On 3/26/22 14:51, Joe Perches wrote:
On Sat, 2022-03-26 at 19:27 +0100, Mauro Carvalho Chehab wrote:
Em Sat, 26 Mar 2022 19:24:54 +0100
Mauro Carvalho Chehab escreveu:
Em Sat, 26 Mar 2022 17:59:03 +0100
Benjamin Stürz escreveu:
This replaces comments with C99's designated
initializers beca
On 3/26/22 11:59, Benjamin Stürz wrote:
This replaces comments with C99's designated
initializers because the kernel supports them now.
Signed-off-by: Benjamin Stürz
---
drivers/net/wireless/realtek/rtw89/coex.c | 40 +++
1 file changed, 20 insertions(+), 20 deletions(-)
I tested 5.11.0-rc1 and it booted OK. My problem is fixed.
Thanks,
Larry
Beginning with commit d0e3fc69d00d ("powerpc/vdso: Provide
__kernel_clock_gettime64() on vdso32"), my PowerBook G4 Aluminum fails to boot.
It stops pretty early in the boot.
I will be happy to test any patches, or provide any additional information.
Larry
On 5/23/20 12:30 PM, Christophe Leroy wrote:
Hi Larry,
Le 23/05/2020 à 19:24, Larry Finger a écrit :
Hi Christophe,
Although kernel 5.7.0-rc2 appeared to boot cleanly, it failed on my G4 when I
tried to generate a new kernel. The following BUG message is logged:
[...]
This problem was
Hi Christophe,
Although kernel 5.7.0-rc2 appeared to boot cleanly, it failed on my G4 when I
tried to generate a new kernel. The following BUG message is logged:
[ 336.148935] [ cut here ]
[ 336.148950] kernel BUG at ./include/linux/swapops.h:195!
[ 336.148971] Oops:
Christophe,
On 2/14/20 1:35 PM, Christophe Leroy wrote:
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -270,6 +270,9 @@ __secondary_hold_acknowledge:
* pointer when we take an exception from supervisor mode.)
* -- paulus.
*/
+#ifdef CONFIG_PPC_CHRP
+1:
On 2/14/20 12:24 AM, Christophe Leroy wrote:
Did you try with the patch at https://patchwork.ozlabs.org/patch/1237387/ ?
Christophe,
When I apply that patch, there is an error at
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -301,6 +301,39 @@ MachineCheck:
On 2/14/20 12:24 AM, Christophe Leroy wrote:
Did you try with the patch at https://patchwork.ozlabs.org/patch/1237387/ ?
Christophe,
When I apply that patch, there is an error at
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -301,6 +301,39 @@ MachineCheck:
On 2/11/20 12:55 AM, Christophe Leroy wrote:
Le 10/02/2020 à 13:55, Larry Finger a écrit :
On 2/9/20 12:19 PM, Christophe Leroy wrote:
Do you have CONFIG_TRACE_IRQFLAGS in your config ?
If so, can you try the patch below ?
https://patchwork.ozlabs.org/patch/1235081/
Otherwise, can you send
On 6/14/19 2:15 PM, Aaro Koskinen wrote:
Hi,
On Fri, Jun 14, 2019 at 09:24:16AM +0200, Mathieu Malaterre wrote:
On Thu, Jun 13, 2019 at 10:27 AM Christoph Hellwig wrote:
With the strict dma mask checking introduced with the switch to
the generic DMA direct code common wifi chips on 32-bit pow
.
Fixes: 65a21b71f948 ("powerpc/dma: remove dma_nommu_dma_supported")
Reported-by: Aaro Koskinen
Signed-off-by: Christoph Hellwig
As expected, it works. The patch needs
Cc: Stable # v5.1+
Tested-by: Larry Finger
Acked-by: Larry Finger
Thanks for the help, and the patience with my
On 6/12/19 1:55 AM, Christoph Hellwig wrote:
Ooops, yes. But I think we could just enable ZONE_DMA on 32-bit
powerpc. Crude enablement hack below:
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8c1c636308c8..1dd71a98b70c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kco
On 6/11/19 5:46 PM, Aaro Koskinen wrote:
Hi,
On Tue, Jun 11, 2019 at 05:20:12PM -0500, Larry Finger wrote:
It is obvious that the case of a mask smaller than min_mask should be
handled by the IOMMU. In my system, CONFIG_IOMMU_SUPPORT is selected. All
other CONFIG variables containing IOMMU are
On 6/11/19 5:46 PM, Benjamin Herrenschmidt wrote:
On Tue, 2019-06-11 at 17:20 -0500, Larry Finger wrote:
b43-pci-bridge 0001:11:00.0: dma_direct_supported: failed (mask =
0x3fff,
min_mask = 0x5000/0x5000, dma bits = 0x1f
Ugh ? A mask with holes in it ? That's very wrong...
On 6/11/19 1:05 AM, Christoph Hellwig wrote:
On Mon, Jun 10, 2019 at 11:09:47AM -0500, Larry Finger wrote:
What might be confusing in your output is that dev->dma_mask is a pointer,
and we are setting it in dma_set_mask. That is before we only check
if the pointer is set, and later we overr
On 6/7/19 11:21 PM, Benjamin Herrenschmidt wrote:
Please try the attached patch. I'm not really pleased with it and I will
continue to determine why the fallback to a 30-bit mask fails, but at least this
one works for me.
Your patch only makes sense if the device is indeed capable of
addressi
On 6/10/19 3:18 AM, Christoph Hellwig wrote:
On Sat, Jun 08, 2019 at 04:52:24PM -0500, Larry Finger wrote:
On 6/7/19 12:29 PM, Christoph Hellwig wrote:
I don't think we should work around this in the driver, we need to fix
it in the core. I'm curious why my previous patch didn&#x
On 6/7/19 12:29 PM, Christoph Hellwig wrote:
I don't think we should work around this in the driver, we need to fix
it in the core. I'm curious why my previous patch didn't work. Can
you throw in a few printks what failed? I.e. did dma_direct_supported
return false? Did the actual allocation
On 6/7/19 12:29 PM, Christoph Hellwig wrote:
I don't think we should work around this in the driver, we need to fix
it in the core. I'm curious why my previous patch didn't work. Can
you throw in a few printks what failed? I.e. did dma_direct_supported
return false? Did the actual allocation
0 2001
From: Larry Finger
Date: Fri, 7 Jun 2019 12:04:16 -0500
Subject: [PATCH] b43legacy: Fix DMA breakage from commit commit 65a21b71f948
To: kv...@codeaurora.org
Cc: linux-wirel...@vger.kernel.org,
pks...@realtek.com
Following commit 65a21b71f948 ("powerpc/dma: remove dma_nommu_dma_s
On 6/6/19 6:43 AM, Christoph Hellwig wrote:
On Thu, Jun 06, 2019 at 08:57:49PM +1000, Benjamin Herrenschmidt wrote:
Wow... that's an odd amount. One thing we could possibly do is add code
to limit the amount of RAM when we detect that device
Sent too quickly... I mean that *or* force swiot
On 6/6/19 6:43 AM, Christoph Hellwig wrote:
On Thu, Jun 06, 2019 at 08:57:49PM +1000, Benjamin Herrenschmidt wrote:
Wow... that's an odd amount. One thing we could possibly do is add code
to limit the amount of RAM when we detect that device
Sent too quickly... I mean that *or* force swiot
On 6/5/19 5:50 PM, Aaro Koskinen wrote:
Hi,
When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN does
not work anymore:
[ 42.004303] b43legacy-phy0: Loading firmware version 0x127, patch level 14
(2005-04-18 02:36:27)
[ 42.184837] b43legacy-phy0 debug: Chip initialized
[ 42.1
On 3/25/19 3:46 AM, Christophe Leroy wrote:
Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
Aluminum. The bootstrap loads the initial kernel and issues the appropriate
start, but the machine hangs at that point.
The
t that time.
So the virtual address of the field should be used instead, but in
the meantime, thread struct has already been zeroised and initialised
so we can just drop this initialisation.
Reported-by: Larry Finger
Fixes: 0df977eafc79 ("powerpc/6xx: Don't use SPRN_SPRG2 for storin
On 3/25/19 1:53 AM, Christophe Leroy wrote:
Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
Aluminum. The bootstrap loads the initial kernel and issues the appropriate
start, but the machine hangs at that point.
Can
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
Aluminum. The bootstrap loads the initial kernel and issues the appropriate
start, but the machine hangs at that point.
The problem does not depend on the choice of PPC32 processor type. This machine
has a 7447A accor
On 07/01/2018 11:16 PM, Michael Ellerman wrote:
Linus Torvalds writes:
On Fri, Jun 29, 2018 at 1:42 PM Larry Finger wrote:
I have more information regarding this BUG. Line 700 of page-flags.h is the
macro PAGE_TYPE_OPS(Table, table). For further debugging, I manually expanded
the macro, and
On 06/30/2018 04:31 AM, christophe leroy wrote:
Le 29/06/2018 à 22:42, Larry Finger a écrit :
My PowerBook G4 Aluminum crashes on boot with 4.18-rcX kernels with a kernel
BUG at include/linux/page-flags.h:700! The problem was bisected to commit
1d40a5ea01d5 ("mm: mark pages in use for
My PowerBook G4 Aluminum crashes on boot with 4.18-rcX kernels with a kernel BUG
at include/linux/page-flags.h:700! The problem was bisected to commit
1d40a5ea01d5 ("mm: mark pages in use for page tables"). It is not possible to
capture the bug with anything other than a camera. The first few li
My PowerBook G4 Aluminum crashes on boot with 4.18-rcX kernels with a kernel BUG
at include/linux/page-flags.h:700! The problem was bisected to commit
1d40a5ea01d5 ("mm: mark pages in use for page tables"). It is not possible to
capture the bug with anything other than a camera. The first few li
In kernel 4.15, the modprobe step on my PowerBook G4 started complaining that
there was no module license for ans-lcd.
Signed-off-by: Larry Finger
---
v2 - fixed typo in commit message
---
drivers/macintosh/ans-lcd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/macintosh/ans
On 01/29/2018 04:49 PM, Gabriel Paubert wrote:
On Mon, Jan 29, 2018 at 01:33:08PM -0600, Larry Finger wrote:
In kernel 4.15, the modprobe step on my PowerBook G5 started complaining that
PowerBook G5? Really, could you send a pic! :-)
That was a typo. It is a G4 Aluminum.
Larry
In kernel 4.15, the modprobe step on my PowerBook G5 started complaining that
there was no module license for ans-lcd.
Signed-off-by: Larry Finger
---
drivers/macintosh/ans-lcd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/macintosh/ans-lcd.c b/drivers/macintosh/ans-lcd.c
index
On 09/13/2017 07:37 PM, Andrew Donnellan wrote:
On 14/09/17 10:07, Larry Finger wrote:
When booting my PowerBook Aluminum G4, I get a pop-up screen that says "The
system is running in low-graphics mode. Your screen, graphics card, and input
device settings could not be detected correctly
When booting my PowerBook Aluminum G4, I get a pop-up screen that says "The
system is running in low-graphics mode. Your screen, graphics card, and input
device settings could not be detected correctly. You will need to configure
these yourself." This is a big-endian 74xx CPU. The lscpu command
On 06/23/2017 03:29 PM, Al Viro wrote:
On Fri, Jun 23, 2017 at 01:49:16PM -0500, Larry Finger wrote:
BTW, could you try to check what happens if you kill the
if (__builtin_constant_p(n) && (n <= 8))
bits in raw_copy_{to,from}_user()? The usefulness of those (in
__cop
57933dbb6e ("treewide: Move dma_ops from struct dev_archdata
into struct device")
Signed-off-by: Larry Finger
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Benjamin Herrenschmidt
Cc: regressi...@leemhuis.info
drivers/macintosh/macio_asic.c | 1 +
1 file changed, 1 insertion(+)
diff --git
32,64}.S, misc_{32,64}.S,
systbl.S")
Signed-off-by: Larry Finger
Cc: Nicholas Piggin
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/misc_32.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch
On 12/21/2016 08:02 PM, Nicholas Piggin wrote:
Hi Larry,
This is strange you've bisected it there, I can't see how that patch would
trigger it. That said, powerpc has had a few small build system glitches.
It looks like this warning could be fixed by changing #elif CONFIG_FSL_BOOKE
to #elif def
On 11/07/2016 11:21 AM, Paul Burton wrote:
Hi Larry,
On Monday, 7 November 2016 09:26:37 GMT Larry Finger wrote:
A revert was already submitted by Hans de Goede & is being discussed over
here:
https://marc.info/?l=linux-kernel&m=147826151427455&w=2
I am a little surprised that I
On 11/07/2016 03:18 AM, Paul Burton wrote:
On Monday, 7 November 2016 19:27:32 GMT Michael Ellerman wrote:
Paul Burton writes:
If a device tree specified a preferred device for kernel console output
via the stdout-path or linux,stdout-path chosen node properties there's
no guarantee that it wi
On 10/31/2016 06:09 PM, Sergey Senozhatsky wrote:
Hi,
On (10/31/16 15:50), Paul Burton wrote:
[..]
Actually whilst this fixes the output in QEMU it has other problems. I'm still
digging...
I propose a revert of '05fd007e46296', so you guys can find the
problem and fix it, not being under 'rc3
On 10/31/2016 10:50 AM, Paul Burton wrote:
On Monday, 31 October 2016 12:14:55 GMT Paul Burton wrote:
If a device tree specified a preferred device for kernel console output
via the stdout-path or linux,stdout-path chosen node properties there's
no guarantee that it will have specified a device
On 10/31/2016 07:14 AM, Paul Burton wrote:
If a device tree specified a preferred device for kernel console output
via the stdout-path or linux,stdout-path chosen node properties there's
no guarantee that it will have specified a device for which we have a
driver. It may also be the case that we
On 04/29/2012 07:23 PM, Benjamin Herrenschmidt wrote:
On Sat, 2012-04-28 at 18:53 -0500, Larry Finger wrote:
Index: wireless-testing/drivers/tty/serial/pmac_zilog.c
===
--- wireless-testing.orig/drivers/tty/serial/pmac_zilog.c
On 04/29/2012 04:05 AM, Gabriel Paubert wrote:
On Sat, Apr 28, 2012 at 06:53:49PM -0500, Larry Finger wrote:
Hmm, I'm not a native english speaker, but I have the feeling that
it would be more grammatically correct to use "opened" instead of "open".
Of course if t
ctly report why an error branch
is being taken.
Signed-off-by: Larry Finger
---
Ben,
Any changes you wish to make in the commit message are OK with me.
Larry
---
Index: wireless-testing/drivers/tty/serial/pmac_zilog.c
===
--- wireless-
On 04/28/2012 06:23 PM, Benjamin Herrenschmidt wrote:
On Sat, 2012-04-28 at 18:17 -0500, Larry Finger wrote:
Yes, good catch by Andreas. That change does fix the problem.
Ben - Do you want to fix the typos for open/not open with the same
patch?
Sure, if you're going to do a proper patc
On 04/28/2012 05:48 PM, Benjamin Herrenschmidt wrote:
On Sat, 2012-04-28 at 20:23 +0200, Andreas Schwab wrote:
Larry Finger writes:
I have done a little more debugging. The problem is definitely coming from
drivers/tty/serial/pmac_zilog.c. I am getting ChanB interrupts while open,
which
On 04/27/2012 07:42 PM, Benjamin Herrenschmidt wrote:
Ok, so you do have a serial port, probably two even :-) One of them is
connected to the infra red transceiver and the other one is probably
connected to the internal modem.
(The modem itself might not use it, some of these machines use an
i2
On 04/27/2012 05:26 PM, Benjamin Herrenschmidt wrote:
On Fri, 2012-04-27 at 10:38 -0500, Larry Finger wrote:
Sorry, I was unable to find anything in debugfs to help me learn about interrupt
mapping. The value of CONFIG_NR_IRQS is already 512. I have not tried reducing
it to 128. The setting
On 04/25/2012 04:44 PM, Benjamin Herrenschmidt wrote:
Do we know what the bad interrupt maps to ? Also what is the value of
NR_IRQ and do you have SPARSE_IRQ enabled ? Can you try with the latter
disabled and NR_IRQ set to something large, such as 128 ?
(You may be able to check the interrupt m
On 04/24/2012 11:11 PM, Benjamin Herrenschmidt wrote:
On Tue, 2012-04-24 at 21:37 -0500, Larry Finger wrote:
Somewhere between v3.2 and v3.3, the kernel in my Powerbook G4
started issuing
the following traceback on bootup:
Does it continue working afterward or not at all ?
Are you using
On 04/24/2012 06:53 PM, Benjamin Herrenschmidt wrote:
On Tue, 2012-04-24 at 17:58 -0500, Larry Finger wrote:
Hi,
Somewhere between v3.2 and v3.3, the kernel in my Powerbook G4 started issuing
the following traceback on bootup:
Does it continue working afterward or not at all ?
Are you using
Hi,
Somewhere between v3.2 and v3.3, the kernel in my Powerbook G4 started issuing
the following traceback on bootup:
[ 40.264006] irq 23: nobody cared (try booting with the "irqpoll" option)
[ 40.264031] Call Trace:
[ 40.264070] [dfff3f00] [c000984c] show_stack+0x7c/0x194 (unreliable)
[
On 05/31/2011 10:54 AM, Andreas Schwab wrote:
Larry Finger writes:
From the traceback, it must be the serdes_pll_device read that failed.
Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)?
Mainly because the last two steps in the traceback are
[c2ca5c40] [f2146244
On 05/31/2011 04:37 AM, Andreas Schwab wrote:
Rafał Miłecki writes:
+/**
+ * Workarounds.
+ **/
+
+static u8 ssb_pcicore_polarity_workaround(struct ssb_pcicore *pc)
+{
+ return (ssb_pcie_rea
59 matches
Mail list logo
