Re: [PATCH 3.18 00/50] 3.18.64-stable review

On Fri, Aug 04, 2017 at 07:51:07PM -0700, Greg Kroah-Hartman wrote: > On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: > > On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > > > On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: > > > > This is the start of the

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On Fri, Aug 04, 2017 at 07:51:07PM -0700, Greg Kroah-Hartman wrote: > On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: > > On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > > > On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: > > > > This is the start of the

Re: [v4] wlcore: add missing nvs file name info for wilink8

Hi Eyal, On Mon, Jul 31, 2017 at 6:45 PM, Reizer, Eyal wrote: > The following commits: > c815fde wlcore: spi: Populate config firmware data > d776fc8 wlcore: sdio: Populate config firmware data > > Populated the nvs entry for wilink6 and wilink7 only while it is > still needed for

Re: [v4] wlcore: add missing nvs file name info for wilink8

Hi Eyal, On Mon, Jul 31, 2017 at 6:45 PM, Reizer, Eyal wrote: > The following commits: > c815fde wlcore: spi: Populate config firmware data > d776fc8 wlcore: sdio: Populate config firmware data > > Populated the nvs entry for wilink6 and wilink7 only while it is > still needed for wilink8 as

Re: [PATCH v2 7/7] edac drivers: add MC owner check in init

On Fri, Aug 04, 2017 at 09:48:23PM +, Kani, Toshimitsu wrote: > Not sure if anyone cares, but I thought it should return with -ENODEV > when this modules found no target, and -EBUSY when it found a target > but it's busy. Hence, this ordering. You can still return -EBUSY. Just do the owner

Re: [PATCH v2 7/7] edac drivers: add MC owner check in init

On Fri, Aug 04, 2017 at 09:48:23PM +, Kani, Toshimitsu wrote: > Not sure if anyone cares, but I thought it should return with -ENODEV > when this modules found no target, and -EBUSY when it found a target > but it's busy. Hence, this ordering. You can still return -EBUSY. Just do the owner

Re: [PATCH v2 6/7] EDAC: add edac_check_mc_owner() to check MC owner

On Fri, Aug 04, 2017 at 09:35:05PM +, Kani, Toshimitsu wrote: > 1 means the caller's init function can continue its initialization -- > such conditions are free or owned by itself. Make that: edac_get_owner(void) to return the owner string or NULL if there's no owner. The caller

Re: [PATCH v2 6/7] EDAC: add edac_check_mc_owner() to check MC owner

On Fri, Aug 04, 2017 at 09:35:05PM +, Kani, Toshimitsu wrote: > 1 means the caller's init function can continue its initialization -- > such conditions are free or owned by itself. Make that: edac_get_owner(void) to return the owner string or NULL if there's no owner. The caller

Re: [PATCH] f2fs: fix the size value in __check_sit_bitmap

On 2017/8/4 17:07, Yunlong Song wrote: > The current size value is not correct and will miss bitmap check. > > Signed-off-by: Yunlong Song Reviewed-by: Chao Yu > --- > fs/f2fs/segment.c | 7 +-- > 1 file changed, 5 insertions(+), 2

Re: [PATCH] f2fs: fix the size value in __check_sit_bitmap

On 2017/8/4 17:07, Yunlong Song wrote: > The current size value is not correct and will miss bitmap check. > > Signed-off-by: Yunlong Song Reviewed-by: Chao Yu > --- > fs/f2fs/segment.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/fs/f2fs/segment.c

Re: [PATCH v6 2/2] ARM: dts: TS-4600: add basic device tree

On Thu, Aug 03, 2017 at 03:38:15PM -0400, Sebastien Bourdelin wrote: > These device trees add support for the TS-4600 by Technologic Systems. > > More details here: > http://wiki.embeddedarm.com/wiki/TS-4600 > > Signed-off-by: Sebastien Bourdelin >

Re: [PATCH v6 2/2] ARM: dts: TS-4600: add basic device tree

