Re: bug-introducing patches

On Tue, May 01, 2018 at 10:33:25PM +0200, Willy Tarreau wrote: >On Tue, May 01, 2018 at 08:00:21PM +, Sasha Levin wrote: >> What's worse is that that commit is tagged for stable, which means >> that (given Greg's schedule) it may find it's way to -stable users >> even before some -next

Re: bug-introducing patches

On Tue, May 01, 2018 at 10:33:25PM +0200, Willy Tarreau wrote: >On Tue, May 01, 2018 at 08:00:21PM +, Sasha Levin wrote: >> What's worse is that that commit is tagged for stable, which means >> that (given Greg's schedule) it may find it's way to -stable users >> even before some -next

Re: [PATCH 2/5] regulator: add dummy of_find_regulator_by_node

On Tue, May 01, 2018 at 09:00:11PM +0800, changbin...@intel.com wrote: > From: Changbin Du > > If device tree is not enabled, of_find_regulator_by_node() should have > a dummy function since the function call is still there. > > Signed-off-by: Changbin Du

Re: [PATCH 2/5] regulator: add dummy of_find_regulator_by_node

On Tue, May 01, 2018 at 09:00:11PM +0800, changbin...@intel.com wrote: > From: Changbin Du > > If device tree is not enabled, of_find_regulator_by_node() should have > a dummy function since the function call is still there. > > Signed-off-by: Changbin Du This appears to have no obvious

Re: [PATCH] spi: mediatek: Use of_device_get_match_data()

On Mon, Apr 30, 2018 at 03:26:36PM +0800, Ryder Lee wrote: > Hi Mark, > > Is it okay with you? > > On Mon, 2018-04-16 at 10:33 +0800, Ryder Lee (李庚?V) wrote: > > The usage of of_device_get_match_data() reduce the code size a bit. Please don't send content free pings and please allow a

Re: [PATCH] spi: mediatek: Use of_device_get_match_data()

On Mon, Apr 30, 2018 at 03:26:36PM +0800, Ryder Lee wrote: > Hi Mark, > > Is it okay with you? > > On Mon, 2018-04-16 at 10:33 +0800, Ryder Lee (李庚?V) wrote: > > The usage of of_device_get_match_data() reduce the code size a bit. Please don't send content free pings and please allow a

Re: [PATCH v2 2/2] hwmon: (k10temp) Use API function to access System Management Network

Hi Guenter, I love your patch! Yet something to improve: [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.17-rc3 next-20180501] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2 2/2] hwmon: (k10temp) Use API function to access System Management Network

Hi Guenter, I love your patch! Yet something to improve: [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.17-rc3 next-20180501] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: bug-introducing patches

On Tue, May 01, 2018 at 08:00:21PM +, Sasha Levin wrote: > What's worse is that that commit is tagged for stable, which means > that (given Greg's schedule) it may find it's way to -stable users > even before some -next users/bots had a chance to test it out. But it's a difficult trade-off. I

Re: bug-introducing patches

On Tue, May 01, 2018 at 08:00:21PM +, Sasha Levin wrote: > What's worse is that that commit is tagged for stable, which means > that (given Greg's schedule) it may find it's way to -stable users > even before some -next users/bots had a chance to test it out. But it's a difficult trade-off. I

Re: [PATCH v7 4/5] cpuset: Restrict load balancing off cpus to subset of cpus.isolated

On 05/01/2018 03:51 PM, Tejun Heo wrote: > Hello, Waiman. > > Sorry about the delay. > > On Thu, Apr 19, 2018 at 09:47:03AM -0400, Waiman Long wrote: >> With the addition of "cpuset.cpus.isolated", it makes sense to add the >> restriction that load balancing can only be turned off if the CPUs in

Re: [PATCH v7 4/5] cpuset: Restrict load balancing off cpus to subset of cpus.isolated

On 05/01/2018 03:51 PM, Tejun Heo wrote: > Hello, Waiman. > > Sorry about the delay. > > On Thu, Apr 19, 2018 at 09:47:03AM -0400, Waiman Long wrote: >> With the addition of "cpuset.cpus.isolated", it makes sense to add the >> restriction that load balancing can only be turned off if the CPUs in

