On Thu, Nov 29, 2018 at 10:58:40AM -0800, Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote:
> >
> > Note, we do have a bit of control at what is getting called. The patch
> > set requires that the callers are wrapped in macros. We should not
> > allow just any random
On Thu, Nov 29, 2018 at 10:58:40AM -0800, Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote:
> >
> > Note, we do have a bit of control at what is getting called. The patch
> > set requires that the callers are wrapped in macros. We should not
> > allow just any random
* Aaro Koskinen [181119 11:49]:
> Configure omap1_spi100k only on OMAP7xx. This allows running multiboard
> kernels on non-OMAP7xx HW with CONFIG_SPI_OMAP_100K enabled.
Applying into omap-for-v4.21/omap1 thanks.
Tony
* Aaro Koskinen [181119 11:49]:
> Configure omap1_spi100k only on OMAP7xx. This allows running multiboard
> kernels on non-OMAP7xx HW with CONFIG_SPI_OMAP_100K enabled.
Applying into omap-for-v4.21/omap1 thanks.
Tony
* Aaro Koskinen [181119 11:46]:
> Currently we get extra newlines on OMAP1/2 when the SoC name is printed:
>
> [0.00] OMAP1510
> [0.00] revision 2 handled as 15xx id: bc058c9b93111a16
>
> [0.00] OMAP2420
> [0.00]
>
> Fix by using pr_cont.
Applying into
* Aaro Koskinen [181119 11:46]:
> Currently we get extra newlines on OMAP1/2 when the SoC name is printed:
>
> [0.00] OMAP1510
> [0.00] revision 2 handled as 15xx id: bc058c9b93111a16
>
> [0.00] OMAP2420
> [0.00]
>
> Fix by using pr_cont.
Applying into
* Linus Walleij [181115 10:46]:
> On Wed, Nov 7, 2018 at 9:16 PM Janusz Krzysztofik wrote:
>
> > Janusz Krzysztofik (3):
> > ARM: OMAP1: ams-delta: Drop board specific global GPIO numbers
> > ARM: OMAP1: ams-delta: Drop unused symbols from the board header
> > ARM: OMAP1:
* Linus Walleij [181115 10:46]:
> On Wed, Nov 7, 2018 at 9:16 PM Janusz Krzysztofik wrote:
>
> > Janusz Krzysztofik (3):
> > ARM: OMAP1: ams-delta: Drop board specific global GPIO numbers
> > ARM: OMAP1: ams-delta: Drop unused symbols from the board header
> > ARM: OMAP1:
* Yangtao Li [181106 06:35]:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Applying into omap-for-v4.21/omap1 thanks.
Tony
* Yangtao Li [181106 06:35]:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Applying into omap-for-v4.21/omap1 thanks.
Tony
* Yangtao Li [181106 06:34]:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Applying into omap-for-v4.21/omap1 thanks.
Tony
* Yangtao Li [181106 06:34]:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Applying into omap-for-v4.21/omap1 thanks.
Tony
* Linus Walleij [181114 12:51]:
> On Tue, Nov 6, 2018 at 12:22 AM Janusz Krzysztofik
> wrote:
>
> > Global GPIO numbers no longer have to be passed to leds-gpio driver,
> > replace their assignment with a lookup table.
> >
> > Signed-off-by: Janusz Krzysztofik
>
> Excellent Janusz! :)
>
* Linus Walleij [181114 12:51]:
> On Tue, Nov 6, 2018 at 12:22 AM Janusz Krzysztofik
> wrote:
>
> > Global GPIO numbers no longer have to be passed to leds-gpio driver,
> > replace their assignment with a lookup table.
> >
> > Signed-off-by: Janusz Krzysztofik
>
> Excellent Janusz! :)
>
* Janusz Krzysztofik [181105 15:09]:
> Now as the board header file is no longer included by drivers, move it
> to the root directory of mach-omap1.
Applying into omap-for-v4.21/omap1 thanks.
Tony
* Janusz Krzysztofik [181105 15:09]:
> Now as the board header file is no longer included by drivers, move it
> to the root directory of mach-omap1.
Applying into omap-for-v4.21/omap1 thanks.
Tony
On 4/19/18 9:50 AM, Alexandre Belloni wrote:
> Since commit 6610e0893b8bc ("RTC: Rework RTC code to use timerqueue for
> events"), PIE are completely handled using hrtimers, without actually using
> any underlying hardware RTC.
>
> Move PIE testing out of rtctest. It still depends on the presence
On 4/19/18 9:50 AM, Alexandre Belloni wrote:
> Since commit 6610e0893b8bc ("RTC: Rework RTC code to use timerqueue for
> events"), PIE are completely handled using hrtimers, without actually using
> any underlying hardware RTC.
>
> Move PIE testing out of rtctest. It still depends on the presence
From: Enrico Granata
The ChromeOS EC has support for signaling to the host that
a single IRQ can serve multiple MKBP events.
Doing this serves an optimization purpose, as it minimizes the
number of round-trips into the interrupt handling machinery, and
it proves beneficial to sensor
On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner
> wrote:
> >
> > On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
> > wrote:
> > >
> > >
> > >> On Nov 29, 2018, at 4:28 AM, Florian Weimer
> > >wrote:
> > >>
> > >>
From: Enrico Granata
The ChromeOS EC has support for signaling to the host that
a single IRQ can serve multiple MKBP events.
Doing this serves an optimization purpose, as it minimizes the
number of round-trips into the interrupt handling machinery, and
it proves beneficial to sensor
On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner
> wrote:
> >
> > On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
> > wrote:
> > >
> > >
> > >> On Nov 29, 2018, at 4:28 AM, Florian Weimer
> > >wrote:
> > >>
> > >>
stable-rc/linux-4.4.y boot: 103 boots: 1 failed, 101 passed with 1 offline
(v4.4.165-87-g0741f52e1a53)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.165-87-g0741f52e1a53/
Full Build Summary:
stable-rc/linux-3.18.y boot: 64 boots: 5 failed, 59 passed
(v3.18.127-84-gd2846da19bca)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.18.127-84-gd2846da19bca/
Full Build Summary:
stable-rc/linux-4.4.y boot: 103 boots: 1 failed, 101 passed with 1 offline
(v4.4.165-87-g0741f52e1a53)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.165-87-g0741f52e1a53/
Full Build Summary:
stable-rc/linux-3.18.y boot: 64 boots: 5 failed, 59 passed
(v3.18.127-84-gd2846da19bca)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.18.127-84-gd2846da19bca/
Full Build Summary:
stable-rc/linux-4.9.y boot: 113 boots: 0 failed, 111 passed with 1 offline, 1
untried/unknown (v4.9.141-93-gf46aebe62697)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.141-93-gf46aebe62697/
Full Build Summary:
stable-rc/linux-4.14.y boot: 121 boots: 0 failed, 117 passed with 3 offline, 1
conflict (v4.14.84-101-gfed8ae3e80b0)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.84-101-gfed8ae3e80b0/
Full Build Summary:
stable-rc/linux-4.9.y boot: 113 boots: 0 failed, 111 passed with 1 offline, 1
untried/unknown (v4.9.141-93-gf46aebe62697)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.141-93-gf46aebe62697/
Full Build Summary:
stable-rc/linux-4.14.y boot: 121 boots: 0 failed, 117 passed with 3 offline, 1
conflict (v4.14.84-101-gfed8ae3e80b0)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.84-101-gfed8ae3e80b0/
Full Build Summary:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
> Possibly I misunderstood you, but I don't think we want to copy-up on
> permission denial, as that would still allow the mounter to read/write
> special files or execute regular files to which it would normally be
> denied access, because
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
> Possibly I misunderstood you, but I don't think we want to copy-up on
> permission denial, as that would still allow the mounter to read/write
> special files or execute regular files to which it would normally be
> denied access, because
On Thu, Nov 29, 2018 at 07:26:56PM +0100, Daniel Lezcano wrote:
> Without this patch, the thermal driver on hi6220 and hi3660 is broken.
>
> That is due because part of the posted patchset was merged but a small
> change in the DT was dropped.
>
> The hi6220 and hi3660 do not have an interrupt
On Thu, Nov 29, 2018 at 07:26:56PM +0100, Daniel Lezcano wrote:
> Without this patch, the thermal driver on hi6220 and hi3660 is broken.
>
> That is due because part of the posted patchset was merged but a small
> change in the DT was dropped.
>
> The hi6220 and hi3660 do not have an interrupt
> -Original Message-
> From: Jean Delvare [mailto:jdelv...@suse.de]
> Sent: Thursday, November 29, 2018 11:34 AM
> To: Greg Kroah-Hartman
> Cc: Schmauss, Erik ; linux-
> ker...@vger.kernel.org; sta...@vger.kernel.org; Jean-Marc Lenoir
> ; Wysocki, Rafael J
> Subject: Re: [PATCH 4.14
> -Original Message-
> From: Jean Delvare [mailto:jdelv...@suse.de]
> Sent: Thursday, November 29, 2018 11:34 AM
> To: Greg Kroah-Hartman
> Cc: Schmauss, Erik ; linux-
> ker...@vger.kernel.org; sta...@vger.kernel.org; Jean-Marc Lenoir
> ; Wysocki, Rafael J
> Subject: Re: [PATCH 4.14
On Thu, 29 Nov 2018 20:21:37 +0100, Greg Kroah-Hartman wrote:
> On Thu, Nov 29, 2018 at 06:56:40PM +, Schmauss, Erik wrote:
> > This should only apply to 4.17 or later. I unintentionally put all
> > applicable so
> > please drop this for all 4.16 or earlier. I've learned my lesson and I'll
>
On Thu, 29 Nov 2018 20:21:37 +0100, Greg Kroah-Hartman wrote:
> On Thu, Nov 29, 2018 at 06:56:40PM +, Schmauss, Erik wrote:
> > This should only apply to 4.17 or later. I unintentionally put all
> > applicable so
> > please drop this for all 4.16 or earlier. I've learned my lesson and I'll
>
On Thu, 29 Nov 2018 11:24:43 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote:
> >
> > But then we need to implement all numbers of parameters.
>
> Oh, I agree, it's nasty.
>
> But it's actually a nastiness that we've solved before. In particular,
> with
On Thu, 29 Nov 2018 11:24:43 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote:
> >
> > But then we need to implement all numbers of parameters.
>
> Oh, I agree, it's nasty.
>
> But it's actually a nastiness that we've solved before. In particular,
> with
On Thu, Nov 29, 2018 at 07:00:58PM +, alex_gagn...@dellteam.com wrote:
> >> + if (link_status & PCI_EXP_LNKSTA_LBMS) {
> >> + if (pdev->subordinate && pdev->subordinate->self)
> >> + endpoint = pdev->subordinate->self;
> >
> > Hmm, I thought pdev->subordinate->self
On Thu, Nov 29, 2018 at 07:00:58PM +, alex_gagn...@dellteam.com wrote:
> >> + if (link_status & PCI_EXP_LNKSTA_LBMS) {
> >> + if (pdev->subordinate && pdev->subordinate->self)
> >> + endpoint = pdev->subordinate->self;
> >
> > Hmm, I thought pdev->subordinate->self
On Thu, Nov 29, 2018 at 11:25 AM Linus Torvalds
wrote:
>
> On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote:
> >
> > But then we need to implement all numbers of parameters.
>
> Oh, I agree, it's nasty.
>
> But it's actually a nastiness that we've solved before. In particular,
> with the
On Thu, Nov 29, 2018 at 11:25 AM Linus Torvalds
wrote:
>
> On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote:
> >
> > But then we need to implement all numbers of parameters.
>
> Oh, I agree, it's nasty.
>
> But it's actually a nastiness that we've solved before. In particular,
> with the
On Thu, 29 Nov 2018 13:22:11 -0600
Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
> > > and honestly, the way "static_call()" works now, can you guarantee
> > > that the call-site doesn't end up doing that, and calling the
> > > trampoline function for
On Thu, 29 Nov 2018 13:22:11 -0600
Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
> > > and honestly, the way "static_call()" works now, can you guarantee
> > > that the call-site doesn't end up doing that, and calling the
> > > trampoline function for
On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
wrote:
>
> On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> wrote:
> >
> > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > compiler couldn't turn a "call wrapper(%rip)" into anything else.
>
> Actually, I think I have a
On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
wrote:
>
> On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> wrote:
> >
> > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > compiler couldn't turn a "call wrapper(%rip)" into anything else.
>
> Actually, I think I have a
On Wed, Nov 28, 2018 at 08:08:06PM +, Will Deacon wrote:
> I spent some more time looking at this today...
>
> On Fri, Nov 23, 2018 at 06:05:25PM +, Will Deacon wrote:
> > Doing some more debugging, it looks like the usual failure case is where
> > one CPU clears the inode field in the
On Wed, Nov 28, 2018 at 08:08:06PM +, Will Deacon wrote:
> I spent some more time looking at this today...
>
> On Fri, Nov 23, 2018 at 06:05:25PM +, Will Deacon wrote:
> > Doing some more debugging, it looks like the usual failure case is where
> > one CPU clears the inode field in the
On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote:
>
> But then we need to implement all numbers of parameters.
Oh, I agree, it's nasty.
But it's actually a nastiness that we've solved before. In particular,
with the system call mappings, which have pretty much the exact same
issue of "map
On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote:
>
> But then we need to implement all numbers of parameters.
Oh, I agree, it's nasty.
But it's actually a nastiness that we've solved before. In particular,
with the system call mappings, which have pretty much the exact same
issue of "map
On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner wrote:
>
> On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
> wrote:
> >
> >
> >> On Nov 29, 2018, at 4:28 AM, Florian Weimer
> >wrote:
> >>
> >> Disclaimer: I'm looking at this patch because Christian requested it.
> >> I'm not a
On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner wrote:
>
> On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
> wrote:
> >
> >
> >> On Nov 29, 2018, at 4:28 AM, Florian Weimer
> >wrote:
> >>
> >> Disclaimer: I'm looking at this patch because Christian requested it.
> >> I'm not a
On Thu, 29 Nov 2018, Vitaly Kuznetsov wrote:
> Nadav Amit writes:
>
> >> On Nov 28, 2018, at 5:07 AM, Thomas Gleixner wrote:
> >>
> >> On Wed, 28 Nov 2018, Vitaly Kuznetsov wrote:
> >>
> >>> Nadav Amit writes:
> >>>
> On a different note: how come all of the hyper-v structs are not
On Thu, 29 Nov 2018, Vitaly Kuznetsov wrote:
> Nadav Amit writes:
>
> >> On Nov 28, 2018, at 5:07 AM, Thomas Gleixner wrote:
> >>
> >> On Wed, 28 Nov 2018, Vitaly Kuznetsov wrote:
> >>
> >>> Nadav Amit writes:
> >>>
> On a different note: how come all of the hyper-v structs are not
On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
> > and honestly, the way "static_call()" works now, can you guarantee
> > that the call-site doesn't end up doing that, and calling the
> > trampoline function for two different static calls from one indirect
> > call?
> >
> > See
On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
> > and honestly, the way "static_call()" works now, can you guarantee
> > that the call-site doesn't end up doing that, and calling the
> > trampoline function for two different static calls from one indirect
> > call?
> >
> > See
On Thu, Nov 29, 2018 at 06:56:40PM +, Schmauss, Erik wrote:
>
>
> > -Original Message-
> > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, November 29, 2018 7:01 AM
> > To: Jean Delvare
> > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org;
On Thu, Nov 29, 2018 at 06:56:40PM +, Schmauss, Erik wrote:
>
>
> > -Original Message-
> > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, November 29, 2018 7:01 AM
> > To: Jean Delvare
> > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org;
On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
wrote:
>
>
>> On Nov 29, 2018, at 4:28 AM, Florian Weimer
>wrote:
>>
>> Disclaimer: I'm looking at this patch because Christian requested it.
>> I'm not a kernel developer.
>>
>> * Christian Brauner:
>>
>>> diff --git
On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
wrote:
>
>
>> On Nov 29, 2018, at 4:28 AM, Florian Weimer
>wrote:
>>
>> Disclaimer: I'm looking at this patch because Christian requested it.
>> I'm not a kernel developer.
>>
>> * Christian Brauner:
>>
>>> diff --git
On Thu, 29 Nov 2018 10:58:40 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote:
> >
> > Note, we do have a bit of control at what is getting called. The patch
> > set requires that the callers are wrapped in macros. We should not
> > allow just any random
On Thu, 29 Nov 2018 10:58:40 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote:
> >
> > Note, we do have a bit of control at what is getting called. The patch
> > set requires that the callers are wrapped in macros. We should not
> > allow just any random
On Thu, Nov 29, 2018 at 06:57:37PM +, alex_gagn...@dellteam.com wrote:
> On 11/29/2018 11:36 AM, Bjorn Helgaas wrote:
> > On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
> >> A warning is generated when a PCIe device is probed with a degraded
> >> link, but there was no
On Thu, Nov 29, 2018 at 06:57:37PM +, alex_gagn...@dellteam.com wrote:
> On 11/29/2018 11:36 AM, Bjorn Helgaas wrote:
> > On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
> >> A warning is generated when a PCIe device is probed with a degraded
> >> link, but there was no
On Thu, 29 Nov 2018 11:08:26 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> wrote:
> >
> > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > compiler couldn't turn a "call wrapper(%rip)" into anything else.
>
> Actually, I think I
On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
wrote:
>
> What you can do then is basically add a single-byte prefix to the
> "call" instruction that does nothing (say, cs override), and then
> replace *that* with a 'int3' instruction.
Hmm. the segment prefixes are documented as being
On Thu, 29 Nov 2018 11:08:26 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> wrote:
> >
> > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > compiler couldn't turn a "call wrapper(%rip)" into anything else.
>
> Actually, I think I
On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
wrote:
>
> What you can do then is basically add a single-byte prefix to the
> "call" instruction that does nothing (say, cs override), and then
> replace *that* with a 'int3' instruction.
Hmm. the segment prefixes are documented as being
On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
wrote:
>
> In contrast, if the call was wrapped in an inline asm, we'd *know* the
> compiler couldn't turn a "call wrapper(%rip)" into anything else.
Actually, I think I have a better model - if the caller is done with inline asm.
What you can do
On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
wrote:
>
> In contrast, if the call was wrapped in an inline asm, we'd *know* the
> compiler couldn't turn a "call wrapper(%rip)" into anything else.
Actually, I think I have a better model - if the caller is done with inline asm.
What you can do
Errata i929 in certain OMAP5/DRA7XX/AM57XX silicon revisions
(SPRZ426D - November 2014 - Revised February 2018 [1]) mentions
unexpected tuning pattern errors. A small failure band may be present
in the tuning range which may be missed by the current algorithm.
Furthermore, the failure bands vary
Errata i929 in certain OMAP5/DRA7XX/AM57XX silicon revisions
(SPRZ426D - November 2014 - Revised February 2018 [1]) mentions
unexpected tuning pattern errors. A small failure band may be present
in the tuning range which may be missed by the current algorithm.
Furthermore, the failure bands vary
On 11/28/2018 06:24 AM, Thomas Gleixner wrote:
>
> I've integrated the latest review feedback and the change which plugs the
> TIF async update issue and pushed all of it out to:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/pti
>
> For the stable 4.14.y and 4.19.y
On Thu, Nov 29, 2018 at 07:38:20PM +0100, Bartosz Golaszewski wrote:
> I'm wondering if instead of using the non-devm variants of
> gpiod_get_*() routines, we shouldn't provide helpers in the regulator
> framework that would be named accordingly, for example:
> regulator_gpiod_get_optional() etc.
On Thu, Nov 29, 2018 at 07:38:20PM +0100, Bartosz Golaszewski wrote:
> I'm wondering if instead of using the non-devm variants of
> gpiod_get_*() routines, we shouldn't provide helpers in the regulator
> framework that would be named accordingly, for example:
> regulator_gpiod_get_optional() etc.
On 11/28/2018 06:24 AM, Thomas Gleixner wrote:
>
> I've integrated the latest review feedback and the change which plugs the
> TIF async update issue and pushed all of it out to:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/pti
>
> For the stable 4.14.y and 4.19.y
On 11/29/2018 10:06 AM, Mika Westerberg wrote:
>> @@ -515,7 +515,8 @@ static irqreturn_t pciehp_isr(int irq, void *dev_id)
>> struct controller *ctrl = (struct controller *)dev_id;
>> struct pci_dev *pdev = ctrl_dev(ctrl);
>> struct device *parent = pdev->dev.parent;
>> -u16
On 11/29/2018 10:06 AM, Mika Westerberg wrote:
>> @@ -515,7 +515,8 @@ static irqreturn_t pciehp_isr(int irq, void *dev_id)
>> struct controller *ctrl = (struct controller *)dev_id;
>> struct pci_dev *pdev = ctrl_dev(ctrl);
>> struct device *parent = pdev->dev.parent;
>> -u16
On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote:
>
> Note, we do have a bit of control at what is getting called. The patch
> set requires that the callers are wrapped in macros. We should not
> allow just any random callers (like from asm).
Actually, I'd argue that asm is often more
On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote:
>
> Note, we do have a bit of control at what is getting called. The patch
> set requires that the callers are wrapped in macros. We should not
> allow just any random callers (like from asm).
Actually, I'd argue that asm is often more
On 11/29/2018 11:36 AM, Bjorn Helgaas wrote:
> On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
>> A warning is generated when a PCIe device is probed with a degraded
>> link, but there was no similar mechanism to warn when the link becomes
>> degraded after probing. The Link
On 11/29/2018 11:36 AM, Bjorn Helgaas wrote:
> On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
>> A warning is generated when a PCIe device is probed with a degraded
>> link, but there was no similar mechanism to warn when the link becomes
>> degraded after probing. The Link
> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, November 29, 2018 7:01 AM
> To: Jean Delvare
> Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Jean-Marc Lenoir
> ; Schmauss, Erik ;
> Wysocki, Rafael J
> Subject: Re:
> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, November 29, 2018 7:01 AM
> To: Jean Delvare
> Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Jean-Marc Lenoir
> ; Schmauss, Erik ;
> Wysocki, Rafael J
> Subject: Re:
On Thu, 29 Nov 2018 10:00:48 -0800
Andy Lutomirski wrote:
> >
> > Of course, another option is to just say "we don't do the inline case,
> > then", and only ever do a call to a stub that does a "jmp"
> > instruction.
>
> That’s not a terrible idea.
It was the implementation of my first
On Thu, 29 Nov 2018 10:00:48 -0800
Andy Lutomirski wrote:
> >
> > Of course, another option is to just say "we don't do the inline case,
> > then", and only ever do a call to a stub that does a "jmp"
> > instruction.
>
> That’s not a terrible idea.
It was the implementation of my first
ср, 28 нояб. 2018 г. в 15:43, Long Li :
>
> > Subject: Re: [Patch v4 1/3] CIFS: Add support for direct I/O read
> >
> > Hi Long,
> >
> > Please find my comments below.
> >
> >
> > ср, 31 окт. 2018 г. в 15:14, Long Li :
> > >
> > > From: Long Li
> > >
> > > With direct I/O read, we transfer the
ср, 28 нояб. 2018 г. в 15:43, Long Li :
>
> > Subject: Re: [Patch v4 1/3] CIFS: Add support for direct I/O read
> >
> > Hi Long,
> >
> > Please find my comments below.
> >
> >
> > ср, 31 окт. 2018 г. в 15:14, Long Li :
> > >
> > > From: Long Li
> > >
> > > With direct I/O read, we transfer the
On 11/29/2018 01:43 PM, Davidlohr Bueso wrote:
> On Thu, 29 Nov 2018, Peter Zijlstra wrote:
>
>> On Thu, Nov 29, 2018 at 02:12:32PM +0100, Peter Zijlstra wrote:
>>> Yes, I think this is real, and worse, I think we need to go audit all
>>> wake_q_add() users and document this behaviour.
>>>
>>> In
On 11/29/2018 01:43 PM, Davidlohr Bueso wrote:
> On Thu, 29 Nov 2018, Peter Zijlstra wrote:
>
>> On Thu, Nov 29, 2018 at 02:12:32PM +0100, Peter Zijlstra wrote:
>>> Yes, I think this is real, and worse, I think we need to go audit all
>>> wake_q_add() users and document this behaviour.
>>>
>>> In
On Thu, 29 Nov 2018 10:23:44 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 9:59 AM Steven Rostedt wrote:
> >
> > Do you realize that the cmpxchg used by the first attempts of the
> > dynamic modification of code by ftrace was the source of the e1000e
> > NVRAM corruption bug.
>
> If
On Thu, 29 Nov 2018 10:23:44 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 9:59 AM Steven Rostedt wrote:
> >
> > Do you realize that the cmpxchg used by the first attempts of the
> > dynamic modification of code by ftrace was the source of the e1000e
> > NVRAM corruption bug.
>
> If
On Thu, 29 Nov 2018, Peter Zijlstra wrote:
On Thu, Nov 29, 2018 at 02:12:32PM +0100, Peter Zijlstra wrote:
Yes, I think this is real, and worse, I think we need to go audit all
wake_q_add() users and document this behaviour.
In the ideal case we'd delay the actual wakeup to the last
On Thu, 29 Nov 2018, Peter Zijlstra wrote:
On Thu, Nov 29, 2018 at 02:12:32PM +0100, Peter Zijlstra wrote:
Yes, I think this is real, and worse, I think we need to go audit all
wake_q_add() users and document this behaviour.
In the ideal case we'd delay the actual wakeup to the last
On Thu, Nov 29, 2018 at 10:00 AM Andy Lutomirski wrote:
> > then it really sounds pretty safe to just say "ok, just make it
> > aligned and update the instruction with an atomic cmpxchg or
> > something".
>
> And how do we do that? With a gcc plugin and some asm magic?
Asm magic.
You already
On Thu, Nov 29, 2018 at 10:00 AM Andy Lutomirski wrote:
> > then it really sounds pretty safe to just say "ok, just make it
> > aligned and update the instruction with an atomic cmpxchg or
> > something".
>
> And how do we do that? With a gcc plugin and some asm magic?
Asm magic.
You already
* Update AMD cpu microcode for processor family 17h
Key Name= AMD Microcode Signing Key (for signing microcode container
files only)
Key ID = F328AE73
Key Fingerprint = FC7C 6C50 5DAF CC14 7183 57CA E4BE 5339 F328 AE73
Signed-off-by: John Allen
---
WHENCE
* Update AMD cpu microcode for processor family 17h
Key Name= AMD Microcode Signing Key (for signing microcode container
files only)
Key ID = F328AE73
Key Fingerprint = FC7C 6C50 5DAF CC14 7183 57CA E4BE 5339 F328 AE73
Signed-off-by: John Allen
---
WHENCE
701 - 800 of 2748 matches
Mail list logo