On Thu, Aug 03, 2017 at 03:38:15PM -0400, Sebastien Bourdelin wrote: > These device trees add support for the TS-4600 by Technologic Systems. > > More details here: > http://wiki.embeddedarm.com/wiki/TS-4600 > > Signed-off-by: Sebastien Bourdelin > --- > Changes v5 -> v6: > - rebase on

Re: [PATCH v2 5/7] ghes_edac: add platform check to enable ghes_edac

On Fri, Aug 04, 2017 at 09:06:27PM +, Kani, Toshimitsu wrote: > How about "ghes_edac.any_platform"? ghes_edac.force_load -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --

Re: [PATCH v2 5/7] ghes_edac: add platform check to enable ghes_edac

On Fri, Aug 04, 2017 at 09:06:27PM +, Kani, Toshimitsu wrote: > How about "ghes_edac.any_platform"? ghes_edac.force_load -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --

Re: [PATCH] ARM: dts: i.MX25: add ranges to tscadc

On Thu, Aug 03, 2017 at 06:29:48PM +0200, Martin Kaiser wrote: > Hi Shawn, > > Thus wrote Shawn Guo (shawn...@kernel.org): > > > On Wed, Aug 02, 2017 at 10:06:11PM +0200, Martin Kaiser wrote: > > > Add a ranges; line to the tscadc node. This creates a 1:1 mapping between > > > the addresses used

Re: [PATCH] ARM: dts: i.MX25: add ranges to tscadc

On Thu, Aug 03, 2017 at 06:29:48PM +0200, Martin Kaiser wrote: > Hi Shawn, > > Thus wrote Shawn Guo (shawn...@kernel.org): > > > On Wed, Aug 02, 2017 at 10:06:11PM +0200, Martin Kaiser wrote: > > > Add a ranges; line to the tscadc node. This creates a 1:1 mapping between > > > the addresses used

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Fri, Aug 04, 2017 at 09:02:17PM +, Kani, Toshimitsu wrote: > GHES platform devices correspond to GHES entries, which define firmware > interfaces to report generic memory errors to the OS, such as NMI and > SCI. These devices are associated with all DIMMs, not a particular > DIMM. And?

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

On Fri, Aug 04, 2017 at 09:02:17PM +, Kani, Toshimitsu wrote: > GHES platform devices correspond to GHES entries, which define firmware > interfaces to report generic memory errors to the OS, such as NMI and > SCI. These devices are associated with all DIMMs, not a particular > DIMM. And?

Re: [PATCH v2 3/7] ACPI / APEI: add OSC APEI bit check for ghes_edac

On Fri, Aug 04, 2017 at 08:49:51PM +, Kani, Toshimitsu wrote: > Some firmware features can be enabled / disabled in BIOS. While HPE > firmware does not allow to disable FF, it's possible that other vendors > might allow such and still have the same OEM ID info. Yeah, we don't protect

Re: [PATCH v2 3/7] ACPI / APEI: add OSC APEI bit check for ghes_edac

On Fri, Aug 04, 2017 at 08:49:51PM +, Kani, Toshimitsu wrote: > Some firmware features can be enabled / disabled in BIOS. While HPE > firmware does not allow to disable FF, it's possible that other vendors > might allow such and still have the same OEM ID info. Yeah, we don't protect

Re: [PATCH v2 1/7] ACPI / blacklist: add acpi_match_oemlist() interface

On Fri, Aug 04, 2017 at 08:39:35PM +, Kani, Toshimitsu wrote: > Well, we did talk a lot about your suggested name, "acpi_blacklist", > and I explained that it did not work since it'd be used for both black > and white-list. We've agreed on that. > > You then suggested it's "platform", not

Re: [PATCH v2 1/7] ACPI / blacklist: add acpi_match_oemlist() interface

On Fri, Aug 04, 2017 at 08:39:35PM +, Kani, Toshimitsu wrote: > Well, we did talk a lot about your suggested name, "acpi_blacklist", > and I explained that it did not work since it'd be used for both black > and white-list. We've agreed on that. > > You then suggested it's "platform", not