Re: [v4.17-rcx] Lost IBPB, IBRS_FW support for spectre_v2 mitigation.

On Tue, May 1, 2018 at 5:59 AM Thomas Gleixner wrote: > Then I really have no idea how reverting the patch you pointed out would > fix it. So I do think that the original patch is buggy. What I think *may* be going on is: - first we do that

Re: [v4.17-rcx] Lost IBPB, IBRS_FW support for spectre_v2 mitigation.

On Tue, May 1, 2018 at 5:59 AM Thomas Gleixner wrote: > Then I really have no idea how reverting the patch you pointed out would > fix it. So I do think that the original patch is buggy. What I think *may* be going on is: - first we do that get_cpu_cap(c);

Re: [PATCH v2 2/2] hwmon: (k10temp) Use API function to access System Management Network

On Wed, May 02, 2018 at 03:39:19AM +0800, kbuild test robot wrote: > Hi Guenter, > > I love your patch! Yet something to improve: > > [auto build test ERROR on tip/auto-latest] > [also build test ERROR on v4.17-rc3 next-20180501] > [if your patch is applied to the wrong git

Re: [PATCH v2 2/2] hwmon: (k10temp) Use API function to access System Management Network

On Wed, May 02, 2018 at 03:39:19AM +0800, kbuild test robot wrote: > Hi Guenter, > > I love your patch! Yet something to improve: > > [auto build test ERROR on tip/auto-latest] > [also build test ERROR on v4.17-rc3 next-20180501] > [if your patch is applied to the wrong git

[PATCH] proc/kcore: Don't bounds check against address 0

The existing kcore code checks for bad addresses against __va(0) with the assumption that this is the lowest address on the system. This may not hold true on some systems (e.g. arm64) and produce overflows and crashes. Switch to using other functions to validate the address range. Tested-by: Dave

[PATCH] proc/kcore: Don't bounds check against address 0

The existing kcore code checks for bad addresses against __va(0) with the assumption that this is the lowest address on the system. This may not hold true on some systems (e.g. arm64) and produce overflows and crashes. Switch to using other functions to validate the address range. Tested-by: Dave

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

On Tue, May 01, 2018 at 07:29:19PM +, Andy Lutomirski wrote: > On Sun, Apr 29, 2018 at 2:36 AM Hans de Goede wrote: > > + for (i = 0; i < size; i += 8) { > > + if (*((u64 *)(mem + i)) != *((u64 *)desc->prefix)) > > + continue; > >

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

On Tue, May 01, 2018 at 07:29:19PM +, Andy Lutomirski wrote: > On Sun, Apr 29, 2018 at 2:36 AM Hans de Goede wrote: > > + for (i = 0; i < size; i += 8) { > > + if (*((u64 *)(mem + i)) != *((u64 *)desc->prefix)) > > + continue; > > + > > +

RE: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Hi Florian, > Not sure I completely understand your suggestion, do you mean that I > should break down the body of that function above such that there are > per-speed lower level functions? Something like the pseudo-code below: > > genphy_set_test() { > switch (mode) { > case

RE: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Hi Florian, > Not sure I completely understand your suggestion, do you mean that I > should break down the body of that function above such that there are > per-speed lower level functions? Something like the pseudo-code below: > > genphy_set_test() { > switch (mode) { > case

Re: [PATCH v5 4/6] x86/microcode/AMD: Check microcode container data in the late loader

On Tue, May 01, 2018 at 06:19:56PM +0200, Maciej S. Szmigiero wrote: > -EINVAL cast to unsigned int is 4294967274 and this value is also > a valid count of bytes to skip that this function can return. And where exactly in the *old* code do we do that? -- Regards/Gruss, Boris. Good mailing

Re: [PATCH v5 4/6] x86/microcode/AMD: Check microcode container data in the late loader

On Tue, May 01, 2018 at 06:19:56PM +0200, Maciej S. Szmigiero wrote: > -EINVAL cast to unsigned int is 4294967274 and this value is also > a valid count of bytes to skip that this function can return. And where exactly in the *old* code do we do that? -- Regards/Gruss, Boris. Good mailing

Re: [PATCH] tracing/irqtrace: only call trace_hardirqs_on/off when state changes

On Tue, 1 May 2018 21:48:38 +0200 Peter Zijlstra wrote: > On Tue, May 01, 2018 at 03:38:40PM -0400, Steven Rostedt wrote: > > On Tue, 1 May 2018 21:19:51 +0200 > > Peter Zijlstra wrote: > > > > Now, lockdep only minimally tracks these otherwise

Re: bug-introducing patches

On Tue, May 01, 2018 at 03:44:50PM -0400, Theodore Y. Ts'o wrote: >On Tue, May 01, 2018 at 04:38:21PM +, Sasha Levin wrote: >> - A merge window commit spent 50% more days, on average, in -next than a -rc >>commit. > >So it *used* to be the case that after the merge window, I would queue

Re: [PATCH] tracing/irqtrace: only call trace_hardirqs_on/off when state changes

On Tue, 1 May 2018 21:48:38 +0200 Peter Zijlstra wrote: > On Tue, May 01, 2018 at 03:38:40PM -0400, Steven Rostedt wrote: > > On Tue, 1 May 2018 21:19:51 +0200 > > Peter Zijlstra wrote: > > > > Now, lockdep only minimally tracks these otherwise redundant operations; > > > see

Re: bug-introducing patches

On Tue, May 01, 2018 at 03:44:50PM -0400, Theodore Y. Ts'o wrote: >On Tue, May 01, 2018 at 04:38:21PM +, Sasha Levin wrote: >> - A merge window commit spent 50% more days, on average, in -next than a -rc >>commit. > >So it *used* to be the case that after the merge window, I would queue

Re: [RFC net-next 0/5] Support for PHY test modes

> # echo 4 > /sys/class/net/gphy/operstate > # ip link show gphy > 4: gphy@eth1: mtu 1500 > qdisc noqueue switchid state TESTING mode DEFAULT group default > qlen 1000 > link/ether 00:10:18:de:38:1f brd ff:ff:ff:ff:ff:ff This looks good.

Re: [RFC net-next 0/5] Support for PHY test modes

> # echo 4 > /sys/class/net/gphy/operstate > # ip link show gphy > 4: gphy@eth1: mtu 1500 > qdisc noqueue switchid state TESTING mode DEFAULT group default > qlen 1000 > link/ether 00:10:18:de:38:1f brd ff:ff:ff:ff:ff:ff This looks good. I stopped using ifconfig years ago, so i

Re: perf: fuzzer causes stack going in wrong direction warnings

On Tue, 1 May 2018, Josh Poimboeuf wrote: > Can you try the following patch? I applied the patch, but the warnings don't really look that different. [ 62.220322] WARNING: stack recursion on stack type 4 [ 62.220326] WARNING: can't dereference registers at 9ca2e86d for ip

Re: perf: fuzzer causes stack going in wrong direction warnings

On Tue, 1 May 2018, Josh Poimboeuf wrote: > Can you try the following patch? I applied the patch, but the warnings don't really look that different. [ 62.220322] WARNING: stack recursion on stack type 4 [ 62.220326] WARNING: can't dereference registers at 9ca2e86d for ip

Re: [Regression] PCI / PM: Simplify device wakeup settings code

On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote: > On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury > wrote: > > On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote: > >> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury > >>

Re: [Regression] PCI / PM: Simplify device wakeup settings code

On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote: > On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury > wrote: > > On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote: > >> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury > >> wrote: > >>> On 04/13/2018 05:34 PM, Rafael J. Wysocki

Re: Linux messages full of `random: get_random_u32 called from`

On Mon 2018-04-30 12:11:43, Theodore Y. Ts'o wrote: > On Sun, Apr 29, 2018 at 09:34:45PM -0700, Sultan Alsawaf wrote: > > > > What about abusing high-resolution timers to get entropy? Since hrtimers > > can't > > make guarantees down to the nanosecond, there's always a skew between the > >

Re: Linux messages full of `random: get_random_u32 called from`

On Mon 2018-04-30 12:11:43, Theodore Y. Ts'o wrote: > On Sun, Apr 29, 2018 at 09:34:45PM -0700, Sultan Alsawaf wrote: > > > > What about abusing high-resolution timers to get entropy? Since hrtimers > > can't > > make guarantees down to the nanosecond, there's always a skew between the > >

[PATCH 1/2] iommu/amd - Update the PASID information printed to the system log

Provide detailed data for each event, as appropriate. Signed-off-by: Gary R Hook --- drivers/iommu/amd_iommu.c | 31 +-- 1 file changed, 13 insertions(+), 18 deletions(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index

[PATCH 1/2] iommu/amd - Update the PASID information printed to the system log

Provide detailed data for each event, as appropriate. Signed-off-by: Gary R Hook --- drivers/iommu/amd_iommu.c | 31 +-- 1 file changed, 13 insertions(+), 18 deletions(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index

[PATCH 2/2] iommu/amd - Update logging information for new event type

A new events have been defined in the AMD IOMMU spec: 0x09 - "invalid PPR request" Add support for logging this type of event. Signed-off-by: Gary R Hook ~ ~ ~ --- drivers/iommu/amd_iommu.c | 10 +- drivers/iommu/amd_iommu_types.h |1 + 2 files changed,

[PATCH 2/2] iommu/amd - Update logging information for new event type

A new events have been defined in the AMD IOMMU spec: 0x09 - "invalid PPR request" Add support for logging this type of event. Signed-off-by: Gary R Hook ~ ~ ~ --- drivers/iommu/amd_iommu.c | 10 +- drivers/iommu/amd_iommu_types.h |1 + 2 files changed, 10 insertions(+), 1

[PATCH 0/2] Tweak AMD IOMMU logging

Update the AMD IOMMU log messages to be more precise, and add a log message for a new event type. --- Gary R Hook (2): iommu/amd - Update the PASID information printed to the system log iommu/amd - Update logging information for new event type drivers/iommu/amd_iommu.c |

[PATCH 0/2] Tweak AMD IOMMU logging

Update the AMD IOMMU log messages to be more precise, and add a log message for a new event type. --- Gary R Hook (2): iommu/amd - Update the PASID information printed to the system log iommu/amd - Update logging information for new event type drivers/iommu/amd_iommu.c |

Re: [PATCH v7 4/5] cpuset: Restrict load balancing off cpus to subset of cpus.isolated

Hello, Waiman. Sorry about the delay. On Thu, Apr 19, 2018 at 09:47:03AM -0400, Waiman Long wrote: > With the addition of "cpuset.cpus.isolated", it makes sense to add the > restriction that load balancing can only be turned off if the CPUs in > the isolated cpuset are subset of

Re: [PATCH v7 4/5] cpuset: Restrict load balancing off cpus to subset of cpus.isolated

Hello, Waiman. Sorry about the delay. On Thu, Apr 19, 2018 at 09:47:03AM -0400, Waiman Long wrote: > With the addition of "cpuset.cpus.isolated", it makes sense to add the > restriction that load balancing can only be turned off if the CPUs in > the isolated cpuset are subset of

Re: [PATCH] tracing/irqtrace: only call trace_hardirqs_on/off when state changes

On Tue, May 01, 2018 at 03:38:40PM -0400, Steven Rostedt wrote: > On Tue, 1 May 2018 21:19:51 +0200 > Peter Zijlstra wrote: > > Now, lockdep only minimally tracks these otherwise redundant operations; > > see redundant_hardirqs_{on,off} counters, and loosing that doesn't

Re: [PATCH] tracing/irqtrace: only call trace_hardirqs_on/off when state changes

On Tue, May 01, 2018 at 03:38:40PM -0400, Steven Rostedt wrote: > On Tue, 1 May 2018 21:19:51 +0200 > Peter Zijlstra wrote: > > Now, lockdep only minimally tracks these otherwise redundant operations; > > see redundant_hardirqs_{on,off} counters, and loosing that doesn't seen > > like a big

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

On Tue, May 1, 2018 at 9:12 PM, Ulf Magnusson wrote: > On Tue, May 1, 2018 at 7:56 PM, Randy Dunlap wrote: >> On 04/30/2018 05:57 PM, Ulf Magnusson wrote: >>> Hello, >>> >>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a >>> terminal

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

On Tue, May 1, 2018 at 9:12 PM, Ulf Magnusson wrote: > On Tue, May 1, 2018 at 7:56 PM, Randy Dunlap wrote: >> On 04/30/2018 05:57 PM, Ulf Magnusson wrote: >>> Hello, >>> >>> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a >>> terminal menuconfig implementation, implemented in

Re: bug-introducing patches

On Tue, May 01, 2018 at 04:38:21PM +, Sasha Levin wrote: > - A merge window commit spent 50% more days, on average, in -next than a -rc >commit. So it *used* to be the case that after the merge window, I would queue up bug fixes for the next merge window. Greg K-H pushed for me to send

Re: bug-introducing patches

On Tue, May 01, 2018 at 04:38:21PM +, Sasha Levin wrote: > - A merge window commit spent 50% more days, on average, in -next than a -rc >commit. So it *used* to be the case that after the merge window, I would queue up bug fixes for the next merge window. Greg K-H pushed for me to send

Re: [PATCH] Input: atmel_mxt_ts - add missing compatible strings to OF device table

On Tue, May 1, 2018 at 1:48 PM, Dmitry Torokhov wrote: > On Tue, Apr 10, 2018 at 11:53:40AM +0200, Javier Martinez Canillas wrote: >> Commit af503716ac14 ("i2c: core: report OF style module alias for devices >> registered via OF") fixed how the I2C core reports the

Re: [PATCH] Input: atmel_mxt_ts - add missing compatible strings to OF device table

On Tue, May 1, 2018 at 1:48 PM, Dmitry Torokhov wrote: > On Tue, Apr 10, 2018 at 11:53:40AM +0200, Javier Martinez Canillas wrote: >> Commit af503716ac14 ("i2c: core: report OF style module alias for devices >> registered via OF") fixed how the I2C core reports the module alias when >> devices

Re: [PATCH v2 2/2] hwmon: (k10temp) Use API function to access System Management Network

Hi Guenter, I love your patch! Yet something to improve: [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.17-rc3 next-20180501] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2 2/2] hwmon: (k10temp) Use API function to access System Management Network

Hi Guenter, I love your patch! Yet something to improve: [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.17-rc3 next-20180501] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH] tracing/irqtrace: only call trace_hardirqs_on/off when state changes

On Tue, 1 May 2018 21:19:51 +0200 Peter Zijlstra wrote: > On Tue, May 01, 2018 at 02:46:20PM -0400, Steven Rostedt wrote: > > On Fri, 17 Nov 2017 02:15:06 +1000 > > Nicholas Piggin wrote: > > > > > In local_irq_save and local_irq_restore, only call

Re: [PATCH] tracing/irqtrace: only call trace_hardirqs_on/off when state changes

On Tue, 1 May 2018 21:19:51 +0200 Peter Zijlstra wrote: > On Tue, May 01, 2018 at 02:46:20PM -0400, Steven Rostedt wrote: > > On Fri, 17 Nov 2017 02:15:06 +1000 > > Nicholas Piggin wrote: > > > > > In local_irq_save and local_irq_restore, only call irq tracing when > > > the flag state

[PATCH v2 2/2] pinctrl: generic: improve apply_setting error verbosity

For generic pinconf: print the dev_error with the pinctrl vendor driver name, error code, the sub-node property name used and the pin that was tried to set. Improves the undestading of the error if use a generic sub-node property that generic-pinconf can do parse but the vendor pinctrl driver

[PATCH v2 2/2] pinctrl: generic: improve apply_setting error verbosity

For generic pinconf: print the dev_error with the pinctrl vendor driver name, error code, the sub-node property name used and the pin that was tried to set. Improves the undestading of the error if use a generic sub-node property that generic-pinconf can do parse but the vendor pinctrl driver

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

On Tue, May 1, 2018 at 8:52 PM, Randy Dunlap wrote: > On 05/01/2018 11:13 AM, Randy Dunlap wrote: >> On 05/01/2018 10:56 AM, Randy Dunlap wrote: >>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote: Hello, Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

On Tue, May 1, 2018 at 8:52 PM, Randy Dunlap wrote: > On 05/01/2018 11:13 AM, Randy Dunlap wrote: >> On 05/01/2018 10:56 AM, Randy Dunlap wrote: >>> On 04/30/2018 05:57 PM, Ulf Magnusson wrote: Hello, Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a terminal

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

On Sun, Apr 29, 2018 at 2:36 AM Hans de Goede wrote: > +The EFI embedded-fw code works by scanning all EFI_BOOT_SERVICES_CODE memory > +segments for an eight byte sequence matching prefix, if the prefix is found it > +then does a crc32 over length bytes and if that matches

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

On Sun, Apr 29, 2018 at 2:36 AM Hans de Goede wrote: > +The EFI embedded-fw code works by scanning all EFI_BOOT_SERVICES_CODE memory > +segments for an eight byte sequence matching prefix, if the prefix is found it > +then does a crc32 over length bytes and if that matches makes a copy of length

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

On Tue, 2018-05-01 at 21:11 +0200, Hans de Goede wrote: > Hi, > > On 01-05-18 16:36, Mimi Zohar wrote: > > [Cc'ing linux-security] > > > > On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote: > > [...] > >> diff --git a/drivers/base/firmware_loader/fallback_efi.c > >>

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

On Tue, 2018-05-01 at 21:11 +0200, Hans de Goede wrote: > Hi, > > On 01-05-18 16:36, Mimi Zohar wrote: > > [Cc'ing linux-security] > > > > On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote: > > [...] > >> diff --git a/drivers/base/firmware_loader/fallback_efi.c > >>

Re: [PATCH 4.16 000/113] 4.16.7-stable review

On Tue, May 01, 2018 at 01:05:50PM -0600, Shuah Khan wrote: > On 04/30/2018 01:23 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.16.7 release. > > There are 113 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.16 000/113] 4.16.7-stable review

On Tue, May 01, 2018 at 01:05:50PM -0600, Shuah Khan wrote: > On 04/30/2018 01:23 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.16.7 release. > > There are 113 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH] tracing/irqtrace: only call trace_hardirqs_on/off when state changes

On Tue, May 01, 2018 at 02:46:20PM -0400, Steven Rostedt wrote: > On Fri, 17 Nov 2017 02:15:06 +1000 > Nicholas Piggin wrote: > > > In local_irq_save and local_irq_restore, only call irq tracing when > > the flag state acutally changes. It is not unexpected for the state > >

Re: [PATCH] tracing/irqtrace: only call trace_hardirqs_on/off when state changes

On Tue, May 01, 2018 at 02:46:20PM -0400, Steven Rostedt wrote: > On Fri, 17 Nov 2017 02:15:06 +1000 > Nicholas Piggin wrote: > > > In local_irq_save and local_irq_restore, only call irq tracing when > > the flag state acutally changes. It is not unexpected for the state > > to go

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

On Tue, May 1, 2018 at 7:56 PM, Randy Dunlap wrote: > On 04/30/2018 05:57 PM, Ulf Magnusson wrote: >> Hello, >> >> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a >> terminal menuconfig implementation, implemented in plain curses >> (which is in the Python

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

On Tue, May 1, 2018 at 7:56 PM, Randy Dunlap wrote: > On 04/30/2018 05:57 PM, Ulf Magnusson wrote: >> Hello, >> >> Kconfiglib (https://github.com/ulfalizer/Kconfiglib) now has a >> terminal menuconfig implementation, implemented in plain curses >> (which is in the Python standard library). >> >>

Re: [PATCH net-next 0/9] Misc bug fixes for HNS3 Ethernet driver

From: Salil Mehta Date: Tue, 1 May 2018 19:55:56 +0100 > This patch-set presents some miscellaneous bug fixs and cleanups for > HNS3 Ethernet Driver. Series applied, thank you.

Re: [PATCH net-next 0/9] Misc bug fixes for HNS3 Ethernet driver

From: Salil Mehta Date: Tue, 1 May 2018 19:55:56 +0100 > This patch-set presents some miscellaneous bug fixs and cleanups for > HNS3 Ethernet Driver. Series applied, thank you.

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

Hi, On 01-05-18 16:36, Mimi Zohar wrote: [Cc'ing linux-security] On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote: [...] diff --git a/drivers/base/firmware_loader/fallback_efi.c b/drivers/base/firmware_loader/fallback_efi.c new file mode 100644 index ..82ba82f48a79 ---

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

Hi, On 01-05-18 16:36, Mimi Zohar wrote: [Cc'ing linux-security] On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote: [...] diff --git a/drivers/base/firmware_loader/fallback_efi.c b/drivers/base/firmware_loader/fallback_efi.c new file mode 100644 index ..82ba82f48a79 ---

[PATCH v2 1/2] pinctrl: generic: add API to solve generic sub-node property name

Set dt_params with the definitions of the generic sub-node properties global in pinconf-generic.h and add a function to pinconf-generic API to decode a packed param returning the string name from sub-node property. This can be useful in debug from pinctrl-vendor driver or even for debug in

[PATCH v2 1/2] pinctrl: generic: add API to solve generic sub-node property name

Set dt_params with the definitions of the generic sub-node properties global in pinconf-generic.h and add a function to pinconf-generic API to decode a packed param returning the string name from sub-node property. This can be useful in debug from pinctrl-vendor driver or even for debug in

RE: [PATCH v4 2/3] dt-bindings: mmc: Add binding for BlueField SoC

Thanks! Updated in v5 2/3. > -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Tuesday, May 1, 2018 12:25 PM > To: Liming Sun > Cc: Ulf Hansson ; Mark Rutland > ; Jaehoon Chung

RE: [PATCH v4 2/3] dt-bindings: mmc: Add binding for BlueField SoC

Thanks! Updated in v5 2/3. > -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Tuesday, May 1, 2018 12:25 PM > To: Liming Sun > Cc: Ulf Hansson ; Mark Rutland > ; Jaehoon Chung ; > Catalin Marinas ; Will Deacon > ; linux-...@vger.kernel.org; >

Re: [PATCH v2 0/2] pinctrl: generic: improve apply_setting error verbosity

This series is for improve verbosity in debug for error cases using pinconf generic API. Legacy pinctrl-vendor drivers prints error messages with more verbosity when parse invalid or not supported sub-nodes properties. In this series we try to show messages with more information about the

Re: [PATCH v2 0/2] pinctrl: generic: improve apply_setting error verbosity

This series is for improve verbosity in debug for error cases using pinconf generic API. Legacy pinctrl-vendor drivers prints error messages with more verbosity when parse invalid or not supported sub-nodes properties. In this series we try to show messages with more information about the

Re: [PATCH 4.9 00/61] 4.9.98-stable review

On 04/30/2018 01:24 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.98 release. > There are 61 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 00/61] 4.9.98-stable review

On 04/30/2018 01:24 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.98 release. > There are 61 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/44] 4.4.131-stable review

On 04/30/2018 01:24 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.131 release. > There are 44 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/44] 4.4.131-stable review

On 04/30/2018 01:24 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.131 release. > There are 44 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.14 00/91] 4.14.39-stable review

On 04/30/2018 01:23 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.39 release. > There are 91 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.14 00/91] 4.14.39-stable review

On 04/30/2018 01:23 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.39 release. > There are 91 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.16 000/113] 4.16.7-stable review

On 04/30/2018 01:23 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.7 release. > There are 113 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.16 000/113] 4.16.7-stable review

On 04/30/2018 01:23 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.7 release. > There are 113 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/25] 3.18.108-stable review

On 04/30/2018 01:23 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.108 release. > There are 25 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/25] 3.18.108-stable review

On 04/30/2018 01:23 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.108 release. > There are 25 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH] 1wire: family module autoload fails because of upper/lower case mismatch.

Hi Ingo Sorry for late reply and because of forcing you to resend the patch, your changes are correct 01.05.2018, 17:10, "Ingo Flaschberger" : > 1wire family module autoload fails because of upper/lower >   case mismatch. > > Signed-off-by: Ingo Flaschberger

Re: [PATCH] 1wire: family module autoload fails because of upper/lower case mismatch.

Hi Ingo Sorry for late reply and because of forcing you to resend the patch, your changes are correct 01.05.2018, 17:10, "Ingo Flaschberger" : > 1wire family module autoload fails because of upper/lower >   case mismatch. > > Signed-off-by: Ingo Flaschberger Greg, please pull this patch into

[PATCH net-next 1/9] net: hns3: Remove error log when getting pfc stats fails

From: Yunsheng Lin When mac supports DCB, but is in GE mode, it does not support querying pfc stats, firmware returns error when trying to query the pfc stats. this creates a lot of noise in the kernel log when it prints the error log. This patch fixes it by removing the

[PATCH net-next 1/9] net: hns3: Remove error log when getting pfc stats fails

From: Yunsheng Lin When mac supports DCB, but is in GE mode, it does not support querying pfc stats, firmware returns error when trying to query the pfc stats. this creates a lot of noise in the kernel log when it prints the error log. This patch fixes it by removing the error log, because it

[PATCH net-next 3/9] net: hns3: Fixes the out of bounds access in hclge_map_tqp

From: Huazhong Tan This patch fixes the handling of the check when number of vports are detected to be more than available TPQs. Current handling causes an out of bounds access in hclge_map_tqp(). Fixes: 7df7dad633e2 ("net: hns3: Refactor the mapping of tqp to vport")

[PATCH net-next 3/9] net: hns3: Fixes the out of bounds access in hclge_map_tqp

From: Huazhong Tan This patch fixes the handling of the check when number of vports are detected to be more than available TPQs. Current handling causes an out of bounds access in hclge_map_tqp(). Fixes: 7df7dad633e2 ("net: hns3: Refactor the mapping of tqp to vport") Signed-off-by: Huazhong

[PATCH net-next 2/9] net: hns3: fix to correctly fetch l4 protocol outer header

From: Huazhong Tan This patch fixes the function being used to fetch L4 protocol outer header. Mistakenly skb_inner_transport_header API was being used earlier. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Huazhong

[PATCH net-next 2/9] net: hns3: fix to correctly fetch l4 protocol outer header

From: Huazhong Tan This patch fixes the function being used to fetch L4 protocol outer header. Mistakenly skb_inner_transport_header API was being used earlier. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Huazhong Tan Signed-off-by: Peng

[PATCH net-next 7/9] net: hns3: fix a dead loop in hclge_cmd_csq_clean

From: Huazhong Tan If head has invlid value then a dead loop can be triggered in hclge_cmd_csq_clean. This patch adds sanity check for this case. Fixes: 68c0a5c70614 ("net: hns3: Add HNS3 IMP(Integrated Mgmt Proc) Cmd Interface Support") Signed-off-by: Huazhong Tan

[PATCH net-next 7/9] net: hns3: fix a dead loop in hclge_cmd_csq_clean

From: Huazhong Tan If head has invlid value then a dead loop can be triggered in hclge_cmd_csq_clean. This patch adds sanity check for this case. Fixes: 68c0a5c70614 ("net: hns3: Add HNS3 IMP(Integrated Mgmt Proc) Cmd Interface Support") Signed-off-by: Huazhong Tan Signed-off-by: Peng Li

<    1   2   3   4   5   6   7   8   9   10   >