On 11/29/23 at 06:52pm, Joe Perches wrote:
> On Thu, 2023-11-30 at 10:39 +0800, Baoquan He wrote:
> > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > loading related codes.
>
> trivia:
>
> > diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> []
> > @@ -551,9 +551,1
Michael Ellerman writes:
> "Aneesh Kumar K.V" writes:
>> There used to be a dependency on _PAGE_PRIVILEGED with pte_savedwrite.
>> But that got dropped by
>> commit 6a56ccbcf6c6 ("mm/autonuma: use can_change_(pte|pmd)_writable() to
>> replace savedwrite")
>>
>> With the change in this patch num
From: "Aneesh Kumar K.V (IBM)"
There used to be a dependency on _PAGE_PRIVILEGED with pte_savedwrite.
But that got dropped by
commit 6a56ccbcf6c6 ("mm/autonuma: use can_change_(pte|pmd)_writable() to
replace savedwrite")
With the change in this patch numa fault pte (pte_protnone()) gets mapped
From: "Aneesh Kumar K.V (IBM)"
This reverts commit 1abce0580b89 ("powerpc/64s: Fix __pte_needs_flush()
false positive warning")
The previous patch dropped the usage of _PAGE_PRIVILEGED with PAGE_NONE.
Hence this check can be dropped.
Signed-off-by: Aneesh Kumar K.V (IBM)
---
arch/powerpc/incl
On 04/12/2023 03:07, Kunwu Chan wrote:
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
Fixes: bdecf76e319a ("cxl: Fix coredump generation when cxl_get_fd() is used")
Signed-off-by: Kunwu Chan
---
drivers/misc/cxl/api.c | 4
1 file changed
On Fri, Dec 01, 2023 at 11:17:10AM -0500, Frank Li wrote:
> Add suspend/resume support for Layerscape LS1021a.
>
> In the suspend path, PME_Turn_Off message is sent to the endpoint to
> transition the link to L2/L3_Ready state. In this SoC, there is no way to
> check if the controller has received
On Fri, Dec 01, 2023 at 11:17:11AM -0500, Frank Li wrote:
> 'pf' and 'lut' is just difference name in difference chips, but basic it is
> a MMIO base address plus an offset.
>
> Rename it to avoid duplicate pf_* and lut_* in driver.
>
> Signed-off-by: Frank Li
One comment below. With that addre
On Fri, Dec 01, 2023 at 11:17:12AM -0500, Frank Li wrote:
> Add suspend/resume support for Layerscape LS1043a.
>
> In the suspend path, PME_Turn_Off message is sent to the endpoint to
> transition the link to L2/L3_Ready state. In this SoC, there is no way to
> check if the controller has received
On 03/12/2023 13:33, Christophe Leroy wrote:
>
>
> Le 30/11/2023 à 22:30, Peter Xu a écrit :
>> On Fri, Nov 24, 2023 at 11:07:51AM -0500, Peter Xu wrote:
>>> On Fri, Nov 24, 2023 at 09:06:01AM +, Ryan Roberts wrote:
I don't have any micro-benchmarks for GUP though, if that's your questio
Le 04/12/2023 à 12:11, Ryan Roberts a écrit :
> On 03/12/2023 13:33, Christophe Leroy wrote:
>>
>>
>> Le 30/11/2023 à 22:30, Peter Xu a écrit :
>>> On Fri, Nov 24, 2023 at 11:07:51AM -0500, Peter Xu wrote:
On Fri, Nov 24, 2023 at 09:06:01AM +, Ryan Roberts wrote:
> I don't have any m
On 04/12/2023 11:25, Christophe Leroy wrote:
>
>
> Le 04/12/2023 à 12:11, Ryan Roberts a écrit :
>> On 03/12/2023 13:33, Christophe Leroy wrote:
>>>
>>>
>>> Le 30/11/2023 à 22:30, Peter Xu a écrit :
On Fri, Nov 24, 2023 at 11:07:51AM -0500, Peter Xu wrote:
> On Fri, Nov 24, 2023 at 09:06
Le 04/12/2023 à 12:46, Ryan Roberts a écrit :
> On 04/12/2023 11:25, Christophe Leroy wrote:
>>
>>
>> Le 04/12/2023 à 12:11, Ryan Roberts a écrit :
>>> On 03/12/2023 13:33, Christophe Leroy wrote:
Le 30/11/2023 à 22:30, Peter Xu a écrit :
> On Fri, Nov 24, 2023 at 11:07:51AM -0
On 04/12/2023 11:57, Christophe Leroy wrote:
>
>
> Le 04/12/2023 à 12:46, Ryan Roberts a écrit :
>> On 04/12/2023 11:25, Christophe Leroy wrote:
>>>
>>>
>>> Le 04/12/2023 à 12:11, Ryan Roberts a écrit :
On 03/12/2023 13:33, Christophe Leroy wrote:
>
>
> Le 30/11/2023 à 22:30, Pet
Haren Myneni writes:
> VAS allocate, modify and deallocate HCALLs returns
> H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC for busy
> delay and expects OS to reissue HCALL after that delay. But using
> msleep() will often sleep at least 20 msecs even though the
> hypervisor suggests OS rei
On 12/01/23 at 10:38am, Conor Dooley wrote:
> On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote:
>
> $subject has a typo in the arch bit :)
Indeed, will fix if need report. Thanks for careful checking.
>
> > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file
> > load
Add suspend/resume support for ls1043 and ls1021.
Change log see each patch
Frank Li (4):
PCI: layerscape: Add function pointer for exit_from_l2()
PCI: layerscape: Add suspend/resume for ls1021a
PCI: layerscape(ep): Rename pf_* as pf_lut_*
PCI: layerscape: Add suspend/resume for ls1043a
Since difference SoCs require different sequence for exiting L2, let's add
a separate "exit_from_l2()" callback. This callback can be used to execute
SoC specific sequence.
Change ls_pcie_exit_from_l2() return value from void to int. Return error
if exit_from_l2() failure at exit resume flow.
Ack
Add suspend/resume support for Layerscape LS1021a.
In the suspend path, PME_Turn_Off message is sent to the endpoint to
transition the link to L2/L3_Ready state. In this SoC, there is no way to
check if the controller has received the PME_To_Ack from the endpoint or
not. So to be on the safer side
'pf' and 'lut' is just difference name in difference chips, but basic it is
a MMIO base address plus an offset.
Rename it to avoid duplicate pf_* and lut_* in driver.
Reviewed-by: Manivannan Sadhasivam
Acked-by: Roy Zang
Signed-off-by: Frank Li
---
Notes:
pf_lut is better than pf_* or lut
Add suspend/resume support for Layerscape LS1043a.
In the suspend path, PME_Turn_Off message is sent to the endpoint to
transition the link to L2/L3_Ready state. In this SoC, there is no way to
check if the controller has received the PME_To_Ack from the endpoint or
not. So to be on the safer side
On Mon, Dec 04, 2023 at 11:38:05PM +0800, Baoquan He wrote:
> On 12/01/23 at 10:38am, Conor Dooley wrote:
> > On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote:
> >
> > $subject has a typo in the arch bit :)
>
> Indeed, will fix if need report. Thanks for careful checking.
>
> >
> > >
On Mon, Dec 04, 2023 at 11:11:26AM +, Ryan Roberts wrote:
> To be honest, while I understand pte_cont() and friends, I don't understand
> their relevance (or at least potential future relevance) to GUP?
GUP in general can be smarter to recognize if a pte/pmd is a cont_pte and
fetch the whole p
In the probe() callback in case of error mutex is destroyed being locked
which is not allowed so unlock the mute before destroying.
Signed-off-by: George Stark
---
drivers/leds/leds-aw2013.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/leds/leds-aw2013.c b/drivers/leds/leds-aw2013
Using of devm API leads to certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release order. Mutex is one of such objects that
often is bound to other resources and has no own devm wrapping.
Since mutex_destroy() actual
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
This patch series fixes the problem of devm_led_classdev_register misusing.
The basic problem is described in [1]. Shortly when devm_led_classdev_register()
is used then led_classdev_unregister() called after driver's remove() callback.
led_classdev_unregister() calls driver's brightness_set callb
On Mon, Dec 4, 2023 at 8:07 PM George Stark wrote:
>
> Using of devm API leads to certain order of releasing resources.
> So all dependent resources which are not devm-wrapped should be deleted
> with respect to devm-release order. Mutex is one of such objects that
> often is bound to other resour
On Mon, Dec 4, 2023 at 8:07 PM George Stark wrote:
>
> In the probe() callback in case of error mutex is destroyed being locked
> which is not allowed so unlock the mute before destroying.
Sounds to me like this is a real fix, hence the Fixes tag and being
first in the series.
You free to add
Re
On Mon, Dec 4, 2023 at 8:07 PM George Stark wrote:
>
> In this driver LEDs are registered using devm_led_classdev_register()
> so they are automatically unregistered after module's remove() is done.
> led_classdev_unregister() calls module's led_set_brightness() to turn off
> the LEDs and that cal
On Mon, Dec 4, 2023 at 8:07 PM George Stark wrote:
>
> In this driver LEDs are registered using devm_led_classdev_register()
> so they are automatically unregistered after module's remove() is done.
> led_classdev_unregister() calls module's led_set_brightness() to turn off
> the LEDs and that cal
Hello,
(implicit) v1 of this series can be found at
https://lore.kernel.org/netdev/20231117095922.876489-1-u.kleine-koe...@pengutronix.de.
Changes since then:
- Dropped patch #1 as Alex objected. Patch #1 (was #2 before) now
converts ipa to remove_new() and introduces an error message in the
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve h
Em Sun, Dec 03, 2023 at 09:27:25PM +0530, Athira Rajeev escreveu:
> > On 29-Nov-2023, at 10:51 AM, Athira Rajeev
> > wrote:
> >> On 27-Nov-2023, at 5:32 PM, Disha Goel wrote:
> >>> Fixes: fc1435807533 ("perf vendor events power10: Update JSON/events")
> >>> Signed-off-by: Athira Rajeev
> >> I
On Thu, Nov 23, 2023 at 8:01 AM Athira Rajeev
wrote:
>
> Running "perf list" on powerpc fails with segfault
> as below:
>
>./perf list
>Segmentation fault (core dumped)
>
> This happens because of duplicate events in the json list.
> The powerpc Json event list contains some event with sam
Em Mon, Dec 04, 2023 at 12:12:54PM -0800, Ian Rogers escreveu:
> On Thu, Nov 23, 2023 at 8:01 AM Athira Rajeev
> wrote:
> >
> > Running "perf list" on powerpc fails with segfault
> > as below:
> >
> >./perf list
> >Segmentation fault (core dumped)
> >
> > This happens because of duplicate
Em Mon, Dec 04, 2023 at 05:20:46PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Dec 04, 2023 at 12:12:54PM -0800, Ian Rogers escreveu:
> > On Thu, Nov 23, 2023 at 8:01 AM Athira Rajeev
> > wrote:
> > >
> > > Running "perf list" on powerpc fails with segfault
> > > as below:
> > >
> > >.
On Mon, Dec 4, 2023 at 12:22 PM Arnaldo Carvalho de Melo
wrote:
>
> Em Mon, Dec 04, 2023 at 05:20:46PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Mon, Dec 04, 2023 at 12:12:54PM -0800, Ian Rogers escreveu:
> > > On Thu, Nov 23, 2023 at 8:01 AM Athira Rajeev
> > > wrote:
> > > >
> > > > Runn
On 11/10/2023 7:08 AM, Daniel Walker wrote:
> diff --git a/lib/generic_cmdline.S b/lib/generic_cmdline.S
> new file mode 100644
> index ..223763f9eeb6
> --- /dev/null
> +++ b/lib/generic_cmdline.S
> @@ -0,0 +1,53 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include
> +#include
On Sun, Dec 03, 2023 at 11:23:47AM -0800, Yury Norov wrote:
> Add helpers around test_and_{set,clear}_bit() that allow to search for
> clear or set bits and flip them atomically.
>
> The target patterns may look like this:
>
> for (idx = 0; idx < nbits; idx++)
> if (test_and_c
Hello Yury!
On Sun 03-12-23 11:23:47, Yury Norov wrote:
> Add helpers around test_and_{set,clear}_bit() that allow to search for
> clear or set bits and flip them atomically.
>
> The target patterns may look like this:
>
> for (idx = 0; idx < nbits; idx++)
> if (test_and_clea
Le 04/12/2023 à 19:05, George Stark a écrit :
> Using of devm API leads to certain order of releasing resources.
> So all dependent resources which are not devm-wrapped should be deleted
> with respect to devm-release order. Mutex is one of such objects that
> often is bound to other resources an
Le 04/12/2023 à 19:05, George Stark a écrit :
> In the probe() callback in case of error mutex is destroyed being locked
> which is not allowed so unlock the mute before destroying.
Should there be a fixes: tag ? For instance on 59ea3c9faf32 ("leds: add
aw2013 driver") ?
>
> Signed-off-by: Ge
Le 04/12/2023 à 19:05, George Stark a écrit :
> In this driver LEDs are registered using devm_led_classdev_register()
> so they are automatically unregistered after module's remove() is done.
> led_classdev_unregister() calls module's led_set_brightness() to turn off
> the LEDs and that callback
Le 04/12/2023 à 19:05, George Stark a écrit :
> In this driver LEDs are registered using devm_led_classdev_register()
> so they are automatically unregistered after module's remove() is done.
> led_classdev_unregister() calls module's led_set_brightness() to turn off
> the LEDs and that callback
Bjorn Helgaas writes:
> [+cc scsi, powerpc folks]
>
> On Fri, Dec 01, 2023 at 02:44:47PM -0600, Bjorn Helgaas wrote:
>> On Fri, Nov 24, 2023 at 11:09:13AM +0200, Ilpo Järvinen wrote:
>> > Replace 0x7f and 0x80 literals with PCI_HEADER_TYPE_* defines.
>> >
>> > Signed-off-by: Ilpo Järvinen
>>
>>
Aneesh and Naveen are helping out with some aspects of upstream
maintenance, add them as reviewers.
Signed-off-by: Michael Ellerman
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea790149af79..562d048863ee 100644
--- a/MAINTAINERS
+++ b/MAIN
Christophe volunteered[1] to maintain PPC83XX.
1: https://lore.kernel.org/all/7b1bf4dc-d09d-35b8-f4df-16bf00429...@csgroup.eu/
Signed-off-by: Michael Ellerman
---
MAINTAINERS | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 562d048863ee..
Hi Uwe,
u.kleine-koe...@pengutronix.de wrote on Mon, 4 Dec 2023 19:30:40 +0100:
> Hello,
>
> (implicit) v1 of this series can be found at
> https://lore.kernel.org/netdev/20231117095922.876489-1-u.kleine-koe...@pengutronix.de.
> Changes since then:
>
> - Dropped patch #1 as Alex objected. Pat
> On 05-Dec-2023, at 1:42 AM, Ian Rogers wrote:
>
> On Thu, Nov 23, 2023 at 8:01 AM Athira Rajeev
> wrote:
>>
>> Running "perf list" on powerpc fails with segfault
>> as below:
>>
>> ./perf list
>> Segmentation fault (core dumped)
>>
>> This happens because of duplicate events in the j
> On 05-Dec-2023, at 2:43 AM, Ian Rogers wrote:
>
> On Mon, Dec 4, 2023 at 12:22 PM Arnaldo Carvalho de Melo
> wrote:
>>
>> Em Mon, Dec 04, 2023 at 05:20:46PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Em Mon, Dec 04, 2023 at 12:12:54PM -0800, Ian Rogers escreveu:
On Thu, Nov 23, 202
Hello Miquel,
On Tue, Dec 05, 2023 at 07:51:10AM +0100, Miquel Raynal wrote:
> u.kleine-koe...@pengutronix.de wrote on Mon, 4 Dec 2023 19:30:40 +0100:
> > (implicit) v1 of this series can be found at
> > https://lore.kernel.org/netdev/20231117095922.876489-1-u.kleine-koe...@pengutronix.de.
> > Ch
Hello Uwe,
u.kleine-koe...@pengutronix.de wrote on Tue, 5 Dec 2023 08:39:11 +0100:
> Hello Miquel,
>
> On Tue, Dec 05, 2023 at 07:51:10AM +0100, Miquel Raynal wrote:
> > u.kleine-koe...@pengutronix.de wrote on Mon, 4 Dec 2023 19:30:40 +0100:
> > > (implicit) v1 of this series can be found at
54 matches
Mail list logo