Re: [PATCH v2 4/5] PCI: mediatek: Add new generation controller support

Hi Honghui, Bjorn, On Fri, 2017-08-04 at 08:18 -0500, Bjorn Helgaas wrote: > On Fri, Aug 04, 2017 at 04:39:36PM +0800, Honghui Zhang wrote: > > On Thu, 2017-08-03 at 17:42 -0500, Bjorn Helgaas wrote: > > > > + > > > > +static struct mtk_pcie_port *mtk_pcie_find_port(struct mtk_pcie *pcie, > > > >

Re: [PATCH v2 4/5] PCI: mediatek: Add new generation controller support

Hi Honghui, Bjorn, On Fri, 2017-08-04 at 08:18 -0500, Bjorn Helgaas wrote: > On Fri, Aug 04, 2017 at 04:39:36PM +0800, Honghui Zhang wrote: > > On Thu, 2017-08-03 at 17:42 -0500, Bjorn Helgaas wrote: > > > > + > > > > +static struct mtk_pcie_port *mtk_pcie_find_port(struct mtk_pcie *pcie, > > > >

[PATCH V3] get_maintainer: Prepare for separate MAINTAINERS files

Allow for MAINTAINERS to become a directory and if it is, read all the files in the directory for maintained sections. Optionally look for all files named MAINTAINERS in directories excluding the .git directory by using --find-maintainer-files. This optional feature adds ~.3 seconds of CPU on an

[PATCH V3] get_maintainer: Prepare for separate MAINTAINERS files

Allow for MAINTAINERS to become a directory and if it is, read all the files in the directory for maintained sections. Optionally look for all files named MAINTAINERS in directories excluding the .git directory by using --find-maintainer-files. This optional feature adds ~.3 seconds of CPU on an

Re: [PATCH 0/3] arm64 xilinx zynqmp firmware interface

> Am 04.08.2017 um 15:45 schrieb Michal Simek : > > Hi, > > xilinx is using this interface for very long time and we can't merge our > driver changes to Linux because of missing communication layer with > firmware. This interface was developed before scpi and scmi was

Re: [PATCH 0/3] arm64 xilinx zynqmp firmware interface

> Am 04.08.2017 um 15:45 schrieb Michal Simek : > > Hi, > > xilinx is using this interface for very long time and we can't merge our > driver changes to Linux because of missing communication layer with > firmware. This interface was developed before scpi and scmi was > available. In

[PATCH 2/2] io_getevents: Use timespec64 to represent timeouts

struct timespec is not y2038 safe. Use y2038 safe struct timespec64 to represent timeouts. The system call interface itself will be changed as part of different series. Timeouts will not really need more than 32 bits. But, replacing these with timespec64 helps verification of a y2038 safe kernel

[PATCH 2/2] io_getevents: Use timespec64 to represent timeouts

struct timespec is not y2038 safe. Use y2038 safe struct timespec64 to represent timeouts. The system call interface itself will be changed as part of different series. Timeouts will not really need more than 32 bits. But, replacing these with timespec64 helps verification of a y2038 safe kernel

[PATCH 1/2] select: Use get/put_timespec64

Usage of these apis and their compat versions makes the syscalls: select family of syscalls and their compat implementations simpler. This is a preparatory patch to isolate data conversions to struct timespec64 at userspace boundaries. This helps contain the changes needed to transition to new

[PATCH 0/2] i/o: Make i/o y2038 safe

This is a preparatory series to make i/o y2038-safe by replacing the use of struct timespec which is not y2038 safe by y2038 safe struct timespec64. Sockets and userspace interfaces themselves will be changed in a separate series. Deepa Dinamani (2): select: Use get/put_timespec64

[PATCH 1/2] select: Use get/put_timespec64

Usage of these apis and their compat versions makes the syscalls: select family of syscalls and their compat implementations simpler. This is a preparatory patch to isolate data conversions to struct timespec64 at userspace boundaries. This helps contain the changes needed to transition to new

[PATCH 0/2] i/o: Make i/o y2038 safe

This is a preparatory series to make i/o y2038-safe by replacing the use of struct timespec which is not y2038 safe by y2038 safe struct timespec64. Sockets and userspace interfaces themselves will be changed in a separate series. Deepa Dinamani (2): select: Use get/put_timespec64

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On 08/04/2017 08:00 PM, Greg Kroah-Hartman wrote: On Fri, Aug 04, 2017 at 07:51:07PM -0700, Greg Kroah-Hartman wrote: On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: On 08/04/2017 04:15 PM, Greg Kroah-Hartman

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On 08/04/2017 08:00 PM, Greg Kroah-Hartman wrote: On Fri, Aug 04, 2017 at 07:51:07PM -0700, Greg Kroah-Hartman wrote: On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: On 08/04/2017 04:15 PM, Greg Kroah-Hartman

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On 08/04/2017 07:46 PM, Greg Kroah-Hartman wrote: On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.64 release. There are 50 patches in this series, all will be posted as a

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On 08/04/2017 07:46 PM, Greg Kroah-Hartman wrote: On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.64 release. There are 50 patches in this series, all will be posted as a

Re: [PATCH] soc: imx: gpcv2: fix regulator deferred probe

On Wed, Aug 02, 2017 at 12:51:29PM -0700, Stefan Agner wrote: > If a regulator requests a deferred probe, the power domain gets > initialized twice. This leads to a list double add (without > list debugging the kernel hangs due to the double add later): > > WARNING: CPU: 0 PID: 19 at

Re: [PATCH] soc: imx: gpcv2: fix regulator deferred probe

On Wed, Aug 02, 2017 at 12:51:29PM -0700, Stefan Agner wrote: > If a regulator requests a deferred probe, the power domain gets > initialized twice. This leads to a list double add (without > list debugging the kernel hangs due to the double add later): > > WARNING: CPU: 0 PID: 19 at

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On Fri, Aug 04, 2017 at 07:51:07PM -0700, Greg Kroah-Hartman wrote: > On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: > > On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > > > On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: > > > > This is the start of the

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On Fri, Aug 04, 2017 at 07:51:07PM -0700, Greg Kroah-Hartman wrote: > On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: > > On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > > > On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: > > > > This is the start of the

Re: [PATCH 4.9 000/105] 4.9.41-stable review

On Fri, Aug 04, 2017 at 07:54:52PM -0700, Randy Dunlap wrote: > On 08/04/2017 07:53 PM, Randy Dunlap wrote: > > On 08/04/2017 04:14 PM, Greg Kroah-Hartman wrote: > >> This is the start of the stable review cycle for the 4.9.41 release. > >> There are 105 patches in this series, all will be posted

Re: [PATCH 4.9 000/105] 4.9.41-stable review

On Fri, Aug 04, 2017 at 07:54:52PM -0700, Randy Dunlap wrote: > On 08/04/2017 07:53 PM, Randy Dunlap wrote: > > On 08/04/2017 04:14 PM, Greg Kroah-Hartman wrote: > >> This is the start of the stable review cycle for the 4.9.41 release. > >> There are 105 patches in this series, all will be posted

Re: [PATCH v5 0/4] ARM: dts: imx: add CX9020 Embedded PC device tree

On Wed, Jul 26, 2017 at 02:05:30PM +0200, linux-kernel-...@beckhoff.com wrote: > Patrick Bruenn (4): > dt-bindings: arm: Add entry for Beckhoff CX9020 > ARM: dts: imx53: add srtc node > ARM: dts: imx53: add alternative UART2 configuration > ARM: dts: imx: add CX9020 Embedded PC device tree

Re: [PATCH v5 0/4] ARM: dts: imx: add CX9020 Embedded PC device tree

On Wed, Jul 26, 2017 at 02:05:30PM +0200, linux-kernel-...@beckhoff.com wrote: > Patrick Bruenn (4): > dt-bindings: arm: Add entry for Beckhoff CX9020 > ARM: dts: imx53: add srtc node > ARM: dts: imx53: add alternative UART2 configuration > ARM: dts: imx: add CX9020 Embedded PC device tree

Re: [PATCH 4.9 000/105] 4.9.41-stable review

On 08/04/2017 07:53 PM, Randy Dunlap wrote: > On 08/04/2017 04:14 PM, Greg Kroah-Hartman wrote: >> This is the start of the stable review cycle for the 4.9.41 release. >> There are 105 patches in this series, all will be posted as a response >> to this one. If anyone has any issues with these

Re: [PATCH 4.9 000/105] 4.9.41-stable review

On 08/04/2017 07:53 PM, Randy Dunlap wrote: > On 08/04/2017 04:14 PM, Greg Kroah-Hartman wrote: >> This is the start of the stable review cycle for the 4.9.41 release. >> There are 105 patches in this series, all will be posted as a response >> to this one. If anyone has any issues with these

Re: [PATCH 4.9 000/105] 4.9.41-stable review

On 08/04/2017 04:14 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.41 release. > There are 105 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 000/105] 4.9.41-stable review

On 08/04/2017 04:14 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.41 release. > There are 105 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/50] 3.18.64-stable review

