v6.10-rcX, or in Linux Next.
>
> But if you think differently, tell me.
Thanks, the drivers/platform/x86 bits look good to me:
Acked-by: Hans de Goede
Regards,
Hans
> arch/powerpc/xmon/xmon.c | 5 ++--
> arch/x86/kernel/cpu/mtrr/if.c | 4 +
Hi,
On 12/14/23 11:06, Christophe Leroy wrote:
>
>
> Le 13/12/2023 à 23:30, George Stark a écrit :
>> [Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Using of devm API le
) or as a static inline...
With a static inline we are pretty much back to the original
v3 patch.
I believe the best way to reduce the ifdef-ery is to remove
the #ifdef around devm_mutex_release() having unused
static inline ... functions in .h files is quite common,
so this one does not need a #ifdef around it and with
that removed we are down to just one #ifdef so just
removing the #ifdef around devm_mutex_release() seems
the best fix.
With that fixed you may add my:
Reviewed-by: Hans de Goede
to the patch and I'm fine with this being routed
upstream through whatever tree is convenient.
Regards,
Hans
Hi,
On 12/6/23 19:58, George Stark wrote:
>
> Hello Hans
>
> Thanks for the review.
>
> On 12/6/23 18:01, Hans de Goede wrote:
>> Hi George,
>>
>> On 12/4/23 19:05, George Stark wrote:
>>> Using of devm API leads to certain order of releasing resour
Hi George,
On 12/4/23 19:05, 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 resources
Hi,
On 12/6/23 08:56, George Stark wrote:
> Hello Andy
>
> Thanks for the review.
>
> On 12/4/23 21:11, Andy Shevchenko wrote:
>> 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
gt; Cc: Daniel Jordan
> Cc: Daniel Lezcano
> Cc: Dave Hansen
> Cc: Davidlohr Bueso
> Cc: "David S. Miller"
> Cc: Dietmar Eggemann
> Cc: Gonglei
> Cc: Greg Kroah-Hartman
> Cc: Guenter Roeck
> Cc: Hans de Goede
> Cc: Heiko Carstens
> Cc: Herbert
Milton Miller wrote:
On Jul 14, 2008, at 2:59 AM, Jean Delvare wrote:
On Sun, 13 Jul 2008 15:26:56 -0600, David Hubbard wrote:
Hi Hans,
I propose writing a subsystem driver. (Is that properly called "The
SuperIO Bus Driver"?) If no one thinks it's a really bad idea I will
put together some co
David Hubbard wrote:
Hi Hans, Milton, Jean,
On Sun, Jul 13, 2008 at 12:31 AM, Hans de Goede <[EMAIL PROTECTED]> wrote:
Jean Delvare wrote:
On Fri, 11 Jul 2008 09:27:26 +0200, Hans de Goede wrote:
Jean Delvare wrote:
Hi Hans, hi Milton,
One could make a superio driver, and crea
Jean Delvare wrote:
On Fri, 11 Jul 2008 09:27:26 +0200, Hans de Goede wrote:
Jean Delvare wrote:
Hi Hans, hi Milton,
One could make a superio driver, and create sub-devices for the IR,
I2C, floppy, parallel, etc
nodes.
There have been proposals to do this, and this would indeed be a
Jean Delvare wrote:
Hi Hans, hi Milton,
One could make a superio driver, and create sub-devices for the IR,
I2C, floppy, parallel, etc
nodes.
There have been proposals to do this, and this would indeed be a very
good idea, but unfortunately nobody took the time to implement this
properly
Milton Miller wrote:
After the following patch to mark the isa region busy and applying a few
patches[1], I was able to kexec boot into an all-yes-config kernel from
linux-next, with the following KCONFIG_ALLCONFIG file:
# CONFIG_KALLSYMS_EXTRA_PASS is not set
# CONFIG_CRASH_DUMP is not set
CO
12 matches
Mail list logo