On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: > On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > > On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 3.18.64 release. > > > There are 50 patches in this

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On Fri, Aug 04, 2017 at 07:46:57PM -0700, Greg Kroah-Hartman wrote: > On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > > On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 3.18.64 release. > > > There are 50 patches in this

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.64 release. > > There are 50 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On Fri, Aug 04, 2017 at 06:43:50PM -0700, Guenter Roeck wrote: > On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.64 release. > > There are 50 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.9 000/105] 4.9.41-stable review

On Fri, Aug 04, 2017 at 07:51:12PM -0600, Shuah Khan wrote: > On 08/04/2017 05:14 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.41 release. > > There are 105 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.9 000/105] 4.9.41-stable review

On Fri, Aug 04, 2017 at 07:51:12PM -0600, Shuah Khan wrote: > On 08/04/2017 05:14 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.41 release. > > There are 105 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On 08/04/2017 05:15 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.64 release. > There are 50 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/50] 3.18.64-stable review

On 08/04/2017 05:15 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.64 release. > There are 50 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/91] 4.4.80-stable review

On 08/04/2017 05:14 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.80 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.4 00/91] 4.4.80-stable review

On 08/04/2017 05:14 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.80 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 v5 0/8] Add board support for TS-4600

On Thu, Aug 03, 2017 at 03:32:36PM -0400, Sebastien Bourdelin wrote: > Hi Shawn, > > Thanks i understand, however if it's ok, i would like to process in the > same time with the TS4600 board bindings and initial dts without the > part related to the nbus and watchdog. > There is no dependencies

Re: [PATCH v5 0/8] Add board support for TS-4600

On Thu, Aug 03, 2017 at 03:32:36PM -0400, Sebastien Bourdelin wrote: > Hi Shawn, > > Thanks i understand, however if it's ok, i would like to process in the > same time with the TS4600 board bindings and initial dts without the > part related to the nbus and watchdog. > There is no dependencies

[PATCH] imon: constify attribute_group structures

Functions working with attribute_groups provided by work with const attribute_group. These attribute_group structures do not change at runtime so mark them as const. File size before: text data bss dec hex filename 3698116776 960 54717d5bd drivers/media/rc/imon.o

[PATCH] imon: constify attribute_group structures

Functions working with attribute_groups provided by work with const attribute_group. These attribute_group structures do not change at runtime so mark them as const. File size before: text data bss dec hex filename 3698116776 960 54717d5bd drivers/media/rc/imon.o

Re: [PATCH 4.9 000/105] 4.9.41-stable review

On 08/04/2017 05:14 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.41 release. > There are 105 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 000/105] 4.9.41-stable review

On 08/04/2017 05:14 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.41 release. > There are 105 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 v5 2/8] ARM: dts: TS-4600: add basic device tree

On Fri, Jul 14, 2017 at 04:32:12PM -0400, Sebastien Bourdelin wrote: > These device trees add support for the TS-4600 by Technologic Systems. > > More details here: > http://wiki.embeddedarm.com/wiki/TS-4600 > > Signed-off-by: Sebastien Bourdelin >

Re: [PATCH v5 2/8] ARM: dts: TS-4600: add basic device tree

On Fri, Jul 14, 2017 at 04:32:12PM -0400, Sebastien Bourdelin wrote: > These device trees add support for the TS-4600 by Technologic Systems. > > More details here: > http://wiki.embeddedarm.com/wiki/TS-4600 > > Signed-off-by: Sebastien Bourdelin > --- > Changes v4 -> v5: > - fix missing

RE: [PATCH] mm, oom: fix potential data corruption when oom_reaper races with writer

> -Original Message- > From: Michal Hocko [mailto:mho...@kernel.org] > Sent: Friday, August 04, 2017 10:57 PM > To: Tetsuo Handa > Cc: linux...@kvack.org; a...@linux-foundation.org; 陶文苇 > ; o...@redhat.com;

RE: [PATCH] mm, oom: fix potential data corruption when oom_reaper races with writer

> -Original Message- > From: Michal Hocko [mailto:mho...@kernel.org] > Sent: Friday, August 04, 2017 10:57 PM > To: Tetsuo Handa > Cc: linux...@kvack.org; a...@linux-foundation.org; 陶文苇 > ; o...@redhat.com; rient...@google.com; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH] mm,

Re:Re: drivers/s390/char/keyboard.c NULL pointer reference

I don't understand a bit,My idea is in userland fd=open("tty3270",O_RDONLY) ... ret=ioctl(fd,KDGKBDIACR,NULL) ... then here drivers/s390/char/keyboard.c 477 case KDGKBDIACR: { struct kbdiacrs __user *a = argp; struct kbdiacr diacr;

Re:Re: drivers/s390/char/keyboard.c NULL pointer reference

I don't understand a bit,My idea is in userland fd=open("tty3270",O_RDONLY) ... ret=ioctl(fd,KDGKBDIACR,NULL) ... then here drivers/s390/char/keyboard.c 477 case KDGKBDIACR: { struct kbdiacrs __user *a = argp; struct kbdiacr diacr;

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.64 release. There are 50 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 should be

Re: [PATCH 3.18 00/50] 3.18.64-stable review

On 08/04/2017 04:15 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.64 release. There are 50 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 should be

[PATCH] thunderbolt: constify attribute_group structure

Functions working with attribute_groups provided by work with const attribute_group. These attribute_group structures do not change at runtime so mark them as const. File size before: text data bss dec hex filename 28565 7300 0 358658c19

[PATCH] thunderbolt: constify attribute_group structure

Functions working with attribute_groups provided by work with const attribute_group. These attribute_group structures do not change at runtime so mark them as const. File size before: text data bss dec hex filename 28565 7300 0 358658c19

Re: [PATCH v6 2/3] ARM: i.MX25: add RNGB node to dtsi

On Sun, Jul 23, 2017 at 07:49:05PM +0200, Martin Kaiser wrote: > From: Steffen Trumtrar > > Add a devicetree entry for the Random Number Generator Version B (RNGB). > The driver for RNGC supports version B as well. > > Signed-off-by: Steffen Trumtrar

Re: [PATCH v6 2/3] ARM: i.MX25: add RNGB node to dtsi

On Sun, Jul 23, 2017 at 07:49:05PM +0200, Martin Kaiser wrote: > From: Steffen Trumtrar > > Add a devicetree entry for the Random Number Generator Version B (RNGB). > The driver for RNGC supports version B as well. > > Signed-off-by: Steffen Trumtrar > Signed-off-by: Martin Kaiser Applied,

Re: [f2fs-dev] [PATCH] f2fs: do not change the valid_block value if cur_valid_map was wrongly set or cleared

On 2017/8/2 22:16, Yunlong Song wrote: > Signed-off-by: Yunlong Song Reviewed-by: Chao Yu > --- > fs/f2fs/segment.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > index 40e40c5..9e3249a 100644

Re: [f2fs-dev] [PATCH] f2fs: do not change the valid_block value if cur_valid_map was wrongly set or cleared

On 2017/8/2 22:16, Yunlong Song wrote: > Signed-off-by: Yunlong Song Reviewed-by: Chao Yu > --- > fs/f2fs/segment.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > index 40e40c5..9e3249a 100644 > --- a/fs/f2fs/segment.c > +++

[PATCH v2 1/4] ipmi: bt-i2c: added documentation for bt-i2c drivers

Added device tree binding documentation for ipmi-bt-i2c (host) and ipmi-bmc-bt-i2c (BMC) and documentation for the Block Transfer over I2C (bt-i2c) protocol. Signed-off-by: Brendan Higgins --- Changes for v2: - Fixed a typo - Reworded a sentence to make it clear

[PATCH v2 1/4] ipmi: bt-i2c: added documentation for bt-i2c drivers

Added device tree binding documentation for ipmi-bt-i2c (host) and ipmi-bmc-bt-i2c (BMC) and documentation for the Block Transfer over I2C (bt-i2c) protocol. Signed-off-by: Brendan Higgins --- Changes for v2: - Fixed a typo - Reworded a sentence to make it clear that I was talking about

[PATCH v2 0/4] ipmi: bt-i2c: added IPMI Block Transfer over I2C

This patchset introduces IPMI Block Transfer over I2C (BT-I2C), which has the same semantics as IPMI Block Transfer except it done over I2C. For the OpenBMC people, this is based on an RFC: https://lists.ozlabs.org/pipermail/openbmc/2016-September/004505.html The documentation discusses the

[PATCH v2 0/4] ipmi: bt-i2c: added IPMI Block Transfer over I2C

This patchset introduces IPMI Block Transfer over I2C (BT-I2C), which has the same semantics as IPMI Block Transfer except it done over I2C. For the OpenBMC people, this is based on an RFC: https://lists.ozlabs.org/pipermail/openbmc/2016-September/004505.html The documentation discusses the

[PATCH v2 2/4] ipmi: bt-i2c: added IPMI Block Transfer over I2C host side

The IPMI definition of the Block Transfer protocol defines the hardware registers and behavior in addition to the message format and messaging semantics. This implements a new protocol that uses IPMI Block Transfer messages and semantics on top of a standard I2C interface. Signed-off-by: Brendan

[PATCH v2 2/4] ipmi: bt-i2c: added IPMI Block Transfer over I2C host side

The IPMI definition of the Block Transfer protocol defines the hardware registers and behavior in addition to the message format and messaging semantics. This implements a new protocol that uses IPMI Block Transfer messages and semantics on top of a standard I2C interface. Signed-off-by: Brendan

[PATCH v2 3/4] ipmi: bt-i2c: added IPMI Block Transfer over I2C BMC side

The IPMI definition of the Block Transfer protocol defines the hardware registers and behavior in addition to the message format and messaging semantics. This implements a new protocol that uses IPMI Block Transfer messages and semantics on top of a standard I2C interface. This protocol has the

[PATCH v2 4/4] ipmi: bt-bmc: move Aspeed IPMI BMC driver to ipmi_bmc

From: Benjamin Fair The ipmi_bmc folder contains drivers for a BMC to communicate using IPMI. The ipmi folder is only for drivers on the host side using the OpenIPMI framework. Signed-off-by: Benjamin Fair Signed-off-by: Brendan Higgins

[PATCH v2 3/4] ipmi: bt-i2c: added IPMI Block Transfer over I2C BMC side

The IPMI definition of the Block Transfer protocol defines the hardware registers and behavior in addition to the message format and messaging semantics. This implements a new protocol that uses IPMI Block Transfer messages and semantics on top of a standard I2C interface. This protocol has the

[PATCH v2 4/4] ipmi: bt-bmc: move Aspeed IPMI BMC driver to ipmi_bmc

From: Benjamin Fair The ipmi_bmc folder contains drivers for a BMC to communicate using IPMI. The ipmi folder is only for drivers on the host side using the OpenIPMI framework. Signed-off-by: Benjamin Fair Signed-off-by: Brendan Higgins --- Added in v2: --- drivers/char/ipmi/Kconfig

[PATCH] nfit, libnvdimm, region: export 'position' in mapping info

It is useful to be able to know the position of a DIMM in an interleave-set. Consider the case where the order of the DIMMs changes causing a namespace to be invalidated because the interleave-set cookie no longer matches. If the before and after state of each DIMM position is known this state

[PATCH] nfit, libnvdimm, region: export 'position' in mapping info

It is useful to be able to know the position of a DIMM in an interleave-set. Consider the case where the order of the DIMMs changes causing a namespace to be invalidated because the interleave-set cookie no longer matches. If the before and after state of each DIMM position is known this state

Re: [PATCH] oom_reaper: close race without using oom_lock

Michal Hocko wrote: > On Wed 26-07-17 20:33:21, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Sun 23-07-17 09:41:50, Tetsuo Handa wrote: > > > > So, how can we verify the above race a real problem? > > > > > > Try to simulate a _real_ workload and see whether we kill more tasks > > > than

Re: [PATCH] oom_reaper: close race without using oom_lock

Michal Hocko wrote: > On Wed 26-07-17 20:33:21, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Sun 23-07-17 09:41:50, Tetsuo Handa wrote: > > > > So, how can we verify the above race a real problem? > > > > > > Try to simulate a _real_ workload and see whether we kill more tasks > > > than

Re: [PATCH net-next 1/3] net: dsa: assign switch device in legacy code

> @@ -251,8 +251,9 @@ dsa_switch_setup(struct dsa_switch_tree *dst, struct > net_device *master, > ds->cd = cd; > ds->ops = ops; > ds->priv = priv; > + ds->dev = parent; Hi Vivien Is this even needed? dsa_switch_alloc() does ds->dev = dev. Andrew

Re: [PATCH net-next 1/3] net: dsa: assign switch device in legacy code

> @@ -251,8 +251,9 @@ dsa_switch_setup(struct dsa_switch_tree *dst, struct > net_device *master, > ds->cd = cd; > ds->ops = ops; > ds->priv = priv; > + ds->dev = parent; Hi Vivien Is this even needed? dsa_switch_alloc() does ds->dev = dev. Andrew

[PATCH v4] drm: kirin: Add mode_valid logic to avoid mode clocks we can't generate

Currently the hikey dsi logic cannot generate accurate byte clocks values for all pixel clock values. Thus if a mode clock is selected that cannot match the calculated byte clock, the device will boot with a blank screen. This patch uses the new mode_valid callback (many thanks to Jose Abreu for

[PATCH v4] drm: kirin: Add mode_valid logic to avoid mode clocks we can't generate

Currently the hikey dsi logic cannot generate accurate byte clocks values for all pixel clock values. Thus if a mode clock is selected that cannot match the calculated byte clock, the device will boot with a blank screen. This patch uses the new mode_valid callback (many thanks to Jose Abreu for

[PATCH] selftests: futex: convert test to use ksft TAP13 framework

Convert test to use ksft TAP13 framework. Signed-off-by: Shuah Khan --- .../selftests/futex/functional/futex_requeue_pi.c| 8 +--- .../functional/futex_requeue_pi_mismatched_ops.c | 3 ++- .../functional/futex_requeue_pi_signal_restart.c | 5 +++--

[PATCH] selftests: futex: convert test to use ksft TAP13 framework

Convert test to use ksft TAP13 framework. Signed-off-by: Shuah Khan --- .../selftests/futex/functional/futex_requeue_pi.c| 8 +--- .../functional/futex_requeue_pi_mismatched_ops.c | 3 ++- .../functional/futex_requeue_pi_signal_restart.c | 5 +++--

  1   2   3   4   5   6   7   8   9   10   >