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

[Willy Tarreau]

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 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 made by Sun Aug  6 23:15:34 UTC 2017.
> > > > Anything received after that time might be too late.
> > > > 
> > > 
> > > Preliminary:
> > > 
> > > Lots of
> > > 
> > > lib/string.c:31:32: fatal error: asm/word-at-a-time.h
> > > 
> > > affecting several architectures.
> > > 
> > > alpha:
> > > 
> > > lib/string.c:217:4: error: implicit declaration of function 
> > > 'zero_bytemask'
> > 
> > Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
> > zero_bytemask() on alpha and tile"), right?  Any other arches failing?
> 
> Hm, that doesn't work, do we care about tile? :)
> 
> Let me see how deep this hole is, I just wanted to get strscpy into 3.18
> to fix a bug...

I suspect you'll need this one which came as part of the strscpy() series
between 4.2 and 4.3 (though I have not tested) :

  commit a6e2f029ae34f41adb6ae3812c32c5d326e1abd2
  Author: Chris Metcalf 
  Date:   Wed Apr 29 12:48:40 2015 -0400

Make asm/word-at-a-time.h available on all architectures

Added the x86 implementation of word-at-a-time to the
generic version, which previously only supported big-endian.
(...)

Willy

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

[Willy Tarreau]

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 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 made by Sun Aug  6 23:15:34 UTC 2017.
> > > > Anything received after that time might be too late.
> > > > 
> > > 
> > > Preliminary:
> > > 
> > > Lots of
> > > 
> > > lib/string.c:31:32: fatal error: asm/word-at-a-time.h
> > > 
> > > affecting several architectures.
> > > 
> > > alpha:
> > > 
> > > lib/string.c:217:4: error: implicit declaration of function 
> > > 'zero_bytemask'
> > 
> > Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
> > zero_bytemask() on alpha and tile"), right?  Any other arches failing?
> 
> Hm, that doesn't work, do we care about tile? :)
> 
> Let me see how deep this hole is, I just wanted to get strscpy into 3.18
> to fix a bug...

I suspect you'll need this one which came as part of the strscpy() series
between 4.2 and 4.3 (though I have not tested) :

  commit a6e2f029ae34f41adb6ae3812c32c5d326e1abd2
  Author: Chris Metcalf 
  Date:   Wed Apr 29 12:48:40 2015 -0400

Make asm/word-at-a-time.h available on all architectures

Added the x86 implementation of word-at-a-time to the
generic version, which previously only supported big-endian.
(...)

Willy

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

[Julian Calaby]

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 well.
> This broke user space backward compatibility when upgrading from older
> kernels, as the alternate mac address would not be read from the nvs that
> is present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin)
> causing mac address change of the wlan interface.
>
> This patch fix this and update the structure field with the same default
> nvs file name that has been used before.
>
> In addition, some distros hold a default wl1271-nvs.bin in the file
> system with a bogus mac address (deadbeef...) that for a wl18xx device
> also overrides the mac address that is stored inside the device.
> Warn users about this bogus mac address and use a random mac instead
>
> Cc: stable 
> Signed-off-by: Eyal Reizer 
> ---
>
> diff --git a/drivers/net/wireless/ti/wlcore/main.c 
> b/drivers/net/wireless/ti/wlcore/main.c
> index 60aaa85..7ce4221 100644
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -5961,6 +5961,22 @@ static void wl12xx_derive_mac_addresses(struct wl1271 
> *wl, u32 oui, u32 nic)
> if (nic + WLCORE_NUM_MAC_ADDRESSES - wl->num_mac_addr > 0xff)
> wl1271_warning("NIC part of the MAC address wraps around!");
>
> +   if (oui == 0xdeadbe && nic == 0xef) {
> +   wl1271_warning("Detected unconfigured mac address in nvs.\n"
> +   "Using a random TI mac address instead.\n"
> +   "in case of using a wl12xx device, your "
> +   "device performance may not be optimized.\n"
> +   "Please use the calibrator tool to configure "
> +   "your device.\n"
> +   "When using a wl18xx device the nvs file can "
> +   "be removed as a default mac address is "
> +   "stored internally.\n");
> +
> +   /* Use TI oui and a random nic */
> +   oui = 0x080028;

Is there (or should there be) a constant for this?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

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

[Julian Calaby]

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 well.
> This broke user space backward compatibility when upgrading from older
> kernels, as the alternate mac address would not be read from the nvs that
> is present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin)
> causing mac address change of the wlan interface.
>
> This patch fix this and update the structure field with the same default
> nvs file name that has been used before.
>
> In addition, some distros hold a default wl1271-nvs.bin in the file
> system with a bogus mac address (deadbeef...) that for a wl18xx device
> also overrides the mac address that is stored inside the device.
> Warn users about this bogus mac address and use a random mac instead
>
> Cc: stable 
> Signed-off-by: Eyal Reizer 
> ---
>
> diff --git a/drivers/net/wireless/ti/wlcore/main.c 
> b/drivers/net/wireless/ti/wlcore/main.c
> index 60aaa85..7ce4221 100644
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -5961,6 +5961,22 @@ static void wl12xx_derive_mac_addresses(struct wl1271 
> *wl, u32 oui, u32 nic)
> if (nic + WLCORE_NUM_MAC_ADDRESSES - wl->num_mac_addr > 0xff)
> wl1271_warning("NIC part of the MAC address wraps around!");
>
> +   if (oui == 0xdeadbe && nic == 0xef) {
> +   wl1271_warning("Detected unconfigured mac address in nvs.\n"
> +   "Using a random TI mac address instead.\n"
> +   "in case of using a wl12xx device, your "
> +   "device performance may not be optimized.\n"
> +   "Please use the calibrator tool to configure "
> +   "your device.\n"
> +   "When using a wl18xx device the nvs file can "
> +   "be removed as a default mac address is "
> +   "stored internally.\n");
> +
> +   /* Use TI oui and a random nic */
> +   oui = 0x080028;

Is there (or should there be) a constant for this?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

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

[Borislav Petkov]

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 check first because if
we're going to return due to ghes_edac being loaded already, we might
just as well skip the other checks as they're a pointless waste of
cycles and energy.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Borislav Petkov]

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 check first because if
we're going to return due to ghes_edac being loaded already, we might
just as well skip the other checks as they're a pointless waste of
cycles and energy.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Borislav Petkov]

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 can then do the string checking and do strncmp() to limit the
string length being checked.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Borislav Petkov]

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 can then do the string checking and do strncmp() to limit the
string length being checked.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Chao Yu]

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 b/fs/f2fs/segment.c
> index f336f8c..45fb534 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -787,11 +787,14 @@ void __check_sit_bitmap(struct f2fs_sb_info *sbi,
>   sentry = get_seg_entry(sbi, segno);
>   offset = GET_BLKOFF_FROM_SEG0(sbi, blk);
>  
> - size = min((unsigned long)(end - blk), max_blocks);
> + if (end < START_BLOCK(sbi, segno + 1))
> + size = GET_BLKOFF_FROM_SEG0(sbi, end);
> + else
> + size = max_blocks;
>   map = (unsigned long *)(sentry->cur_valid_map);
>   offset = __find_rev_next_bit(map, size, offset);
>   f2fs_bug_on(sbi, offset != size);
> - blk += size;
> + blk = START_BLOCK(sbi, segno + 1);
>   }
>  #endif
>  }
> 

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

[Chao Yu]

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 b/fs/f2fs/segment.c
> index f336f8c..45fb534 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -787,11 +787,14 @@ void __check_sit_bitmap(struct f2fs_sb_info *sbi,
>   sentry = get_seg_entry(sbi, segno);
>   offset = GET_BLKOFF_FROM_SEG0(sbi, blk);
>  
> - size = min((unsigned long)(end - blk), max_blocks);
> + if (end < START_BLOCK(sbi, segno + 1))
> + size = GET_BLKOFF_FROM_SEG0(sbi, end);
> + else
> + size = max_blocks;
>   map = (unsigned long *)(sentry->cur_valid_map);
>   offset = __find_rev_next_bit(map, size, offset);
>   f2fs_bug_on(sbi, offset != size);
> - blk += size;
> + blk = START_BLOCK(sbi, segno + 1);
>   }
>  #endif
>  }
> 

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

[Shawn Guo]

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 master
>   - split the previous patch series into series by subsystem

Thanks for splitting the series.  I didn't see this and had the review
comments on v5.  Sorry.

Shawn

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

[Shawn Guo]

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 master
>   - split the previous patch series into series by subsystem

Thanks for splitting the series.  I didn't see this and had the review
comments on v5.  Sorry.

Shawn

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

[Borislav Petkov]

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

[Borislav Petkov]

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

[Shawn Guo]

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 by tscadc and those in its child nodes (adc, tsc).
> 
> > > Without such a mapping, the reg = ... lines in the tsc and adc nodes do
> > > not create a resource. Probing the fsl-imx25-tcq and fsl-imx25-tsadc
> > > drivers will then fail since there's no IORESOURCE_MEM.
> 
> > > Signed-off-by: Martin Kaiser 
> 
> > Do we need the following Fixes tag?
> 
> > Fixes: 92f651f39b42 ("ARM: dts: imx25: Add TSC and ADC support")
> 
> yes, looks like this has never worked correctly.
> 
> If you're ok with the fix, I can add the tag in v2.

I added the Fixes tag and applied the patch.  Thanks.

Shawn

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

[Shawn Guo]

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 by tscadc and those in its child nodes (adc, tsc).
> 
> > > Without such a mapping, the reg = ... lines in the tsc and adc nodes do
> > > not create a resource. Probing the fsl-imx25-tcq and fsl-imx25-tsadc
> > > drivers will then fail since there's no IORESOURCE_MEM.
> 
> > > Signed-off-by: Martin Kaiser 
> 
> > Do we need the following Fixes tag?
> 
> > Fixes: 92f651f39b42 ("ARM: dts: imx25: Add TSC and ADC support")
> 
> yes, looks like this has never worked correctly.
> 
> If you're ok with the fix, I can add the tag in v2.

I added the Fixes tag and applied the patch.  Thanks.

Shawn

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

[Borislav Petkov]

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? Stating the obvious brings you what exactly?

IOW, you still haven't answered my question.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Borislav Petkov]

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? Stating the obvious brings you what exactly?

IOW, you still haven't answered my question.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Borislav Petkov]

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 ourselves against "might allow". Either you have
an *actual* example for such platform or you don't and then you don't
need this check.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Borislav Petkov]

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 ourselves against "might allow". Either you have
an *actual* example for such platform or you don't and then you don't
need this check.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Borislav Petkov]

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 "OEM".  Since this is an ACPI
> structure defined in "acpi.h", its terminology generally follows ACPI
> spec, which I did.
> 
> I understand that you feel strongly against "OEM" (sorry about that). 
> How about "acpi_platform_list"?  Does it work for you?

Yes, I thought we agreed on all that.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Borislav Petkov]

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 "OEM".  Since this is an ACPI
> structure defined in "acpi.h", its terminology generally follows ACPI
> spec, which I did.
> 
> I understand that you feel strongly against "OEM" (sorry about that). 
> How about "acpi_platform_list"?  Does it work for you?

Yes, I thought we agreed on all that.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Ryder Lee]

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,
> > > > +   struct pci_bus *bus, 
> > > > int devfn)
> > > > +{
> > > > +   struct pci_dev *dev;
> > > > +   struct pci_bus *pbus;
> > > > +   struct mtk_pcie_port *port, *tmp;
> > > > +
> > > > +   list_for_each_entry_safe(port, tmp, >ports, list) {
> > > > +   if (bus->number == 0 && port->index == PCI_SLOT(devfn)) 
> > > > {
> > > > +   return port;
> > > > +   } else if (bus->number != 0) {
> > > > +   pbus = bus;
> > > > +   do {
> > > > +   dev = pbus->self;
> > > > +   if (port->index == PCI_SLOT(dev->devfn))
> > > > +   return port;
> > > > +   pbus = dev->bus;
> > > > +   } while (dev->bus->number != 0);
> > > > +   }
> > > > +   }
> > > > +
> > > > +   return NULL;
> > > 
> > > You should be able to use sysdata to avoid searching the list.
> > > See drivers/pci/host/pci-aardvark.c, for example.
> > > 
> > 
> > I could put the mtk_pcie * in sysdata, but still need to searching the
> > list to get the mtk_pcie_port *, how about:
> > 
> > list_for_each_entry_safe(port, tmp, >ports, list) {
> > if (port->index == PCI_SLOT(devfn))
> > return port;
> > }
> 
> No.  Other drivers don't need to search the list.  Please take a look
> at them and see how they solve this problem.  I don't think your
> hardware is fundamentally different in a way that means you need to
> search when the others don't.
> 

I'm not directly involved in this generation, but I guess the main reason why 
Honghui need to do that is just because this hardware access configuration 
space via per-port registers, not just for the guard.  
Currently, We had a host bridge with two ports (two subnodes in binding text), 
thus he tried to tells them apart so that he can get the correct registers.

Some platforms don't need to do that since they just have a single port (no 
more subnodes), the others might have specific/shared registers to access 
configuration space. (e.g. Tegra, MTK legacy IP block).
Or, he can split them into two independent nodes, but it will break common 
probing flow by doing so. (I'd prefer to use subnodes.)

Ryder

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

[Ryder Lee]

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,
> > > > +   struct pci_bus *bus, 
> > > > int devfn)
> > > > +{
> > > > +   struct pci_dev *dev;
> > > > +   struct pci_bus *pbus;
> > > > +   struct mtk_pcie_port *port, *tmp;
> > > > +
> > > > +   list_for_each_entry_safe(port, tmp, >ports, list) {
> > > > +   if (bus->number == 0 && port->index == PCI_SLOT(devfn)) 
> > > > {
> > > > +   return port;
> > > > +   } else if (bus->number != 0) {
> > > > +   pbus = bus;
> > > > +   do {
> > > > +   dev = pbus->self;
> > > > +   if (port->index == PCI_SLOT(dev->devfn))
> > > > +   return port;
> > > > +   pbus = dev->bus;
> > > > +   } while (dev->bus->number != 0);
> > > > +   }
> > > > +   }
> > > > +
> > > > +   return NULL;
> > > 
> > > You should be able to use sysdata to avoid searching the list.
> > > See drivers/pci/host/pci-aardvark.c, for example.
> > > 
> > 
> > I could put the mtk_pcie * in sysdata, but still need to searching the
> > list to get the mtk_pcie_port *, how about:
> > 
> > list_for_each_entry_safe(port, tmp, >ports, list) {
> > if (port->index == PCI_SLOT(devfn))
> > return port;
> > }
> 
> No.  Other drivers don't need to search the list.  Please take a look
> at them and see how they solve this problem.  I don't think your
> hardware is fundamentally different in a way that means you need to
> search when the others don't.
> 

I'm not directly involved in this generation, but I guess the main reason why 
Honghui need to do that is just because this hardware access configuration 
space via per-port registers, not just for the guard.  
Currently, We had a host bridge with two ports (two subnodes in binding text), 
thus he tried to tells them apart so that he can get the correct registers.

Some platforms don't need to do that since they just have a single port (no 
more subnodes), the others might have specific/shared registers to access 
configuration space. (e.g. Tegra, MTK legacy IP block).
Or, he can split them into two independent nodes, but it will break common 
probing flow by doing so. (I'd prefer to use subnodes.)

Ryder

[PATCH V3] get_maintainer: Prepare for separate MAINTAINERS files

[Joe Perches]

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 Intel
i5-6200 with an SSD.

Miscellanea:

o Create a read_maintainer_file subroutine from the existing code
o Test only the existence of MAINTAINERS, not whether it's a file

Signed-off-by: Joe Perches 
---

v2: Search for MAINTAINERS in subdirectories, ignoring .git
v3: Make searching for MAINTAINERS in subdirectories optional

 scripts/get_maintainer.pl | 91 ++-
 1 file changed, 66 insertions(+), 25 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 3bd5f4f30235..bc443201d3ef 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -18,6 +18,7 @@ my $V = '0.26';
 
 use Getopt::Long qw(:config no_auto_abbrev);
 use Cwd;
+use File::Find;
 
 my $cur_path = fastgetcwd() . '/';
 my $lk_path = "./";
@@ -58,6 +59,7 @@ my $from_filename = 0;
 my $pattern_depth = 0;
 my $version = 0;
 my $help = 0;
+my $find_maintainer_files = 0;
 
 my $vcs_used = 0;
 
@@ -249,6 +251,7 @@ if (!GetOptions(
'sections!' => \$sections,
'fe|file-emails!' => \$file_emails,
'f|file' => \$from_filename,
+   'find-maintainer-files' => \$find_maintainer_files,
'v|version' => \$version,
'h|help|usage' => \$help,
)) {
@@ -307,36 +310,74 @@ if (!top_of_kernel_tree($lk_path)) {
 
 my @typevalue = ();
 my %keyword_hash;
+my @mfiles = ();
 
-open (my $maint, '<', "${lk_path}MAINTAINERS")
-or die "$P: Can't open MAINTAINERS: $!\n";
-while (<$maint>) {
-my $line = $_;
-
-if ($line =~ m/^([A-Z]):\s*(.*)/) {
-   my $type = $1;
-   my $value = $2;
-
-   ##Filename pattern matching
-   if ($type eq "F" || $type eq "X") {
-   $value =~ s@\.@\\\.@g;   ##Convert . to \.
-   $value =~ s/\*/\.\*/g;   ##Convert * to .*
-   $value =~ s/\?/\./g; ##Convert ? to .
-   ##if pattern is a directory and it lacks a trailing slash, add one
-   if ((-d $value)) {
-   $value =~ s@([^/])$@$1/@;
+sub read_maintainer_file {
+my ($file) = @_;
+
+open (my $maint, '<', "$file")
+   or die "$P: Can't open MAINTAINERS file '$file': $!\n";
+while (<$maint>) {
+   my $line = $_;
+
+   if ($line =~ m/^([A-Z]):\s*(.*)/) {
+   my $type = $1;
+   my $value = $2;
+
+   ##Filename pattern matching
+   if ($type eq "F" || $type eq "X") {
+   $value =~ s@\.@\\\.@g;   ##Convert . to \.
+   $value =~ s/\*/\.\*/g;   ##Convert * to .*
+   $value =~ s/\?/\./g; ##Convert ? to .
+   ##if pattern is a directory and it lacks a trailing slash, add 
one
+   if ((-d $value)) {
+   $value =~ s@([^/])$@$1/@;
+   }
+   } elsif ($type eq "K") {
+   $keyword_hash{@typevalue} = $value;
}
-   } elsif ($type eq "K") {
-   $keyword_hash{@typevalue} = $value;
+   push(@typevalue, "$type:$value");
+   } elsif (!(/^\s*$/ || /^\s*\#/)) {
+   $line =~ s/\n$//g;
+   push(@typevalue, $line);
}
-   push(@typevalue, "$type:$value");
-} elsif (!/^(\s)*$/) {
-   $line =~ s/\n$//g;
-   push(@typevalue, $line);
 }
+close($maint);
+}
+
+sub find_is_maintainer_file {
+my ($file) = $_;
+return if ($file !~ m@/MAINTAINERS$@);
+$file = $File::Find::name;
+return if (! -f $file);
+push(@mfiles, $file);
 }
-close($maint);
 
+sub find_ignore_git {
+return grep { $_ !~ /^\.git$/; } @_;
+}
+
+if (-d "${lk_path}MAINTAINERS") {
+opendir(DIR, "${lk_path}MAINTAINERS") or die $!;
+my @files = readdir(DIR);
+closedir(DIR);
+foreach my $file (@files) {
+   push(@mfiles, "${lk_path}MAINTAINERS/$file") if ($file !~ /^\./);
+}
+}
+
+if ($find_maintainer_files) {
+find( { wanted => \_is_maintainer_file,
+   preprocess => \_ignore_git,
+   no_chdir => 1,
+   }, "${lk_path}");
+} else {
+push(@mfiles, "${lk_path}MAINTAINERS") if -f "${lk_path}MAINTAINERS";
+}
+
+foreach my $file (@mfiles) {
+read_maintainer_file("$file");
+}
 
 #
 # Read mail address map
@@ -873,7 +914,7 @@ sub top_of_kernel_tree {
 if (   (-f "${lk_path}COPYING")
&& (-f "${lk_path}CREDITS")
&& (-f "${lk_path}Kbuild")
-   && (-f "${lk_path}MAINTAINERS")
+   && (-e "${lk_path}MAINTAINERS")
&& (-f "${lk_path}Makefile")
&& (-f "${lk_path}README")
&& (-d "${lk_path}Documentation")
-- 
2.10.0.rc2.1.g053435c

[PATCH V3] get_maintainer: Prepare for separate MAINTAINERS files

[Joe Perches]

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 Intel
i5-6200 with an SSD.

Miscellanea:

o Create a read_maintainer_file subroutine from the existing code
o Test only the existence of MAINTAINERS, not whether it's a file

Signed-off-by: Joe Perches 
---

v2: Search for MAINTAINERS in subdirectories, ignoring .git
v3: Make searching for MAINTAINERS in subdirectories optional

 scripts/get_maintainer.pl | 91 ++-
 1 file changed, 66 insertions(+), 25 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 3bd5f4f30235..bc443201d3ef 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -18,6 +18,7 @@ my $V = '0.26';
 
 use Getopt::Long qw(:config no_auto_abbrev);
 use Cwd;
+use File::Find;
 
 my $cur_path = fastgetcwd() . '/';
 my $lk_path = "./";
@@ -58,6 +59,7 @@ my $from_filename = 0;
 my $pattern_depth = 0;
 my $version = 0;
 my $help = 0;
+my $find_maintainer_files = 0;
 
 my $vcs_used = 0;
 
@@ -249,6 +251,7 @@ if (!GetOptions(
'sections!' => \$sections,
'fe|file-emails!' => \$file_emails,
'f|file' => \$from_filename,
+   'find-maintainer-files' => \$find_maintainer_files,
'v|version' => \$version,
'h|help|usage' => \$help,
)) {
@@ -307,36 +310,74 @@ if (!top_of_kernel_tree($lk_path)) {
 
 my @typevalue = ();
 my %keyword_hash;
+my @mfiles = ();
 
-open (my $maint, '<', "${lk_path}MAINTAINERS")
-or die "$P: Can't open MAINTAINERS: $!\n";
-while (<$maint>) {
-my $line = $_;
-
-if ($line =~ m/^([A-Z]):\s*(.*)/) {
-   my $type = $1;
-   my $value = $2;
-
-   ##Filename pattern matching
-   if ($type eq "F" || $type eq "X") {
-   $value =~ s@\.@\\\.@g;   ##Convert . to \.
-   $value =~ s/\*/\.\*/g;   ##Convert * to .*
-   $value =~ s/\?/\./g; ##Convert ? to .
-   ##if pattern is a directory and it lacks a trailing slash, add one
-   if ((-d $value)) {
-   $value =~ s@([^/])$@$1/@;
+sub read_maintainer_file {
+my ($file) = @_;
+
+open (my $maint, '<', "$file")
+   or die "$P: Can't open MAINTAINERS file '$file': $!\n";
+while (<$maint>) {
+   my $line = $_;
+
+   if ($line =~ m/^([A-Z]):\s*(.*)/) {
+   my $type = $1;
+   my $value = $2;
+
+   ##Filename pattern matching
+   if ($type eq "F" || $type eq "X") {
+   $value =~ s@\.@\\\.@g;   ##Convert . to \.
+   $value =~ s/\*/\.\*/g;   ##Convert * to .*
+   $value =~ s/\?/\./g; ##Convert ? to .
+   ##if pattern is a directory and it lacks a trailing slash, add 
one
+   if ((-d $value)) {
+   $value =~ s@([^/])$@$1/@;
+   }
+   } elsif ($type eq "K") {
+   $keyword_hash{@typevalue} = $value;
}
-   } elsif ($type eq "K") {
-   $keyword_hash{@typevalue} = $value;
+   push(@typevalue, "$type:$value");
+   } elsif (!(/^\s*$/ || /^\s*\#/)) {
+   $line =~ s/\n$//g;
+   push(@typevalue, $line);
}
-   push(@typevalue, "$type:$value");
-} elsif (!/^(\s)*$/) {
-   $line =~ s/\n$//g;
-   push(@typevalue, $line);
 }
+close($maint);
+}
+
+sub find_is_maintainer_file {
+my ($file) = $_;
+return if ($file !~ m@/MAINTAINERS$@);
+$file = $File::Find::name;
+return if (! -f $file);
+push(@mfiles, $file);
 }
-close($maint);
 
+sub find_ignore_git {
+return grep { $_ !~ /^\.git$/; } @_;
+}
+
+if (-d "${lk_path}MAINTAINERS") {
+opendir(DIR, "${lk_path}MAINTAINERS") or die $!;
+my @files = readdir(DIR);
+closedir(DIR);
+foreach my $file (@files) {
+   push(@mfiles, "${lk_path}MAINTAINERS/$file") if ($file !~ /^\./);
+}
+}
+
+if ($find_maintainer_files) {
+find( { wanted => \_is_maintainer_file,
+   preprocess => \_ignore_git,
+   no_chdir => 1,
+   }, "${lk_path}");
+} else {
+push(@mfiles, "${lk_path}MAINTAINERS") if -f "${lk_path}MAINTAINERS";
+}
+
+foreach my $file (@mfiles) {
+read_maintainer_file("$file");
+}
 
 #
 # Read mail address map
@@ -873,7 +914,7 @@ sub top_of_kernel_tree {
 if (   (-f "${lk_path}COPYING")
&& (-f "${lk_path}CREDITS")
&& (-f "${lk_path}Kbuild")
-   && (-f "${lk_path}MAINTAINERS")
+   && (-e "${lk_path}MAINTAINERS")
&& (-f "${lk_path}Makefile")
&& (-f "${lk_path}README")
&& (-d "${lk_path}Documentation")
-- 
2.10.0.rc2.1.g053435c

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

[Alexander Graf]

> 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 connection to power management scpi and scmi are missing
> pieces which we already use. There is a separate discussion how to
> extend scmi to support all our use cases.
> This simply patch is not adding any power management features but only
> adding minimum functionality which are needed for drivers.

If you're thinking of changing the interface later down the road, wouldn't it 
make sense to probe EL3 for its existence? You could then expose this interface 
on today's EL3 and something scpi/scmi based on tomorrow's.

Alex

> 
> Thanks,
> Michal
> 
> 
> Michal Simek (1):
>  soc: xilinx: zynqmp: Add firmware interface
> 
> Soren Brinkmann (2):
>  dt: xilinx: zynqmp: Add bindings for PM firmware
>  arm64: zynqmp: dt: Add PM firmware node
> 
> .../bindings/soc/xilinx/xlnx,zynqmp-pm.txt |  19 +
> arch/arm64/boot/dts/xilinx/zynqmp.dtsi |   7 +
> drivers/soc/Kconfig|   1 +
> drivers/soc/Makefile   |   1 +
> drivers/soc/xilinx/Kconfig |   6 +
> drivers/soc/xilinx/zynqmp/Makefile |   1 +
> drivers/soc/xilinx/zynqmp/firmware.c   | 419 +
> include/linux/soc/xilinx/zynqmp/firmware.h | 246 
> 8 files changed, 700 insertions(+)
> create mode 100644 
> Documentation/devicetree/bindings/soc/xilinx/xlnx,zynqmp-pm.txt
> create mode 100644 drivers/soc/xilinx/Kconfig
> create mode 100644 drivers/soc/xilinx/zynqmp/Makefile
> create mode 100644 drivers/soc/xilinx/zynqmp/firmware.c
> create mode 100644 include/linux/soc/xilinx/zynqmp/firmware.h
> 
> -- 
> 1.9.1
> 

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

[Alexander Graf]

> 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 connection to power management scpi and scmi are missing
> pieces which we already use. There is a separate discussion how to
> extend scmi to support all our use cases.
> This simply patch is not adding any power management features but only
> adding minimum functionality which are needed for drivers.

If you're thinking of changing the interface later down the road, wouldn't it 
make sense to probe EL3 for its existence? You could then expose this interface 
on today's EL3 and something scpi/scmi based on tomorrow's.

Alex

> 
> Thanks,
> Michal
> 
> 
> Michal Simek (1):
>  soc: xilinx: zynqmp: Add firmware interface
> 
> Soren Brinkmann (2):
>  dt: xilinx: zynqmp: Add bindings for PM firmware
>  arm64: zynqmp: dt: Add PM firmware node
> 
> .../bindings/soc/xilinx/xlnx,zynqmp-pm.txt |  19 +
> arch/arm64/boot/dts/xilinx/zynqmp.dtsi |   7 +
> drivers/soc/Kconfig|   1 +
> drivers/soc/Makefile   |   1 +
> drivers/soc/xilinx/Kconfig |   6 +
> drivers/soc/xilinx/zynqmp/Makefile |   1 +
> drivers/soc/xilinx/zynqmp/firmware.c   | 419 +
> include/linux/soc/xilinx/zynqmp/firmware.h | 246 
> 8 files changed, 700 insertions(+)
> create mode 100644 
> Documentation/devicetree/bindings/soc/xilinx/xlnx,zynqmp-pm.txt
> create mode 100644 drivers/soc/xilinx/Kconfig
> create mode 100644 drivers/soc/xilinx/zynqmp/Makefile
> create mode 100644 drivers/soc/xilinx/zynqmp/firmware.c
> create mode 100644 include/linux/soc/xilinx/zynqmp/firmware.h
> 
> -- 
> 1.9.1
> 

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

[Deepa Dinamani]

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 by getting rid of timespec
internally.

Signed-off-by: Deepa Dinamani 
Cc: linux-...@kvack.org
---
 fs/aio.c | 55 ++-
 1 file changed, 30 insertions(+), 25 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 8f0127526299..7ca6b7a00368 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1289,20 +1289,10 @@ static bool aio_read_events(struct kioctx *ctx, long 
min_nr, long nr,
 
 static long read_events(struct kioctx *ctx, long min_nr, long nr,
struct io_event __user *event,
-   struct timespec __user *timeout)
+   ktime_t until)
 {
-   ktime_t until = KTIME_MAX;
long ret = 0;
 
-   if (timeout) {
-   struct timespec ts;
-
-   if (unlikely(copy_from_user(, timeout, sizeof(ts
-   return -EFAULT;
-
-   until = timespec_to_ktime(ts);
-   }
-
/*
 * Note that aio_read_events() is being called as the conditional - i.e.
 * we're calling it after prepare_to_wait() has set task state to
@@ -1824,6 +1814,25 @@ SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id, struct 
iocb __user *, iocb,
return ret;
 }
 
+static long do_io_getevents(aio_context_t ctx_id,
+   long min_nr,
+   long nr,
+   struct io_event __user *events,
+   struct timespec64 *ts)
+{
+   ktime_t until = ts ? timespec64_to_ktime(*ts) : KTIME_MAX;
+   struct kioctx *ioctx = lookup_ioctx(ctx_id);
+   long ret = -EINVAL;
+
+   if (likely(ioctx)) {
+   if (likely(min_nr <= nr && min_nr >= 0))
+   ret = read_events(ioctx, min_nr, nr, events, until);
+   percpu_ref_put(>users);
+   }
+
+   return ret;
+}
+
 /* io_getevents:
  * Attempts to read at least min_nr events and up to nr events from
  * the completion queue for the aio_context specified by ctx_id. If
@@ -1842,15 +1851,14 @@ SYSCALL_DEFINE5(io_getevents, aio_context_t, ctx_id,
struct io_event __user *, events,
struct timespec __user *, timeout)
 {
-   struct kioctx *ioctx = lookup_ioctx(ctx_id);
-   long ret = -EINVAL;
+   struct timespec64   ts;
 
-   if (likely(ioctx)) {
-   if (likely(min_nr <= nr && min_nr >= 0))
-   ret = read_events(ioctx, min_nr, nr, events, timeout);
-   percpu_ref_put(>users);
+   if (timeout) {
+   if (unlikely(get_timespec64(, timeout)))
+   return -EFAULT;
}
-   return ret;
+
+   return do_io_getevents(ctx_id, min_nr, nr, events, timeout ?  : 
NULL);
 }
 
 #ifdef CONFIG_COMPAT
@@ -1860,17 +1868,14 @@ COMPAT_SYSCALL_DEFINE5(io_getevents, 
compat_aio_context_t, ctx_id,
   struct io_event __user *, events,
   struct compat_timespec __user *, timeout)
 {
-   struct timespec t;
-   struct timespec __user *ut = NULL;
+   struct timespec64 t;
 
if (timeout) {
-   if (compat_get_timespec(, timeout))
+   if (compat_get_timespec64(, timeout))
return -EFAULT;
 
-   ut = compat_alloc_user_space(sizeof(*ut));
-   if (copy_to_user(ut, , sizeof(t)))
-   return -EFAULT;
}
-   return sys_io_getevents(ctx_id, min_nr, nr, events, ut);
+
+   return do_io_getevents(ctx_id, min_nr, nr, events, timeout ?  : NULL);
 }
 #endif
-- 
2.11.0

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

[Deepa Dinamani]

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 by getting rid of timespec
internally.

Signed-off-by: Deepa Dinamani 
Cc: linux-...@kvack.org
---
 fs/aio.c | 55 ++-
 1 file changed, 30 insertions(+), 25 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 8f0127526299..7ca6b7a00368 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1289,20 +1289,10 @@ static bool aio_read_events(struct kioctx *ctx, long 
min_nr, long nr,
 
 static long read_events(struct kioctx *ctx, long min_nr, long nr,
struct io_event __user *event,
-   struct timespec __user *timeout)
+   ktime_t until)
 {
-   ktime_t until = KTIME_MAX;
long ret = 0;
 
-   if (timeout) {
-   struct timespec ts;
-
-   if (unlikely(copy_from_user(, timeout, sizeof(ts
-   return -EFAULT;
-
-   until = timespec_to_ktime(ts);
-   }
-
/*
 * Note that aio_read_events() is being called as the conditional - i.e.
 * we're calling it after prepare_to_wait() has set task state to
@@ -1824,6 +1814,25 @@ SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id, struct 
iocb __user *, iocb,
return ret;
 }
 
+static long do_io_getevents(aio_context_t ctx_id,
+   long min_nr,
+   long nr,
+   struct io_event __user *events,
+   struct timespec64 *ts)
+{
+   ktime_t until = ts ? timespec64_to_ktime(*ts) : KTIME_MAX;
+   struct kioctx *ioctx = lookup_ioctx(ctx_id);
+   long ret = -EINVAL;
+
+   if (likely(ioctx)) {
+   if (likely(min_nr <= nr && min_nr >= 0))
+   ret = read_events(ioctx, min_nr, nr, events, until);
+   percpu_ref_put(>users);
+   }
+
+   return ret;
+}
+
 /* io_getevents:
  * Attempts to read at least min_nr events and up to nr events from
  * the completion queue for the aio_context specified by ctx_id. If
@@ -1842,15 +1851,14 @@ SYSCALL_DEFINE5(io_getevents, aio_context_t, ctx_id,
struct io_event __user *, events,
struct timespec __user *, timeout)
 {
-   struct kioctx *ioctx = lookup_ioctx(ctx_id);
-   long ret = -EINVAL;
+   struct timespec64   ts;
 
-   if (likely(ioctx)) {
-   if (likely(min_nr <= nr && min_nr >= 0))
-   ret = read_events(ioctx, min_nr, nr, events, timeout);
-   percpu_ref_put(>users);
+   if (timeout) {
+   if (unlikely(get_timespec64(, timeout)))
+   return -EFAULT;
}
-   return ret;
+
+   return do_io_getevents(ctx_id, min_nr, nr, events, timeout ?  : 
NULL);
 }
 
 #ifdef CONFIG_COMPAT
@@ -1860,17 +1868,14 @@ COMPAT_SYSCALL_DEFINE5(io_getevents, 
compat_aio_context_t, ctx_id,
   struct io_event __user *, events,
   struct compat_timespec __user *, timeout)
 {
-   struct timespec t;
-   struct timespec __user *ut = NULL;
+   struct timespec64 t;
 
if (timeout) {
-   if (compat_get_timespec(, timeout))
+   if (compat_get_timespec64(, timeout))
return -EFAULT;
 
-   ut = compat_alloc_user_space(sizeof(*ut));
-   if (copy_to_user(ut, , sizeof(t)))
-   return -EFAULT;
}
-   return sys_io_getevents(ctx_id, min_nr, nr, events, ut);
+
+   return do_io_getevents(ctx_id, min_nr, nr, events, timeout ?  : NULL);
 }
 #endif
-- 
2.11.0

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

[Deepa Dinamani]

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 y2038 safe types.

Signed-off-by: Deepa Dinamani 
---
 fs/select.c | 60 
 1 file changed, 24 insertions(+), 36 deletions(-)

diff --git a/fs/select.c b/fs/select.c
index 9d5f15ed87fe..0cf17fb33cf7 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -291,8 +291,7 @@ static int poll_select_copy_remaining(struct timespec64 
*end_time,
  void __user *p,
  int timeval, int ret)
 {
-   struct timespec64 rts64;
-   struct timespec rts;
+   struct timespec64 rts;
struct timeval rtv;
 
if (!p)
@@ -305,23 +304,22 @@ static int poll_select_copy_remaining(struct timespec64 
*end_time,
if (!end_time->tv_sec && !end_time->tv_nsec)
return ret;
 
-   ktime_get_ts64();
-   rts64 = timespec64_sub(*end_time, rts64);
-   if (rts64.tv_sec < 0)
-   rts64.tv_sec = rts64.tv_nsec = 0;
+   ktime_get_ts64();
+   rts = timespec64_sub(*end_time, rts);
+   if (rts.tv_sec < 0)
+   rts.tv_sec = rts.tv_nsec = 0;
 
-   rts = timespec64_to_timespec(rts64);
 
if (timeval) {
if (sizeof(rtv) > sizeof(rtv.tv_sec) + sizeof(rtv.tv_usec))
memset(, 0, sizeof(rtv));
-   rtv.tv_sec = rts64.tv_sec;
-   rtv.tv_usec = rts64.tv_nsec / NSEC_PER_USEC;
+   rtv.tv_sec = rts.tv_sec;
+   rtv.tv_usec = rts.tv_nsec / NSEC_PER_USEC;
 
if (!copy_to_user(p, , sizeof(rtv)))
return ret;
 
-   } else if (!copy_to_user(p, , sizeof(rts)))
+   } else if (!put_timespec64(, p))
return ret;
 
/*
@@ -704,17 +702,15 @@ static long do_pselect(int n, fd_set __user *inp, fd_set 
__user *outp,
   const sigset_t __user *sigmask, size_t sigsetsize)
 {
sigset_t ksigmask, sigsaved;
-   struct timespec ts;
-   struct timespec64 ts64, end_time, *to = NULL;
+   struct timespec64 ts, end_time, *to = NULL;
int ret;
 
if (tsp) {
-   if (copy_from_user(, tsp, sizeof(ts)))
+   if (get_timespec64(, tsp))
return -EFAULT;
-   ts64 = timespec_to_timespec64(ts);
 
to = _time;
-   if (poll_select_set_timeout(to, ts64.tv_sec, ts64.tv_nsec))
+   if (poll_select_set_timeout(to, ts.tv_sec, ts.tv_nsec))
return -EINVAL;
}
 
@@ -1051,12 +1047,11 @@ SYSCALL_DEFINE5(ppoll, struct pollfd __user *, ufds, 
unsigned int, nfds,
size_t, sigsetsize)
 {
sigset_t ksigmask, sigsaved;
-   struct timespec ts;
-   struct timespec64 end_time, *to = NULL;
+   struct timespec64 ts, end_time, *to = NULL;
int ret;
 
if (tsp) {
-   if (copy_from_user(, tsp, sizeof(ts)))
+   if (get_timespec64(, tsp))
return -EFAULT;
 
to = _time;
@@ -1102,10 +1097,10 @@ SYSCALL_DEFINE5(ppoll, struct pollfd __user *, ufds, 
unsigned int, nfds,
 #define __COMPAT_NFDBITS   (8 * sizeof(compat_ulong_t))
 
 static
-int compat_poll_select_copy_remaining(struct timespec *end_time, void __user 
*p,
+int compat_poll_select_copy_remaining(struct timespec64 *end_time, void __user 
*p,
  int timeval, int ret)
 {
-   struct timespec ts;
+   struct timespec64 ts;
 
if (!p)
return ret;
@@ -1117,8 +1112,8 @@ int compat_poll_select_copy_remaining(struct timespec 
*end_time, void __user *p,
if (!end_time->tv_sec && !end_time->tv_nsec)
return ret;
 
-   ktime_get_ts();
-   ts = timespec_sub(*end_time, ts);
+   ktime_get_ts64();
+   ts = timespec64_sub(*end_time, ts);
if (ts.tv_sec < 0)
ts.tv_sec = ts.tv_nsec = 0;
 
@@ -1131,12 +1126,7 @@ int compat_poll_select_copy_remaining(struct timespec 
*end_time, void __user *p,
if (!copy_to_user(p, , sizeof(rtv)))
return ret;
} else {
-   struct compat_timespec rts;
-
-   rts.tv_sec = ts.tv_sec;
-   rts.tv_nsec = ts.tv_nsec;
-
-   if (!copy_to_user(p, , sizeof(rts)))
+   if (!compat_put_timespec64(, p))
return ret;
}
/*
@@ -1198,7 +1188,7 @@ int compat_set_fd_set(unsigned long nr, compat_ulong_t 
__user *ufdset,
  */
 static int compat_core_sys_select(int n, compat_ulong_t __user *inp,
compat_ulong_t __user *outp, compat_ulong_t 

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

[Deepa Dinamani]

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
  io_getevents: Use timespec64 to represent timeouts

 fs/aio.c| 55 ++-
 fs/select.c | 60 
 2 files changed, 54 insertions(+), 61 deletions(-)

-- 
2.11.0

Cc: linux-...@kvack.org

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

[Deepa Dinamani]

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 y2038 safe types.

Signed-off-by: Deepa Dinamani 
---
 fs/select.c | 60 
 1 file changed, 24 insertions(+), 36 deletions(-)

diff --git a/fs/select.c b/fs/select.c
index 9d5f15ed87fe..0cf17fb33cf7 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -291,8 +291,7 @@ static int poll_select_copy_remaining(struct timespec64 
*end_time,
  void __user *p,
  int timeval, int ret)
 {
-   struct timespec64 rts64;
-   struct timespec rts;
+   struct timespec64 rts;
struct timeval rtv;
 
if (!p)
@@ -305,23 +304,22 @@ static int poll_select_copy_remaining(struct timespec64 
*end_time,
if (!end_time->tv_sec && !end_time->tv_nsec)
return ret;
 
-   ktime_get_ts64();
-   rts64 = timespec64_sub(*end_time, rts64);
-   if (rts64.tv_sec < 0)
-   rts64.tv_sec = rts64.tv_nsec = 0;
+   ktime_get_ts64();
+   rts = timespec64_sub(*end_time, rts);
+   if (rts.tv_sec < 0)
+   rts.tv_sec = rts.tv_nsec = 0;
 
-   rts = timespec64_to_timespec(rts64);
 
if (timeval) {
if (sizeof(rtv) > sizeof(rtv.tv_sec) + sizeof(rtv.tv_usec))
memset(, 0, sizeof(rtv));
-   rtv.tv_sec = rts64.tv_sec;
-   rtv.tv_usec = rts64.tv_nsec / NSEC_PER_USEC;
+   rtv.tv_sec = rts.tv_sec;
+   rtv.tv_usec = rts.tv_nsec / NSEC_PER_USEC;
 
if (!copy_to_user(p, , sizeof(rtv)))
return ret;
 
-   } else if (!copy_to_user(p, , sizeof(rts)))
+   } else if (!put_timespec64(, p))
return ret;
 
/*
@@ -704,17 +702,15 @@ static long do_pselect(int n, fd_set __user *inp, fd_set 
__user *outp,
   const sigset_t __user *sigmask, size_t sigsetsize)
 {
sigset_t ksigmask, sigsaved;
-   struct timespec ts;
-   struct timespec64 ts64, end_time, *to = NULL;
+   struct timespec64 ts, end_time, *to = NULL;
int ret;
 
if (tsp) {
-   if (copy_from_user(, tsp, sizeof(ts)))
+   if (get_timespec64(, tsp))
return -EFAULT;
-   ts64 = timespec_to_timespec64(ts);
 
to = _time;
-   if (poll_select_set_timeout(to, ts64.tv_sec, ts64.tv_nsec))
+   if (poll_select_set_timeout(to, ts.tv_sec, ts.tv_nsec))
return -EINVAL;
}
 
@@ -1051,12 +1047,11 @@ SYSCALL_DEFINE5(ppoll, struct pollfd __user *, ufds, 
unsigned int, nfds,
size_t, sigsetsize)
 {
sigset_t ksigmask, sigsaved;
-   struct timespec ts;
-   struct timespec64 end_time, *to = NULL;
+   struct timespec64 ts, end_time, *to = NULL;
int ret;
 
if (tsp) {
-   if (copy_from_user(, tsp, sizeof(ts)))
+   if (get_timespec64(, tsp))
return -EFAULT;
 
to = _time;
@@ -1102,10 +1097,10 @@ SYSCALL_DEFINE5(ppoll, struct pollfd __user *, ufds, 
unsigned int, nfds,
 #define __COMPAT_NFDBITS   (8 * sizeof(compat_ulong_t))
 
 static
-int compat_poll_select_copy_remaining(struct timespec *end_time, void __user 
*p,
+int compat_poll_select_copy_remaining(struct timespec64 *end_time, void __user 
*p,
  int timeval, int ret)
 {
-   struct timespec ts;
+   struct timespec64 ts;
 
if (!p)
return ret;
@@ -1117,8 +1112,8 @@ int compat_poll_select_copy_remaining(struct timespec 
*end_time, void __user *p,
if (!end_time->tv_sec && !end_time->tv_nsec)
return ret;
 
-   ktime_get_ts();
-   ts = timespec_sub(*end_time, ts);
+   ktime_get_ts64();
+   ts = timespec64_sub(*end_time, ts);
if (ts.tv_sec < 0)
ts.tv_sec = ts.tv_nsec = 0;
 
@@ -1131,12 +1126,7 @@ int compat_poll_select_copy_remaining(struct timespec 
*end_time, void __user *p,
if (!copy_to_user(p, , sizeof(rtv)))
return ret;
} else {
-   struct compat_timespec rts;
-
-   rts.tv_sec = ts.tv_sec;
-   rts.tv_nsec = ts.tv_nsec;
-
-   if (!copy_to_user(p, , sizeof(rts)))
+   if (!compat_put_timespec64(, p))
return ret;
}
/*
@@ -1198,7 +1188,7 @@ int compat_set_fd_set(unsigned long nr, compat_ulong_t 
__user *ufdset,
  */
 static int compat_core_sys_select(int n, compat_ulong_t __user *inp,
compat_ulong_t __user *outp, compat_ulong_t __user *exp,
-   

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

[Deepa Dinamani]

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
  io_getevents: Use timespec64 to represent timeouts

 fs/aio.c| 55 ++-
 fs/select.c | 60 
 2 files changed, 54 insertions(+), 61 deletions(-)

-- 
2.11.0

Cc: linux-...@kvack.org

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

[Guenter Roeck]

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 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 made by Sun Aug  6 23:15:34 UTC 2017.
Anything received after that time might be too late.



Preliminary:

Lots of

lib/string.c:31:32: fatal error: asm/word-at-a-time.h

affecting several architectures.

alpha:

lib/string.c:217:4: error: implicit declaration of function 'zero_bytemask'


Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
zero_bytemask() on alpha and tile"), right?  Any other arches failing?


Hm, that doesn't work, do we care about tile? :)

Let me see how deep this hole is, I just wanted to get strscpy into 3.18
to fix a bug...


Ok, I think tile and alpha should be fixed, is there anything else that
is broken?



Did you get my e-mail ? I sent it a couple of minutes ago.

Guenter

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

[Guenter Roeck]

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 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 made by Sun Aug  6 23:15:34 UTC 2017.
Anything received after that time might be too late.



Preliminary:

Lots of

lib/string.c:31:32: fatal error: asm/word-at-a-time.h

affecting several architectures.

alpha:

lib/string.c:217:4: error: implicit declaration of function 'zero_bytemask'


Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
zero_bytemask() on alpha and tile"), right?  Any other arches failing?


Hm, that doesn't work, do we care about tile? :)

Let me see how deep this hole is, I just wanted to get strscpy into 3.18
to fix a bug...


Ok, I think tile and alpha should be fixed, is there anything else that
is broken?



Did you get my e-mail ? I sent it a couple of minutes ago.

Guenter

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

[Guenter Roeck]

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 response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Aug  6 23:15:34 UTC 2017.
Anything received after that time might be too late.



Preliminary:

Lots of

lib/string.c:31:32: fatal error: asm/word-at-a-time.h

affecting several architectures.

alpha:

lib/string.c:217:4: error: implicit declaration of function 'zero_bytemask'


Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
zero_bytemask() on alpha and tile"), right?  Any other arches failing?



Yes, you could say so. Is the offending patch really needed ?

Guenter

total: 136 pass: 68 fail: 68
Failed builds:
alpha:defconfig
alpha:allmodconfig
alpha:allnoconfig
arc:defconfig
arc:allnoconfig
arc:tb10x_defconfig
blackfin:defconfig
blackfin:BF561-EZKIT-SMP_defconfig
c6x:dsk6455_defconfig
c6x:evmc6457_defconfig
c6x:evmc6678_defconfig
cris:defconfig
cris:allnoconfig
cris:etrax-100lx_defconfig
cris:artpec_3_defconfig
cris:etraxfs_defconfig
frv:defconfig
hexagon:defconfig
hexagon:allnoconfig
ia64:defconfig
ia64:allnoconfig
m32r:defconfig
metag:defconfig
metag:allnoconfig
metag:meta1_defconfig
metag:meta2_defconfig
metag:meta2_smp_defconfig
microblaze:mmu_defconfig
microblaze:nommu_defconfig
microblaze:allnoconfig
mips:defconfig
mips:allnoconfig
mips:defconfig
mips:allmodconfig
mips:allnoconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
mips:rt305x_defconfig
mn10300:asb2303_defconfig
mn10300:asb2364_defconfig
powerpc:defconfig
powerpc:allmodconfig
powerpc:allnoconfig
powerpc:ppc64e_defconfig
powerpc:cell_defconfig
powerpc:maple_defconfig
powerpc:ppc6xx_defconfig
powerpc:mpc83xx_defconfig
powerpc:tqm8xx_defconfig
powerpc:85xx/sbc8548_defconfig
powerpc:83xx/mpc834x_mds_defconfig
powerpc:86xx/sbc8641d_defconfig
s390:defconfig
s390:allmodconfig
s390:allnoconfig
score:defconfig
tile:tilegx_defconfig
unicore32:defconfig
unicore32:allnoconfig
xtensa:defconfig
xtensa:allmodconfig
xtensa:allnoconfig

Qemu:

total: 111 pass: 78 fail: 33
Failed tests:
alpha:defconfig
metag:meta2_defconfig
metag:tz1090_defconfig
microblaze:microblaze_defconfig
microblaze:microblazeel_defconfig
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips64:malta_defconfig:nosmp
mips64:malta_defconfig:smp
mipsel:24Kf:malta_defconfig:nosmp
mipsel:24Kf:malta_defconfig:smp
mipsel64:malta_defconfig:nosmp
mipsel64:malta_defconfig:smp
mipsel64:fuloong2e_defconfig:fulong2e
powerpc:mac99:nosmp:ppc_book3s_defconfig
powerpc:g3beige:nosmp:ppc_book3s_defconfig
powerpc:mac99:smp:ppc_book3s_defconfig
powerpc:virtex-ml507:44x/virtex5_defconfig
powerpc:mpc8544ds:mpc85xx_defconfig
powerpc:mpc8544ds:mpc85xx_smp_defconfig
powerpc:mpc8548cds:85xx/mpc85xx_cds_defconfig
powerpc:mpc8548cds:smpdev:85xx/mpc85xx_cds_defconfig
powerpc:bamboo:44x/bamboo_defconfig
powerpc:mac99:ppc64_book3s_defconfig:nosmp
powerpc:mac99:ppc64_book3s_defconfig:smp4
powerpc:pseries:pseries_defconfig
powerpc:mpc8544ds:ppc64_e5500_defconfig:nosmp
powerpc:mpc8544ds:ppc64_e5500_defconfig:smp
s390:defconfig
xtensa:dc232b:lx60:generic_kc705_defconfig
xtensa:dc232b:kc705:generic_kc705_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfig

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

[Guenter Roeck]

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 response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Aug  6 23:15:34 UTC 2017.
Anything received after that time might be too late.



Preliminary:

Lots of

lib/string.c:31:32: fatal error: asm/word-at-a-time.h

affecting several architectures.

alpha:

lib/string.c:217:4: error: implicit declaration of function 'zero_bytemask'


Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
zero_bytemask() on alpha and tile"), right?  Any other arches failing?



Yes, you could say so. Is the offending patch really needed ?

Guenter

total: 136 pass: 68 fail: 68
Failed builds:
alpha:defconfig
alpha:allmodconfig
alpha:allnoconfig
arc:defconfig
arc:allnoconfig
arc:tb10x_defconfig
blackfin:defconfig
blackfin:BF561-EZKIT-SMP_defconfig
c6x:dsk6455_defconfig
c6x:evmc6457_defconfig
c6x:evmc6678_defconfig
cris:defconfig
cris:allnoconfig
cris:etrax-100lx_defconfig
cris:artpec_3_defconfig
cris:etraxfs_defconfig
frv:defconfig
hexagon:defconfig
hexagon:allnoconfig
ia64:defconfig
ia64:allnoconfig
m32r:defconfig
metag:defconfig
metag:allnoconfig
metag:meta1_defconfig
metag:meta2_defconfig
metag:meta2_smp_defconfig
microblaze:mmu_defconfig
microblaze:nommu_defconfig
microblaze:allnoconfig
mips:defconfig
mips:allnoconfig
mips:defconfig
mips:allmodconfig
mips:allnoconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
mips:rt305x_defconfig
mn10300:asb2303_defconfig
mn10300:asb2364_defconfig
powerpc:defconfig
powerpc:allmodconfig
powerpc:allnoconfig
powerpc:ppc64e_defconfig
powerpc:cell_defconfig
powerpc:maple_defconfig
powerpc:ppc6xx_defconfig
powerpc:mpc83xx_defconfig
powerpc:tqm8xx_defconfig
powerpc:85xx/sbc8548_defconfig
powerpc:83xx/mpc834x_mds_defconfig
powerpc:86xx/sbc8641d_defconfig
s390:defconfig
s390:allmodconfig
s390:allnoconfig
score:defconfig
tile:tilegx_defconfig
unicore32:defconfig
unicore32:allnoconfig
xtensa:defconfig
xtensa:allmodconfig
xtensa:allnoconfig

Qemu:

total: 111 pass: 78 fail: 33
Failed tests:
alpha:defconfig
metag:meta2_defconfig
metag:tz1090_defconfig
microblaze:microblaze_defconfig
microblaze:microblazeel_defconfig
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips64:malta_defconfig:nosmp
mips64:malta_defconfig:smp
mipsel:24Kf:malta_defconfig:nosmp
mipsel:24Kf:malta_defconfig:smp
mipsel64:malta_defconfig:nosmp
mipsel64:malta_defconfig:smp
mipsel64:fuloong2e_defconfig:fulong2e
powerpc:mac99:nosmp:ppc_book3s_defconfig
powerpc:g3beige:nosmp:ppc_book3s_defconfig
powerpc:mac99:smp:ppc_book3s_defconfig
powerpc:virtex-ml507:44x/virtex5_defconfig
powerpc:mpc8544ds:mpc85xx_defconfig
powerpc:mpc8544ds:mpc85xx_smp_defconfig
powerpc:mpc8548cds:85xx/mpc85xx_cds_defconfig
powerpc:mpc8548cds:smpdev:85xx/mpc85xx_cds_defconfig
powerpc:bamboo:44x/bamboo_defconfig
powerpc:mac99:ppc64_book3s_defconfig:nosmp
powerpc:mac99:ppc64_book3s_defconfig:smp4
powerpc:pseries:pseries_defconfig
powerpc:mpc8544ds:ppc64_e5500_defconfig:nosmp
powerpc:mpc8544ds:ppc64_e5500_defconfig:smp
s390:defconfig
xtensa:dc232b:lx60:generic_kc705_defconfig
xtensa:dc232b:kc705:generic_kc705_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfig

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

[Shawn Guo]

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 lib/list_debug.c:31 __list_add_valid+0xbc/0xc4
>   list_add double add: new=c1229754, prev=c12383b4, next=c1229754.
> 
> Initialize the power domain after we get the regulator. Also do
> not print an error in case the regulator defers probing.
> 
> Cc: Fabio Estevam 
> Cc: Andrey Smirnov 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Fixes: 03aa12629fc4 ("soc: imx: Add GPCv2 power gating driver")
> Signed-off-by: Stefan Agner 

Applied, thanks.

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

[Shawn Guo]

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 lib/list_debug.c:31 __list_add_valid+0xbc/0xc4
>   list_add double add: new=c1229754, prev=c12383b4, next=c1229754.
> 
> Initialize the power domain after we get the regulator. Also do
> not print an error in case the regulator defers probing.
> 
> Cc: Fabio Estevam 
> Cc: Andrey Smirnov 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Fixes: 03aa12629fc4 ("soc: imx: Add GPCv2 power gating driver")
> Signed-off-by: Stefan Agner 

Applied, thanks.

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

[Greg Kroah-Hartman]

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 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 made by Sun Aug  6 23:15:34 UTC 2017.
> > > > Anything received after that time might be too late.
> > > > 
> > > 
> > > Preliminary:
> > > 
> > > Lots of
> > > 
> > > lib/string.c:31:32: fatal error: asm/word-at-a-time.h
> > > 
> > > affecting several architectures.
> > > 
> > > alpha:
> > > 
> > > lib/string.c:217:4: error: implicit declaration of function 
> > > 'zero_bytemask'
> > 
> > Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
> > zero_bytemask() on alpha and tile"), right?  Any other arches failing?
> 
> Hm, that doesn't work, do we care about tile? :)
> 
> Let me see how deep this hole is, I just wanted to get strscpy into 3.18
> to fix a bug...

Ok, I think tile and alpha should be fixed, is there anything else that
is broken?

thanks,

greg k-h

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

[Greg Kroah-Hartman]

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 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 made by Sun Aug  6 23:15:34 UTC 2017.
> > > > Anything received after that time might be too late.
> > > > 
> > > 
> > > Preliminary:
> > > 
> > > Lots of
> > > 
> > > lib/string.c:31:32: fatal error: asm/word-at-a-time.h
> > > 
> > > affecting several architectures.
> > > 
> > > alpha:
> > > 
> > > lib/string.c:217:4: error: implicit declaration of function 
> > > 'zero_bytemask'
> > 
> > Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
> > zero_bytemask() on alpha and tile"), right?  Any other arches failing?
> 
> Hm, that doesn't work, do we care about tile? :)
> 
> Let me see how deep this hole is, I just wanted to get strscpy into 3.18
> to fix a bug...

Ok, I think tile and alpha should be fixed, is there anything else that
is broken?

thanks,

greg k-h

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

[Greg Kroah-Hartman]

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 as a response
> >> to this one.  If anyone has any issues with these being applied, please
> >> let me know.
> >>
> >> Responses should be made by Sun Aug  6 23:15:23 UTC 2017.
> >> Anything received after that time might be too late.
> >>
> >> The whole patch series can be found in one patch at:
> >>kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.41-rc1.gz
> >> or in the git tree and branch at:
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> >> linux-4.9.y
> >> and the diffstat can be found below.
> > 
> > randconfig build failure:
> > 
> > on x86_64:
> > 
> > drivers/built-in.o: In function `nouveau_backlight_init':
> > (.text+0x11648a): undefined reference to `backlight_device_register'
> > drivers/built-in.o: In function `nouveau_backlight_init':
> > (.text+0x1165a1): undefined reference to `backlight_device_register'
> > drivers/built-in.o: In function `nouveau_backlight_exit':
> > (.text+0x116618): undefined reference to `backlight_device_unregister'
> > /local/lnx/stable/linux-stable-rc-linux-4.9.y/Makefile:972: recipe for 
> > target 'vmlinux' failed
> > 
> > 
> > CONFIG_DRM_NOUVEAU=y
> > CONFIG_NOUVEAU_DEBUG=5
> > CONFIG_NOUVEAU_DEBUG_DEFAULT=3
> > CONFIG_DRM_NOUVEAU_BACKLIGHT=y
> > # CONFIG_FB is not set
> > CONFIG_FB_CMDLINE=y
> > CONFIG_FB_BACKLIGHT=y
> > CONFIG_BACKLIGHT_LCD_SUPPORT=y
> > # CONFIG_LCD_CLASS_DEVICE is not set
> > # CONFIG_BACKLIGHT_CLASS_DEVICE is not set
> > # CONFIG_VGASTATE is not set
> > 
> > 
> > Full randconfig file is attached.
> > 
> 
> and:
> warning: (PMAC_BACKLIGHT && DRM_NOUVEAU && FB_TFT) selects FB_BACKLIGHT which 
> has unmet direct dependencies (HAS_IOMEM && FB)

Odd, is this a new failure?  I'll look at this tomorrow unless someone
has a clue as to what patch causes the issue...

thanks,

greg k-h

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

[Greg Kroah-Hartman]

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 as a response
> >> to this one.  If anyone has any issues with these being applied, please
> >> let me know.
> >>
> >> Responses should be made by Sun Aug  6 23:15:23 UTC 2017.
> >> Anything received after that time might be too late.
> >>
> >> The whole patch series can be found in one patch at:
> >>kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.41-rc1.gz
> >> or in the git tree and branch at:
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> >> linux-4.9.y
> >> and the diffstat can be found below.
> > 
> > randconfig build failure:
> > 
> > on x86_64:
> > 
> > drivers/built-in.o: In function `nouveau_backlight_init':
> > (.text+0x11648a): undefined reference to `backlight_device_register'
> > drivers/built-in.o: In function `nouveau_backlight_init':
> > (.text+0x1165a1): undefined reference to `backlight_device_register'
> > drivers/built-in.o: In function `nouveau_backlight_exit':
> > (.text+0x116618): undefined reference to `backlight_device_unregister'
> > /local/lnx/stable/linux-stable-rc-linux-4.9.y/Makefile:972: recipe for 
> > target 'vmlinux' failed
> > 
> > 
> > CONFIG_DRM_NOUVEAU=y
> > CONFIG_NOUVEAU_DEBUG=5
> > CONFIG_NOUVEAU_DEBUG_DEFAULT=3
> > CONFIG_DRM_NOUVEAU_BACKLIGHT=y
> > # CONFIG_FB is not set
> > CONFIG_FB_CMDLINE=y
> > CONFIG_FB_BACKLIGHT=y
> > CONFIG_BACKLIGHT_LCD_SUPPORT=y
> > # CONFIG_LCD_CLASS_DEVICE is not set
> > # CONFIG_BACKLIGHT_CLASS_DEVICE is not set
> > # CONFIG_VGASTATE is not set
> > 
> > 
> > Full randconfig file is attached.
> > 
> 
> and:
> warning: (PMAC_BACKLIGHT && DRM_NOUVEAU && FB_TFT) selects FB_BACKLIGHT which 
> has unmet direct dependencies (HAS_IOMEM && FB)

Odd, is this a new failure?  I'll look at this tomorrow unless someone
has a clue as to what patch causes the issue...

thanks,

greg k-h

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

[Shawn Guo]

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

Applied all.

> 
...
>  MAINTAINERS|   5 +

This MAINTAINERS file doesn't apply to my tree, so I dropped it.

Shawn

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

[Shawn Guo]

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

Applied all.

> 
...
>  MAINTAINERS|   5 +

This MAINTAINERS file doesn't apply to my tree, so I dropped it.

Shawn

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

[Randy Dunlap]

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 being applied, please
>> let me know.
>>
>> Responses should be made by Sun Aug  6 23:15:23 UTC 2017.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>>  kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.41-rc1.gz
>> or in the git tree and branch at:
>>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
>> linux-4.9.y
>> and the diffstat can be found below.
> 
> randconfig build failure:
> 
> on x86_64:
> 
> drivers/built-in.o: In function `nouveau_backlight_init':
> (.text+0x11648a): undefined reference to `backlight_device_register'
> drivers/built-in.o: In function `nouveau_backlight_init':
> (.text+0x1165a1): undefined reference to `backlight_device_register'
> drivers/built-in.o: In function `nouveau_backlight_exit':
> (.text+0x116618): undefined reference to `backlight_device_unregister'
> /local/lnx/stable/linux-stable-rc-linux-4.9.y/Makefile:972: recipe for target 
> 'vmlinux' failed
> 
> 
> CONFIG_DRM_NOUVEAU=y
> CONFIG_NOUVEAU_DEBUG=5
> CONFIG_NOUVEAU_DEBUG_DEFAULT=3
> CONFIG_DRM_NOUVEAU_BACKLIGHT=y
> # CONFIG_FB is not set
> CONFIG_FB_CMDLINE=y
> CONFIG_FB_BACKLIGHT=y
> CONFIG_BACKLIGHT_LCD_SUPPORT=y
> # CONFIG_LCD_CLASS_DEVICE is not set
> # CONFIG_BACKLIGHT_CLASS_DEVICE is not set
> # CONFIG_VGASTATE is not set
> 
> 
> Full randconfig file is attached.
> 

and:
warning: (PMAC_BACKLIGHT && DRM_NOUVEAU && FB_TFT) selects FB_BACKLIGHT which 
has unmet direct dependencies (HAS_IOMEM && FB)


-- 
~Randy

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

[Randy Dunlap]

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 being applied, please
>> let me know.
>>
>> Responses should be made by Sun Aug  6 23:15:23 UTC 2017.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>>  kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.41-rc1.gz
>> or in the git tree and branch at:
>>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
>> linux-4.9.y
>> and the diffstat can be found below.
> 
> randconfig build failure:
> 
> on x86_64:
> 
> drivers/built-in.o: In function `nouveau_backlight_init':
> (.text+0x11648a): undefined reference to `backlight_device_register'
> drivers/built-in.o: In function `nouveau_backlight_init':
> (.text+0x1165a1): undefined reference to `backlight_device_register'
> drivers/built-in.o: In function `nouveau_backlight_exit':
> (.text+0x116618): undefined reference to `backlight_device_unregister'
> /local/lnx/stable/linux-stable-rc-linux-4.9.y/Makefile:972: recipe for target 
> 'vmlinux' failed
> 
> 
> CONFIG_DRM_NOUVEAU=y
> CONFIG_NOUVEAU_DEBUG=5
> CONFIG_NOUVEAU_DEBUG_DEFAULT=3
> CONFIG_DRM_NOUVEAU_BACKLIGHT=y
> # CONFIG_FB is not set
> CONFIG_FB_CMDLINE=y
> CONFIG_FB_BACKLIGHT=y
> CONFIG_BACKLIGHT_LCD_SUPPORT=y
> # CONFIG_LCD_CLASS_DEVICE is not set
> # CONFIG_BACKLIGHT_CLASS_DEVICE is not set
> # CONFIG_VGASTATE is not set
> 
> 
> Full randconfig file is attached.
> 

and:
warning: (PMAC_BACKLIGHT && DRM_NOUVEAU && FB_TFT) selects FB_BACKLIGHT which 
has unmet direct dependencies (HAS_IOMEM && FB)


-- 
~Randy

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

[Randy Dunlap]

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 should be made by Sun Aug  6 23:15:23 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.41-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.

randconfig build failure:

on x86_64:

drivers/built-in.o: In function `nouveau_backlight_init':
(.text+0x11648a): undefined reference to `backlight_device_register'
drivers/built-in.o: In function `nouveau_backlight_init':
(.text+0x1165a1): undefined reference to `backlight_device_register'
drivers/built-in.o: In function `nouveau_backlight_exit':
(.text+0x116618): undefined reference to `backlight_device_unregister'
/local/lnx/stable/linux-stable-rc-linux-4.9.y/Makefile:972: recipe for target 
'vmlinux' failed


CONFIG_DRM_NOUVEAU=y
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
# CONFIG_FB is not set
CONFIG_FB_CMDLINE=y
CONFIG_FB_BACKLIGHT=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
# CONFIG_BACKLIGHT_CLASS_DEVICE is not set
# CONFIG_VGASTATE is not set


Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.9.41-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
# CONFIG_NO_HZ_FULL_ALL is not set
CONFIG_NO_HZ_FULL_SYSIDLE=y
CONFIG_NO_HZ_FULL_SYSIDLE_SMALL=8
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_IRQ_TIME_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_NOCB_CPU=y
# CONFIG_RCU_NOCB_CPU_NONE is not set
CONFIG_RCU_NOCB_CPU_ZERO=y
# CONFIG_RCU_NOCB_CPU_ALL is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y

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

[Randy Dunlap]

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 should be made by Sun Aug  6 23:15:23 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.41-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.

randconfig build failure:

on x86_64:

drivers/built-in.o: In function `nouveau_backlight_init':
(.text+0x11648a): undefined reference to `backlight_device_register'
drivers/built-in.o: In function `nouveau_backlight_init':
(.text+0x1165a1): undefined reference to `backlight_device_register'
drivers/built-in.o: In function `nouveau_backlight_exit':
(.text+0x116618): undefined reference to `backlight_device_unregister'
/local/lnx/stable/linux-stable-rc-linux-4.9.y/Makefile:972: recipe for target 
'vmlinux' failed


CONFIG_DRM_NOUVEAU=y
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
# CONFIG_FB is not set
CONFIG_FB_CMDLINE=y
CONFIG_FB_BACKLIGHT=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
# CONFIG_BACKLIGHT_CLASS_DEVICE is not set
# CONFIG_VGASTATE is not set


Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.9.41-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
# CONFIG_NO_HZ_FULL_ALL is not set
CONFIG_NO_HZ_FULL_SYSIDLE=y
CONFIG_NO_HZ_FULL_SYSIDLE_SMALL=8
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_IRQ_TIME_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_NOCB_CPU=y
# CONFIG_RCU_NOCB_CPU_NONE is not set
CONFIG_RCU_NOCB_CPU_ZERO=y
# CONFIG_RCU_NOCB_CPU_ALL is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y

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

[Greg Kroah-Hartman]

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 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 made by Sun Aug  6 23:15:34 UTC 2017.
> > > Anything received after that time might be too late.
> > > 
> > 
> > Preliminary:
> > 
> > Lots of
> > 
> > lib/string.c:31:32: fatal error: asm/word-at-a-time.h
> > 
> > affecting several architectures.
> > 
> > alpha:
> > 
> > lib/string.c:217:4: error: implicit declaration of function 'zero_bytemask'
> 
> Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
> zero_bytemask() on alpha and tile"), right?  Any other arches failing?

Hm, that doesn't work, do we care about tile? :)

Let me see how deep this hole is, I just wanted to get strscpy into 3.18
to fix a bug...

thanks,

greg k-h

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

[Greg Kroah-Hartman]

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 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 made by Sun Aug  6 23:15:34 UTC 2017.
> > > Anything received after that time might be too late.
> > > 
> > 
> > Preliminary:
> > 
> > Lots of
> > 
> > lib/string.c:31:32: fatal error: asm/word-at-a-time.h
> > 
> > affecting several architectures.
> > 
> > alpha:
> > 
> > lib/string.c:217:4: error: implicit declaration of function 'zero_bytemask'
> 
> Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
> zero_bytemask() on alpha and tile"), right?  Any other arches failing?

Hm, that doesn't work, do we care about tile? :)

Let me see how deep this hole is, I just wanted to get strscpy into 3.18
to fix a bug...

thanks,

greg k-h

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

[Greg Kroah-Hartman]

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 issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Aug  6 23:15:34 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Preliminary:
> 
> Lots of
> 
> lib/string.c:31:32: fatal error: asm/word-at-a-time.h
> 
> affecting several architectures.
> 
> alpha:
> 
> lib/string.c:217:4: error: implicit declaration of function 'zero_bytemask'

Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
zero_bytemask() on alpha and tile"), right?  Any other arches failing?

thanks,

greg k-h

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

[Greg Kroah-Hartman]

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 issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Aug  6 23:15:34 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Preliminary:
> 
> Lots of
> 
> lib/string.c:31:32: fatal error: asm/word-at-a-time.h
> 
> affecting several architectures.
> 
> alpha:
> 
> lib/string.c:217:4: error: implicit declaration of function 'zero_bytemask'

Hm, I think I need to add c753bf34c94e ("word-at-a-time.h: support
zero_bytemask() on alpha and tile"), right?  Any other arches failing?

thanks,

greg k-h

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

[Greg Kroah-Hartman]

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 issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Aug  6 23:15:23 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.41-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.9.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

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

[Greg Kroah-Hartman]

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 issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Aug  6 23:15:23 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.41-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.9.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

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

[Shuah Khan]

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 should be made by Sun Aug  6 23:15:34 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.64-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

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

[Shuah Khan]

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 should be made by Sun Aug  6 23:15:34 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.64-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.4 00/91] 4.4.80-stable review

[Shuah Khan]

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 should be made by Sun Aug  6 23:15:31 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.80-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.4 00/91] 4.4.80-stable review

[Shuah Khan]

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 should be made by Sun Aug  6 23:15:31 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.80-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

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

[Shawn Guo]

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 here and we can accellerate the process.

Okay.  I just put a few comments on the initial dts patch.  I can pick
it up after the comments get addressed.

Shawn

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

[Shawn Guo]

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 here and we can accellerate the process.

Okay.  I just put a few comments on the initial dts patch.  I can pick
it up after the comments get addressed.

Shawn

[PATCH] imon: constify attribute_group structures

[Amitoj Kaur Chawla]

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

File size after:
 text  data bss dec hex filename
 3717316584 960   54717d5bd drivers/media/rc/imon.o

This change was made with the help of Coccinelle.

Signed-off-by: Amitoj Kaur Chawla 
---
 drivers/media/rc/imon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index bd76534..717ba78 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -911,7 +911,7 @@ static struct attribute *imon_display_sysfs_entries[] = {
NULL
 };
 
-static struct attribute_group imon_display_attr_group = {
+static const struct attribute_group imon_display_attr_group = {
.attrs = imon_display_sysfs_entries
 };
 
@@ -920,7 +920,7 @@ static struct attribute *imon_rf_sysfs_entries[] = {
NULL
 };
 
-static struct attribute_group imon_rf_attr_group = {
+static const struct attribute_group imon_rf_attr_group = {
.attrs = imon_rf_sysfs_entries
 };
 
-- 
2.7.4

[PATCH] imon: constify attribute_group structures

[Amitoj Kaur Chawla]

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

File size after:
 text  data bss dec hex filename
 3717316584 960   54717d5bd drivers/media/rc/imon.o

This change was made with the help of Coccinelle.

Signed-off-by: Amitoj Kaur Chawla 
---
 drivers/media/rc/imon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index bd76534..717ba78 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -911,7 +911,7 @@ static struct attribute *imon_display_sysfs_entries[] = {
NULL
 };
 
-static struct attribute_group imon_display_attr_group = {
+static const struct attribute_group imon_display_attr_group = {
.attrs = imon_display_sysfs_entries
 };
 
@@ -920,7 +920,7 @@ static struct attribute *imon_rf_sysfs_entries[] = {
NULL
 };
 
-static struct attribute_group imon_rf_attr_group = {
+static const struct attribute_group imon_rf_attr_group = {
.attrs = imon_rf_sysfs_entries
 };
 
-- 
2.7.4

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

[Shuah Khan]

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 should be made by Sun Aug  6 23:15:23 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.41-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

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

[Shuah Khan]

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 should be made by Sun Aug  6 23:15:23 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.41-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

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

[Shawn Guo]

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 signed off
> 
> Changes v3 -> v4:
>   - rebase on master
> 
> Changes v2 -> v3:
>   - rebase on master
> 
> Changes v1 -> v2:
>   - rebase on master
> ---
>  arch/arm/boot/dts/Makefile |  2 +
>  arch/arm/boot/dts/imx28-ts4600-common.dtsi | 78 
> ++
>  arch/arm/boot/dts/imx28-ts4600-rev-a.dts   | 22 +
>  arch/arm/boot/dts/imx28-ts4600-rev-b.dts   | 22 +
>  4 files changed, 124 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx28-ts4600-common.dtsi
>  create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-a.dts
>  create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-b.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 4b17f35dc9a7..a3c8b7af192b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -525,6 +525,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
>   imx28-m28cu3.dtb \
>   imx28-m28evk.dtb \
>   imx28-sps1.dtb \
> + imx28-ts4600-rev-a.dtb \
> + imx28-ts4600-rev-b.dtb \
>   imx28-tx28.dtb
>  dtb-$(CONFIG_ARCH_NOMADIK) += \
>   ste-nomadik-s8815.dtb \
> diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi 
> b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> new file mode 100644
> index ..04bd5a5c0cb4
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> @@ -0,0 +1,78 @@
> +/*
> + * Copyright (C) 2016 Savoir-Faire Linux
> + * Author: Sebastien Bourdelin 
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +#include "imx28.dtsi"
> +#include "dt-bindings/gpio/gpio.h"
> +
> +/ {
> +
> + compatible = "technologic,imx28-ts4600", "fsl,imx28";
> +
> + apb@8000 {
> + apbh@8000 {
> + ssp0: ssp@8001 {
> + compatible = "fsl,imx28-mmc";
> + pinctrl-names = "default";
> + pinctrl-0 = <_4bit_pins_a
> +  _sck_cfg
> +  _sd_pwr>;
> + broken-cd = <1>;
> + bus-width = <4>;
> + vmmc-supply = <_vddio_sd0>;
> + status = "okay";
> + };
> +
> + pinctrl@80018000 {
> + pinctrl-names = "default";

This line shouldn't be needed here.

> +
> + en_sd_pwr: en_sd_pwr {

Please have a look at bindings/pinctrl/fsl,mxs-pinctrl.txt.  The node
without 'reg' property will be treated as a pure configuration rather
than pinmux node.  You should really have a 'reg' property for it.

Also, we prefer to use hyphen than underscore in node name.

> + fsl,pinmux-ids = <
> + MX28_PAD_PWM3__GPIO_3_28
> + >;
> + fsl,drive-strength = ;
> + fsl,voltage = ;
> + fsl,pull-up = ;
> + };
> +
> + };
> + };
> +
> + apbx@8004 {
> + pwm: pwm@80064000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + status = "okay";
> + };
> +
> + duart: serial@80074000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + status = "okay";
> + };
> + };
> + };
> +
> + regulators {
> + compatible = "simple-bus";
> +
> + reg_vddio_sd0: vddio-sd0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vddio-sd0";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + gpio = < 28 0>;

Please use the defines in include/dt-bindings/gpio/gpio.h for polarity
here?

> + };
> + };

We are asked by DT maintainers to put fixed regulator directly under
root 

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

[Shawn Guo]

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 signed off
> 
> Changes v3 -> v4:
>   - rebase on master
> 
> Changes v2 -> v3:
>   - rebase on master
> 
> Changes v1 -> v2:
>   - rebase on master
> ---
>  arch/arm/boot/dts/Makefile |  2 +
>  arch/arm/boot/dts/imx28-ts4600-common.dtsi | 78 
> ++
>  arch/arm/boot/dts/imx28-ts4600-rev-a.dts   | 22 +
>  arch/arm/boot/dts/imx28-ts4600-rev-b.dts   | 22 +
>  4 files changed, 124 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx28-ts4600-common.dtsi
>  create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-a.dts
>  create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-b.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 4b17f35dc9a7..a3c8b7af192b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -525,6 +525,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
>   imx28-m28cu3.dtb \
>   imx28-m28evk.dtb \
>   imx28-sps1.dtb \
> + imx28-ts4600-rev-a.dtb \
> + imx28-ts4600-rev-b.dtb \
>   imx28-tx28.dtb
>  dtb-$(CONFIG_ARCH_NOMADIK) += \
>   ste-nomadik-s8815.dtb \
> diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi 
> b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> new file mode 100644
> index ..04bd5a5c0cb4
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> @@ -0,0 +1,78 @@
> +/*
> + * Copyright (C) 2016 Savoir-Faire Linux
> + * Author: Sebastien Bourdelin 
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +#include "imx28.dtsi"
> +#include "dt-bindings/gpio/gpio.h"
> +
> +/ {
> +
> + compatible = "technologic,imx28-ts4600", "fsl,imx28";
> +
> + apb@8000 {
> + apbh@8000 {
> + ssp0: ssp@8001 {
> + compatible = "fsl,imx28-mmc";
> + pinctrl-names = "default";
> + pinctrl-0 = <_4bit_pins_a
> +  _sck_cfg
> +  _sd_pwr>;
> + broken-cd = <1>;
> + bus-width = <4>;
> + vmmc-supply = <_vddio_sd0>;
> + status = "okay";
> + };
> +
> + pinctrl@80018000 {
> + pinctrl-names = "default";

This line shouldn't be needed here.

> +
> + en_sd_pwr: en_sd_pwr {

Please have a look at bindings/pinctrl/fsl,mxs-pinctrl.txt.  The node
without 'reg' property will be treated as a pure configuration rather
than pinmux node.  You should really have a 'reg' property for it.

Also, we prefer to use hyphen than underscore in node name.

> + fsl,pinmux-ids = <
> + MX28_PAD_PWM3__GPIO_3_28
> + >;
> + fsl,drive-strength = ;
> + fsl,voltage = ;
> + fsl,pull-up = ;
> + };
> +
> + };
> + };
> +
> + apbx@8004 {
> + pwm: pwm@80064000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + status = "okay";
> + };
> +
> + duart: serial@80074000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + status = "okay";
> + };
> + };
> + };
> +
> + regulators {
> + compatible = "simple-bus";
> +
> + reg_vddio_sd0: vddio-sd0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vddio-sd0";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + gpio = < 28 0>;

Please use the defines in include/dt-bindings/gpio/gpio.h for polarity
here?

> + };
> + };

We are asked by DT maintainers to put fixed regulator directly under
root instead of having a fake bus container node.  We prefer to use the
following naming 

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, oom: fix potential data corruption when
> oom_reaper races with writer
> 
> On Fri 04-08-17 13:00:47, Michal Hocko wrote:
> > On Fri 04-08-17 19:41:42, Tetsuo Handa wrote:
> [...]
> > > Yes. Data corruption still happens.
> >
> > I guess I managed to reproduce finally. Will investigate further.
> 
> One limitation of the current MMF_UNSTABLE implementation is that it still
> keeps the new page mapped and only sends EFAULT/kill to the consumer. If
> somebody tries to re-read the same content nothing will really happen. I
> went this way because it was much simpler and memory consumers usually
> do not retry on EFAULT. Maybe this is not the case here.
> 
> I've been staring into iov_iter_copy_from_user_atomic which I believe
> should be the common write path which reads the user buffer where the
> corruption caused by the oom_reaper would come from.
> iov_iter_fault_in_readable should be called before this function. If this
> happened after MMF_UNSTABLE was set then we should get EFAULT and bail
> out early. Let's assume this wasn't the case. Then we should get down to
> iov_iter_copy_from_user_atomic and that one shouldn't copy any data
> because __copy_from_user_inatomic says
> 
>  * If copying succeeds, the return value must be 0.  If some data cannot
be
>  * fetched, it is permitted to copy less than had been fetched; the only
>  * hard requirement is that not storing anything at all (i.e. returning
size)
>  * should happen only when nothing could be copied.  In other words, you
> don't
>  * have to squeeze as much as possible - it is allowed, but not necessary.
> 
> which should be our case.
> 
> I was testing with xfs (but generic_perform_write seem to be doing the
same
> thing) and that one does
>   if (unlikely(copied == 0)) {
>   /*
>* If we were unable to copy any data at all, we
must
>* fall back to a single segment length write.
>*
>* If we didn't fallback here, we could livelock
>* because not all segments in the iov can be copied
at
>* once without a pagefault.
>*/
>   bytes = min_t(unsigned long, PAGE_SIZE - offset,
>
iov_iter_single_seg_count(i));
>   goto again;
>   }
> 
> and that again will go through iov_iter_fault_in_readable again and that
will
> succeed now.
> 
Agree, didn't notice this case before.

> And that's why we still see the corruption. That, however, means that the
> MMF_UNSTABLE implementation has to be more complex and we have to
> hook into all anonymous memory fault paths which I hoped I could avoid
> previously.
> 
> This is a rough first draft that passes the test case from Tetsuo on my
system.
> It will need much more eyes on it and I will return to it with a fresh
brain next
> week. I would appreciate as much testing as possible.
> 
> Note that this is on top of the previous attempt for the fix but I will
squash
> the result into one patch because the previous one is not sufficient.
> ---
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c index
> 86975dec0ba1..1fbc78d423d7 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -550,6 +550,7 @@ static int __do_huge_pmd_anonymous_page(struct
> vm_fault *vmf, struct page *page,
>   struct mem_cgroup *memcg;
>   pgtable_t pgtable;
>   unsigned long haddr = vmf->address & HPAGE_PMD_MASK;
> + int ret;
> 
>   VM_BUG_ON_PAGE(!PageCompound(page), page);
> 
> @@ -561,9 +562,8 @@ static int __do_huge_pmd_anonymous_page(struct
> vm_fault *vmf, struct page *page,
> 
>   pgtable = pte_alloc_one(vma->vm_mm, haddr);
>   if (unlikely(!pgtable)) {
> - mem_cgroup_cancel_charge(page, memcg, true);
> - put_page(page);
> - return VM_FAULT_OOM;
> + ret = VM_FAULT_OOM;
> + goto release;
>   }
> 
>   clear_huge_page(page, haddr, HPAGE_PMD_NR); @@ -583,6 +583,15
> @@ static int __do_huge_pmd_anonymous_page(struct vm_fault *vmf,
> struct page *page,
>   } else {
>   pmd_t entry;
> 
> + /*
> +  * range could have been already torn down by
> +  * the oom reaper
> +  */
> + if (test_bit(MMF_UNSTABLE, >vm_mm->flags)) {
> + spin_unlock(vmf->ptl);
> + ret = VM_FAULT_SIGBUS;
> + goto release;
> + }
>   /* Deliver the page fault to userland */
>   if (userfaultfd_missing(vma)) {
> 

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, oom: fix potential data corruption when
> oom_reaper races with writer
> 
> On Fri 04-08-17 13:00:47, Michal Hocko wrote:
> > On Fri 04-08-17 19:41:42, Tetsuo Handa wrote:
> [...]
> > > Yes. Data corruption still happens.
> >
> > I guess I managed to reproduce finally. Will investigate further.
> 
> One limitation of the current MMF_UNSTABLE implementation is that it still
> keeps the new page mapped and only sends EFAULT/kill to the consumer. If
> somebody tries to re-read the same content nothing will really happen. I
> went this way because it was much simpler and memory consumers usually
> do not retry on EFAULT. Maybe this is not the case here.
> 
> I've been staring into iov_iter_copy_from_user_atomic which I believe
> should be the common write path which reads the user buffer where the
> corruption caused by the oom_reaper would come from.
> iov_iter_fault_in_readable should be called before this function. If this
> happened after MMF_UNSTABLE was set then we should get EFAULT and bail
> out early. Let's assume this wasn't the case. Then we should get down to
> iov_iter_copy_from_user_atomic and that one shouldn't copy any data
> because __copy_from_user_inatomic says
> 
>  * If copying succeeds, the return value must be 0.  If some data cannot
be
>  * fetched, it is permitted to copy less than had been fetched; the only
>  * hard requirement is that not storing anything at all (i.e. returning
size)
>  * should happen only when nothing could be copied.  In other words, you
> don't
>  * have to squeeze as much as possible - it is allowed, but not necessary.
> 
> which should be our case.
> 
> I was testing with xfs (but generic_perform_write seem to be doing the
same
> thing) and that one does
>   if (unlikely(copied == 0)) {
>   /*
>* If we were unable to copy any data at all, we
must
>* fall back to a single segment length write.
>*
>* If we didn't fallback here, we could livelock
>* because not all segments in the iov can be copied
at
>* once without a pagefault.
>*/
>   bytes = min_t(unsigned long, PAGE_SIZE - offset,
>
iov_iter_single_seg_count(i));
>   goto again;
>   }
> 
> and that again will go through iov_iter_fault_in_readable again and that
will
> succeed now.
> 
Agree, didn't notice this case before.

> And that's why we still see the corruption. That, however, means that the
> MMF_UNSTABLE implementation has to be more complex and we have to
> hook into all anonymous memory fault paths which I hoped I could avoid
> previously.
> 
> This is a rough first draft that passes the test case from Tetsuo on my
system.
> It will need much more eyes on it and I will return to it with a fresh
brain next
> week. I would appreciate as much testing as possible.
> 
> Note that this is on top of the previous attempt for the fix but I will
squash
> the result into one patch because the previous one is not sufficient.
> ---
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c index
> 86975dec0ba1..1fbc78d423d7 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -550,6 +550,7 @@ static int __do_huge_pmd_anonymous_page(struct
> vm_fault *vmf, struct page *page,
>   struct mem_cgroup *memcg;
>   pgtable_t pgtable;
>   unsigned long haddr = vmf->address & HPAGE_PMD_MASK;
> + int ret;
> 
>   VM_BUG_ON_PAGE(!PageCompound(page), page);
> 
> @@ -561,9 +562,8 @@ static int __do_huge_pmd_anonymous_page(struct
> vm_fault *vmf, struct page *page,
> 
>   pgtable = pte_alloc_one(vma->vm_mm, haddr);
>   if (unlikely(!pgtable)) {
> - mem_cgroup_cancel_charge(page, memcg, true);
> - put_page(page);
> - return VM_FAULT_OOM;
> + ret = VM_FAULT_OOM;
> + goto release;
>   }
> 
>   clear_huge_page(page, haddr, HPAGE_PMD_NR); @@ -583,6 +583,15
> @@ static int __do_huge_pmd_anonymous_page(struct vm_fault *vmf,
> struct page *page,
>   } else {
>   pmd_t entry;
> 
> + /*
> +  * range could have been already torn down by
> +  * the oom reaper
> +  */
> + if (test_bit(MMF_UNSTABLE, >vm_mm->flags)) {
> + spin_unlock(vmf->ptl);
> + ret = VM_FAULT_SIGBUS;
> + goto release;
> + }
>   /* Deliver the page fault to userland */
>   if (userfaultfd_missing(vma)) {
>   int ret;
> @@ -610,6 +619,13 @@ static 

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

[sohu0106]

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;
int i;

//a is NULL,a->kb_cnt will crash
if (put_user(kbd->accent_table_size, >kb_cnt))




At 2017-08-04 17:26:08, "Heiko Carstens"  wrote:
>On Thu, Aug 03, 2017 at 09:57:38PM +0800, sohu0106 wrote:
>> 
>> 
>> Local users able to send the NULL arg argument to kbd_ioctl(), which could 
>> cause kernel crash
>> 
>> 
>> 
>> 
>> diff --git a/keyboard.c 
>> b/keyboard.c
>> index ba0e4f9..3ec16b1 100644
>> --- a/keyboard.c
>> +++ b/keyboard.c
>> @@ -456,6 +456,8 @@ int kbd_ioctl(struct kbd_data *kbd, unsigned int cmd, 
>> unsigned long arg)
>>         int perm;
>>  
>>         argp = (void __user *)arg;
>> +       if( !argp )
>> +               return -EFAULT;
>
>This doesn't make sense as well. All uaccess functions are able to handle
>NULL pointers within user space.
>

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

[sohu0106]

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;
int i;

//a is NULL,a->kb_cnt will crash
if (put_user(kbd->accent_table_size, >kb_cnt))




At 2017-08-04 17:26:08, "Heiko Carstens"  wrote:
>On Thu, Aug 03, 2017 at 09:57:38PM +0800, sohu0106 wrote:
>> 
>> 
>> Local users able to send the NULL arg argument to kbd_ioctl(), which could 
>> cause kernel crash
>> 
>> 
>> 
>> 
>> diff --git a/keyboard.c 
>> b/keyboard.c
>> index ba0e4f9..3ec16b1 100644
>> --- a/keyboard.c
>> +++ b/keyboard.c
>> @@ -456,6 +456,8 @@ int kbd_ioctl(struct kbd_data *kbd, unsigned int cmd, 
>> unsigned long arg)
>>         int perm;
>>  
>>         argp = (void __user *)arg;
>> +       if( !argp )
>> +               return -EFAULT;
>
>This doesn't make sense as well. All uaccess functions are able to handle
>NULL pointers within user space.
>

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

[Guenter Roeck]

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 made by Sun Aug  6 23:15:34 UTC 2017.
Anything received after that time might be too late.



Preliminary:

Lots of

lib/string.c:31:32: fatal error: asm/word-at-a-time.h

affecting several architectures.

alpha:

lib/string.c:217:4: error: implicit declaration of function 'zero_bytemask'

Guenter

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

[Guenter Roeck]

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 made by Sun Aug  6 23:15:34 UTC 2017.
Anything received after that time might be too late.



Preliminary:

Lots of

lib/string.c:31:32: fatal error: asm/word-at-a-time.h

affecting several architectures.

alpha:

lib/string.c:217:4: error: implicit declaration of function 'zero_bytemask'

Guenter

[PATCH] thunderbolt: constify attribute_group structure

[Amitoj Kaur Chawla]

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 drivers/thunderbolt/switch.o

File size after:
 text  data bss dec hex filename
 28661 7204   0   358658c19 drivers/thunderbolt/switch.o

This change was made with the help of Coccinelle.

Signed-off-by: Amitoj Kaur Chawla 
---
 drivers/thunderbolt/switch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index e9391bb..6cd4f14 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -970,7 +970,7 @@ static umode_t switch_attr_is_visible(struct kobject *kobj,
return sw->safe_mode ? 0 : attr->mode;
 }
 
-static struct attribute_group switch_group = {
+static const struct attribute_group switch_group = {
.is_visible = switch_attr_is_visible,
.attrs = switch_attrs,
 };
-- 
2.7.4

[PATCH] thunderbolt: constify attribute_group structure

[Amitoj Kaur Chawla]

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 drivers/thunderbolt/switch.o

File size after:
 text  data bss dec hex filename
 28661 7204   0   358658c19 drivers/thunderbolt/switch.o

This change was made with the help of Coccinelle.

Signed-off-by: Amitoj Kaur Chawla 
---
 drivers/thunderbolt/switch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index e9391bb..6cd4f14 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -970,7 +970,7 @@ static umode_t switch_attr_is_visible(struct kobject *kobj,
return sw->safe_mode ? 0 : attr->mode;
 }
 
-static struct attribute_group switch_group = {
+static const struct attribute_group switch_group = {
.is_visible = switch_attr_is_visible,
.attrs = switch_attrs,
 };
-- 
2.7.4

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

[Shawn Guo]

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, thanks.

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

[Shawn Guo]

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, thanks.

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

[Chao Yu]

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
> +++ b/fs/f2fs/segment.c
> @@ -1540,6 +1540,8 @@ static void update_sit_entry(struct f2fs_sb_info *sbi, 
> block_t blkaddr, int del)
>   f2fs_msg(sbi->sb, KERN_ERR,
>   "Bitmap was wrongly set, blk:%u", blkaddr);
>   f2fs_bug_on(sbi, 1);
> + se->valid_blocks--;
> + del = 0;
>   }
>  
>   if (f2fs_discard_en(sbi) &&
> @@ -1567,6 +1569,8 @@ static void update_sit_entry(struct f2fs_sb_info *sbi, 
> block_t blkaddr, int del)
>   f2fs_msg(sbi->sb, KERN_ERR,
>   "Bitmap was wrongly cleared, blk:%u", blkaddr);
>   f2fs_bug_on(sbi, 1);
> + se->valid_blocks++;
> + del = 0;
>   }
>  
>   if (f2fs_discard_en(sbi) &&
> 

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

[Chao Yu]

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
> +++ b/fs/f2fs/segment.c
> @@ -1540,6 +1540,8 @@ static void update_sit_entry(struct f2fs_sb_info *sbi, 
> block_t blkaddr, int del)
>   f2fs_msg(sbi->sb, KERN_ERR,
>   "Bitmap was wrongly set, blk:%u", blkaddr);
>   f2fs_bug_on(sbi, 1);
> + se->valid_blocks--;
> + del = 0;
>   }
>  
>   if (f2fs_discard_en(sbi) &&
> @@ -1567,6 +1569,8 @@ static void update_sit_entry(struct f2fs_sb_info *sbi, 
> block_t blkaddr, int del)
>   f2fs_msg(sbi->sb, KERN_ERR,
>   "Bitmap was wrongly cleared, blk:%u", blkaddr);
>   f2fs_bug_on(sbi, 1);
> + se->valid_blocks++;
> + del = 0;
>   }
>  
>   if (f2fs_discard_en(sbi) &&
> 

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

[Brendan Higgins]

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 IBM's BT-BMC
  - Deleted an unnecessary discussion of the host side interface (unnecessary
since the OpenIPMI stuff already has its own documentation).
---
 Documentation/bt-i2c.txt   | 109 +
 .../devicetree/bindings/ipmi/ipmi-bt-i2c.txt   |  21 
 .../bindings/ipmi_bmc/ipmi-bmc-bt-i2c.txt  |  21 
 3 files changed, 151 insertions(+)
 create mode 100644 Documentation/bt-i2c.txt
 create mode 100644 Documentation/devicetree/bindings/ipmi/ipmi-bt-i2c.txt
 create mode 100644 
Documentation/devicetree/bindings/ipmi_bmc/ipmi-bmc-bt-i2c.txt

diff --git a/Documentation/bt-i2c.txt b/Documentation/bt-i2c.txt
new file mode 100644
index ..499931b02e6c
--- /dev/null
+++ b/Documentation/bt-i2c.txt
@@ -0,0 +1,109 @@
+Linux Block Transfer over I2C (bt-i2c) interface description
+
+
+by Brendan Higgins  in 2016
+
+Introduction
+
+
+IPMI defines an interface for communication between a CPU, a BMC (Baseboard
+Management Controller), and sensors and various other peripherals. For a more
+complete description of IPMI please see:
+http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html
+
+IPMI defines a *common* message format, as in a set of fields that are common
+across all IPMI messages; they could be viewed as part of the framing
+information for an IPMI message. They include:
+
+   - netfn
+   - lun
+   - cmd
+
+netfn and cmd together define the type of the message; netfn can be viewed as a
+message class and cmd is a subtype of sorts. lun (logical unit number) is used
+for routing between messages between different interfaces. After the last field
+there is usually a variable length payload. Despite these common fields, the
+remainder of the framing varies widely between the IPMI defined hardware
+interfaces; some specify a length as part of the framing which is never more
+than a byte in length; others use a special signal to denote the end of 
message.
+Some IPMI hardware interfaces, the Block Transfer interface in particular,
+support a sequence number that aids in support of multiple in-flight IPMI
+messages.
+
+IPMI defines SSIF (SMBus System Interface) as the IPMI hardware interface for
+SMBus/I2C. It supports a maximum total message length of 255 bytes that is
+broken up across several SMBus block operations. It does not define a sequence
+field in the IPMI framing making it very difficult to support multiple in 
flight
+messages (it is also intentionally left out of the specification). SSIF also
+requires the slave device to NACK until it is ready to accept data (technically
+it only specifies that it may NACK until it is ready, but must NACK on 
attempted
+reads if it does not support SMBus Alert; however, this is an effective
+requirements since a slave device is supposed to start with SMBus Alert
+disabled); this again makes SSIF very difficult to support for some slave
+devices which may not support NACKing arbitrary messages; indeed, at the time 
of
+writing, the Linux I2C slave driver framework did not have support for sending
+NACKs.
+
+Block Transfer over I2C defines a new IPMI compatible interface that uses Block
+Transfer messages and semantics on top of plain old I2C; it does not assume 
that
+the I2C slave is capable of NACKing arbitrary messages; however, it is designed
+such that it could take advantage of SMBus Alert so that the master does not
+have to poll (the Linux I2C core slave mode does not currently support SMBus
+Alert, but a patch adding this support is currently on the way).
+
+Protocol Definition
+---
+
+Block Transfer over I2C uses the IPMI defined Block Transfer message format; it
+supports variable length messages with a maximum length of 255 bytes (limited 
by
+the IPMI Block Transfer length byte).
+
+A Block Transfer over I2C Request is structured as follows:
+
+--
+| I2C start | slave address / RW bit unset | Block Transfer message | ... 
(another message or stop ) |
+--
+
+Multiple requests can be sent before any responses are received. Sequence
+numbers are to be handled by the users of the drivers; thus, no semantics are
+prescribed to their usage; however, the slave driver is required to buffer at
+least 256 requests before dropping requests; this can be used in conjunction
+with sequence numbers to prevent messages from 

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

[Brendan Higgins]

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 IBM's BT-BMC
  - Deleted an unnecessary discussion of the host side interface (unnecessary
since the OpenIPMI stuff already has its own documentation).
---
 Documentation/bt-i2c.txt   | 109 +
 .../devicetree/bindings/ipmi/ipmi-bt-i2c.txt   |  21 
 .../bindings/ipmi_bmc/ipmi-bmc-bt-i2c.txt  |  21 
 3 files changed, 151 insertions(+)
 create mode 100644 Documentation/bt-i2c.txt
 create mode 100644 Documentation/devicetree/bindings/ipmi/ipmi-bt-i2c.txt
 create mode 100644 
Documentation/devicetree/bindings/ipmi_bmc/ipmi-bmc-bt-i2c.txt

diff --git a/Documentation/bt-i2c.txt b/Documentation/bt-i2c.txt
new file mode 100644
index ..499931b02e6c
--- /dev/null
+++ b/Documentation/bt-i2c.txt
@@ -0,0 +1,109 @@
+Linux Block Transfer over I2C (bt-i2c) interface description
+
+
+by Brendan Higgins  in 2016
+
+Introduction
+
+
+IPMI defines an interface for communication between a CPU, a BMC (Baseboard
+Management Controller), and sensors and various other peripherals. For a more
+complete description of IPMI please see:
+http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html
+
+IPMI defines a *common* message format, as in a set of fields that are common
+across all IPMI messages; they could be viewed as part of the framing
+information for an IPMI message. They include:
+
+   - netfn
+   - lun
+   - cmd
+
+netfn and cmd together define the type of the message; netfn can be viewed as a
+message class and cmd is a subtype of sorts. lun (logical unit number) is used
+for routing between messages between different interfaces. After the last field
+there is usually a variable length payload. Despite these common fields, the
+remainder of the framing varies widely between the IPMI defined hardware
+interfaces; some specify a length as part of the framing which is never more
+than a byte in length; others use a special signal to denote the end of 
message.
+Some IPMI hardware interfaces, the Block Transfer interface in particular,
+support a sequence number that aids in support of multiple in-flight IPMI
+messages.
+
+IPMI defines SSIF (SMBus System Interface) as the IPMI hardware interface for
+SMBus/I2C. It supports a maximum total message length of 255 bytes that is
+broken up across several SMBus block operations. It does not define a sequence
+field in the IPMI framing making it very difficult to support multiple in 
flight
+messages (it is also intentionally left out of the specification). SSIF also
+requires the slave device to NACK until it is ready to accept data (technically
+it only specifies that it may NACK until it is ready, but must NACK on 
attempted
+reads if it does not support SMBus Alert; however, this is an effective
+requirements since a slave device is supposed to start with SMBus Alert
+disabled); this again makes SSIF very difficult to support for some slave
+devices which may not support NACKing arbitrary messages; indeed, at the time 
of
+writing, the Linux I2C slave driver framework did not have support for sending
+NACKs.
+
+Block Transfer over I2C defines a new IPMI compatible interface that uses Block
+Transfer messages and semantics on top of plain old I2C; it does not assume 
that
+the I2C slave is capable of NACKing arbitrary messages; however, it is designed
+such that it could take advantage of SMBus Alert so that the master does not
+have to poll (the Linux I2C core slave mode does not currently support SMBus
+Alert, but a patch adding this support is currently on the way).
+
+Protocol Definition
+---
+
+Block Transfer over I2C uses the IPMI defined Block Transfer message format; it
+supports variable length messages with a maximum length of 255 bytes (limited 
by
+the IPMI Block Transfer length byte).
+
+A Block Transfer over I2C Request is structured as follows:
+
+--
+| I2C start | slave address / RW bit unset | Block Transfer message | ... 
(another message or stop ) |
+--
+
+Multiple requests can be sent before any responses are received. Sequence
+numbers are to be handled by the users of the drivers; thus, no semantics are
+prescribed to their usage; however, the slave driver is required to buffer at
+least 256 requests before dropping requests; this can be used in conjunction
+with sequence numbers to prevent messages from being dropped by the slave.
+
+A Block Transfer over 

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

[Brendan Higgins]

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 reason for this in greater detail, suffice it to
say SSIF cannot be correctly implemented on some naive I2C devices. There are
some additional reasons why we don't like SSIF, but those are again covered in
the documentation for all those who are interested.

In addition, since I am adding both host side and BMC side support, I figured
that now is a good time to resolve the problem of where to put BMC side IPMI
drivers; right now we have it (there is only one) in drivers/char/ipmi/ with the
rest of the host side IPMI drivers, but I think it makes sense to put all of the
host side IPMI drivers in one directory and all of the BMC side drivers in
another, preferably in a way that does not effect all of the current OpenIPMI
users. I have not created a MAINTAINERS entry for the new directory yet, as I
figured there might be some discussion to be had about it.

I have tested this patchset on the Aspeed 2500 EVB.

Changes since previous update:
  - Cleaned up some documentation.
  - Added patch which moves the Aspeed BT-BMC driver to the new ipmi_bmc
directory.

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

[Brendan Higgins]

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 reason for this in greater detail, suffice it to
say SSIF cannot be correctly implemented on some naive I2C devices. There are
some additional reasons why we don't like SSIF, but those are again covered in
the documentation for all those who are interested.

In addition, since I am adding both host side and BMC side support, I figured
that now is a good time to resolve the problem of where to put BMC side IPMI
drivers; right now we have it (there is only one) in drivers/char/ipmi/ with the
rest of the host side IPMI drivers, but I think it makes sense to put all of the
host side IPMI drivers in one directory and all of the BMC side drivers in
another, preferably in a way that does not effect all of the current OpenIPMI
users. I have not created a MAINTAINERS entry for the new directory yet, as I
figured there might be some discussion to be had about it.

I have tested this patchset on the Aspeed 2500 EVB.

Changes since previous update:
  - Cleaned up some documentation.
  - Added patch which moves the Aspeed BT-BMC driver to the new ipmi_bmc
directory.

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

[Brendan Higgins]

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 Higgins 
---
Changes for v2:
  - None
---
 drivers/char/ipmi/Kconfig   |   4 +
 drivers/char/ipmi/Makefile  |   1 +
 drivers/char/ipmi/ipmi_bt_i2c.c | 452 
 3 files changed, 457 insertions(+)
 create mode 100644 drivers/char/ipmi/ipmi_bt_i2c.c

diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index f6fa056a52fc..a8734a369cb0 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -79,6 +79,10 @@ config IPMI_POWEROFF
  This enables a function to power off the system with IPMI if
 the IPMI management controller is capable of this.
 
+config IPMI_BT_I2C
+   select I2C
+   tristate 'BT IPMI bmc driver over I2c'
+
 endif # IPMI_HANDLER
 
 config ASPEED_BT_IPMI_BMC
diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
index eefb0b301e83..323de0b0b8b5 100644
--- a/drivers/char/ipmi/Makefile
+++ b/drivers/char/ipmi/Makefile
@@ -12,4 +12,5 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
 obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
 obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
 obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
+obj-$(CONFIG_IPMI_BT_I2C) += ipmi_bt_i2c.o
 obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
diff --git a/drivers/char/ipmi/ipmi_bt_i2c.c b/drivers/char/ipmi/ipmi_bt_i2c.c
new file mode 100644
index ..94b5c11d23cd
--- /dev/null
+++ b/drivers/char/ipmi/ipmi_bt_i2c.c
@@ -0,0 +1,452 @@
+/*
+ * Copyright 2017 Google Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt)"ipmi-bt-i2c: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IPMI_BT_I2C_TIMEOUT (msecs_to_jiffies(1000))
+
+/* If we don't have netfn_lun, seq, and cmd, we might as well have nothing. */
+#define IPMI_BT_I2C_LEN_MIN 3
+/* We need at least netfn_lun, seq, cmd, and completion. */
+#define IPMI_BT_I2C_RESPONSE_LEN_MIN 4
+#define IPMI_BT_I2C_MSG_MAX_PAYLOAD_SIZE 252
+
+struct ipmi_bt_i2c_msg {
+   u8 len;
+   u8 netfn_lun;
+   u8 seq;
+   u8 cmd;
+   u8 payload[IPMI_BT_I2C_MSG_MAX_PAYLOAD_SIZE];
+} __packed;
+
+#define IPMI_BT_I2C_MAX_SMI_SIZE 254 /* Need extra byte for seq. */
+#define IPMI_BT_I2C_SMI_MSG_HEADER_SIZE 2
+
+struct ipmi_bt_i2c_smi_msg {
+   u8 netfn_lun;
+   u8 cmd;
+   u8 payload[IPMI_MAX_MSG_LENGTH - 2];
+} __packed;
+
+static inline u32 bt_msg_len(struct ipmi_bt_i2c_msg *bt_request)
+{
+   return bt_request->len + 1;
+}
+
+#define IPMI_BT_I2C_SEQ_MAX 256
+
+struct ipmi_bt_i2c_seq_entry {
+   struct ipmi_smi_msg *msg;
+   unsigned long   send_time;
+};
+
+struct ipmi_bt_i2c_master {
+   struct ipmi_device_id   ipmi_id;
+   struct i2c_client   *client;
+   ipmi_smi_t  intf;
+   spinlock_t  lock;
+   struct ipmi_bt_i2c_seq_entryseq_msg_map[IPMI_BT_I2C_SEQ_MAX];
+   struct work_struct  ipmi_bt_i2c_recv_work;
+   struct work_struct  ipmi_bt_i2c_send_work;
+   struct ipmi_smi_msg *msg_to_send;
+};
+
+static const unsigned long write_timeout = 25;
+
+static int ipmi_bt_i2c_send_request(struct ipmi_bt_i2c_master *master,
+   struct ipmi_bt_i2c_msg *request)
+{
+   struct i2c_client *client = master->client;
+   unsigned long timeout, read_time;
+   u8 *buf = (u8 *) request;
+   int ret;
+
+   timeout = jiffies + msecs_to_jiffies(write_timeout);
+   do {
+   read_time = jiffies;
+   ret = i2c_master_send(client, buf, bt_msg_len(request));
+   if (ret >= 0)
+   return 0;
+   usleep_range(1000, 1500);
+   } while (time_before(read_time, timeout));
+   return ret;
+}
+
+static int ipmi_bt_i2c_receive_response(struct ipmi_bt_i2c_master *master,
+   struct ipmi_bt_i2c_msg *response)
+{
+   struct i2c_client *client = master->client;
+   unsigned long timeout, read_time;
+   u8 *buf = (u8 *) response;
+   u8 len = 0;
+   int ret;
+
+   /*
+* Slave may not NACK when 

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

[Brendan Higgins]

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 Higgins 
---
Changes for v2:
  - None
---
 drivers/char/ipmi/Kconfig   |   4 +
 drivers/char/ipmi/Makefile  |   1 +
 drivers/char/ipmi/ipmi_bt_i2c.c | 452 
 3 files changed, 457 insertions(+)
 create mode 100644 drivers/char/ipmi/ipmi_bt_i2c.c

diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index f6fa056a52fc..a8734a369cb0 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -79,6 +79,10 @@ config IPMI_POWEROFF
  This enables a function to power off the system with IPMI if
 the IPMI management controller is capable of this.
 
+config IPMI_BT_I2C
+   select I2C
+   tristate 'BT IPMI bmc driver over I2c'
+
 endif # IPMI_HANDLER
 
 config ASPEED_BT_IPMI_BMC
diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
index eefb0b301e83..323de0b0b8b5 100644
--- a/drivers/char/ipmi/Makefile
+++ b/drivers/char/ipmi/Makefile
@@ -12,4 +12,5 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
 obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
 obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
 obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
+obj-$(CONFIG_IPMI_BT_I2C) += ipmi_bt_i2c.o
 obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
diff --git a/drivers/char/ipmi/ipmi_bt_i2c.c b/drivers/char/ipmi/ipmi_bt_i2c.c
new file mode 100644
index ..94b5c11d23cd
--- /dev/null
+++ b/drivers/char/ipmi/ipmi_bt_i2c.c
@@ -0,0 +1,452 @@
+/*
+ * Copyright 2017 Google Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt)"ipmi-bt-i2c: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IPMI_BT_I2C_TIMEOUT (msecs_to_jiffies(1000))
+
+/* If we don't have netfn_lun, seq, and cmd, we might as well have nothing. */
+#define IPMI_BT_I2C_LEN_MIN 3
+/* We need at least netfn_lun, seq, cmd, and completion. */
+#define IPMI_BT_I2C_RESPONSE_LEN_MIN 4
+#define IPMI_BT_I2C_MSG_MAX_PAYLOAD_SIZE 252
+
+struct ipmi_bt_i2c_msg {
+   u8 len;
+   u8 netfn_lun;
+   u8 seq;
+   u8 cmd;
+   u8 payload[IPMI_BT_I2C_MSG_MAX_PAYLOAD_SIZE];
+} __packed;
+
+#define IPMI_BT_I2C_MAX_SMI_SIZE 254 /* Need extra byte for seq. */
+#define IPMI_BT_I2C_SMI_MSG_HEADER_SIZE 2
+
+struct ipmi_bt_i2c_smi_msg {
+   u8 netfn_lun;
+   u8 cmd;
+   u8 payload[IPMI_MAX_MSG_LENGTH - 2];
+} __packed;
+
+static inline u32 bt_msg_len(struct ipmi_bt_i2c_msg *bt_request)
+{
+   return bt_request->len + 1;
+}
+
+#define IPMI_BT_I2C_SEQ_MAX 256
+
+struct ipmi_bt_i2c_seq_entry {
+   struct ipmi_smi_msg *msg;
+   unsigned long   send_time;
+};
+
+struct ipmi_bt_i2c_master {
+   struct ipmi_device_id   ipmi_id;
+   struct i2c_client   *client;
+   ipmi_smi_t  intf;
+   spinlock_t  lock;
+   struct ipmi_bt_i2c_seq_entryseq_msg_map[IPMI_BT_I2C_SEQ_MAX];
+   struct work_struct  ipmi_bt_i2c_recv_work;
+   struct work_struct  ipmi_bt_i2c_send_work;
+   struct ipmi_smi_msg *msg_to_send;
+};
+
+static const unsigned long write_timeout = 25;
+
+static int ipmi_bt_i2c_send_request(struct ipmi_bt_i2c_master *master,
+   struct ipmi_bt_i2c_msg *request)
+{
+   struct i2c_client *client = master->client;
+   unsigned long timeout, read_time;
+   u8 *buf = (u8 *) request;
+   int ret;
+
+   timeout = jiffies + msecs_to_jiffies(write_timeout);
+   do {
+   read_time = jiffies;
+   ret = i2c_master_send(client, buf, bt_msg_len(request));
+   if (ret >= 0)
+   return 0;
+   usleep_range(1000, 1500);
+   } while (time_before(read_time, timeout));
+   return ret;
+}
+
+static int ipmi_bt_i2c_receive_response(struct ipmi_bt_i2c_master *master,
+   struct ipmi_bt_i2c_msg *response)
+{
+   struct i2c_client *client = master->client;
+   unsigned long timeout, read_time;
+   u8 *buf = (u8 *) response;
+   u8 len = 0;
+   int ret;
+
+   /*
+* Slave may not NACK when not ready, so we peek at the 

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

[Brendan Higgins]

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 same BMC side file system interface as "ipmi-bt-host".

Signed-off-by: Brendan Higgins 
---
Changes for v2:
  - None
---
 drivers/char/Kconfig|   1 +
 drivers/char/Makefile   |   1 +
 drivers/char/ipmi_bmc/Kconfig   |  22 ++
 drivers/char/ipmi_bmc/Makefile  |   5 +
 drivers/char/ipmi_bmc/ipmi_bmc_bt_i2c.c | 346 
 include/linux/ipmi_bmc.h|  76 +++
 6 files changed, 451 insertions(+)
 create mode 100644 drivers/char/ipmi_bmc/Kconfig
 create mode 100644 drivers/char/ipmi_bmc/Makefile
 create mode 100644 drivers/char/ipmi_bmc/ipmi_bmc_bt_i2c.c
 create mode 100644 include/linux/ipmi_bmc.h

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index ccd239ab879f..2a6ca2325a45 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -195,6 +195,7 @@ config POWERNV_OP_PANEL
  If unsure, say M here to build it as a module called powernv-op-panel.
 
 source "drivers/char/ipmi/Kconfig"
+source "drivers/char/ipmi_bmc/Kconfig"
 
 config DS1620
tristate "NetWinder thermometer support"
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 53e33720818c..9e143186fa30 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -58,4 +58,5 @@ js-rtc-y = rtc.o
 
 obj-$(CONFIG_TILE_SROM)+= tile-srom.o
 obj-$(CONFIG_XILLYBUS) += xillybus/
+obj-$(CONFIG_IPMI_BMC) += ipmi_bmc/
 obj-$(CONFIG_POWERNV_OP_PANEL) += powernv-op-panel.o
diff --git a/drivers/char/ipmi_bmc/Kconfig b/drivers/char/ipmi_bmc/Kconfig
new file mode 100644
index ..26c8e0cb765c
--- /dev/null
+++ b/drivers/char/ipmi_bmc/Kconfig
@@ -0,0 +1,22 @@
+#
+# IPMI BMC configuration
+#
+
+menuconfig IPMI_BMC
+   tristate 'IPMI BMC core'
+   help
+ This enables the BMC-side IPMI drivers.
+
+ If unsure, say N.
+
+if IPMI_BMC
+
+config IPMI_BMC_BT_I2C
+   depends on I2C
+   select I2C_SLAVE
+   tristate 'Generic I2C BT IPMI BMC driver'
+   help
+ Provides a driver that uses IPMI Block Transfer messages and
+ semantics on top of plain old I2C.
+
+endif # IPMI_BMC
diff --git a/drivers/char/ipmi_bmc/Makefile b/drivers/char/ipmi_bmc/Makefile
new file mode 100644
index ..dfe5128f8158
--- /dev/null
+++ b/drivers/char/ipmi_bmc/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the ipmi bmc drivers.
+#
+
+obj-$(CONFIG_IPMI_BMC_BT_I2C) += ipmi_bmc_bt_i2c.o
diff --git a/drivers/char/ipmi_bmc/ipmi_bmc_bt_i2c.c 
b/drivers/char/ipmi_bmc/ipmi_bmc_bt_i2c.c
new file mode 100644
index ..686b83fa42a4
--- /dev/null
+++ b/drivers/char/ipmi_bmc/ipmi_bmc_bt_i2c.c
@@ -0,0 +1,346 @@
+/*
+ * Copyright 2017 Google Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PFX "IPMI BMC BT-I2C: "
+
+/*
+ * TODO: This is "bt-host" to match the bt-host driver; however, I think this 
is
+ * unclear in the context of a CPU side driver. Should probably name this
+ * and the DEVICE_NAME in bt-host to something like "bt-bmc" or "bt-slave".
+ */
+#define DEVICE_NAME"ipmi-bt-host"
+
+static const unsigned long request_queue_max_len = 256;
+
+struct bt_request_elem {
+   struct list_headlist;
+   struct bt_msg   request;
+};
+
+struct bt_i2c_slave {
+   struct i2c_client   *client;
+   struct miscdevice   miscdev;
+   struct bt_msg   request;
+   struct list_headrequest_queue;
+   atomic_trequest_queue_len;
+   struct bt_msg   response;
+   boolresponse_in_progress;
+   size_t  msg_idx;
+   spinlock_t  lock;
+   wait_queue_head_t   wait_queue;
+   struct mutexfile_mutex;
+};
+
+static int receive_bt_request(struct bt_i2c_slave *bt_slave, bool non_blocking,
+ struct bt_msg *bt_request)
+{
+   int res;
+   unsigned long flags;
+   struct bt_request_elem *queue_elem;
+
+   if (!non_blocking) {
+try_again:
+   res = wait_event_interruptible(
+   bt_slave->wait_queue,

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

[Brendan Higgins]

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 | 9 -
 drivers/char/ipmi/Makefile| 1 -
 drivers/char/ipmi_bmc/Kconfig | 9 +
 drivers/char/ipmi_bmc/Makefile| 1 +
 drivers/char/{ipmi/bt-bmc.c => ipmi_bmc/ipmi_bmc_bt_aspeed.c} | 0
 5 files changed, 10 insertions(+), 10 deletions(-)
 rename drivers/char/{ipmi/bt-bmc.c => ipmi_bmc/ipmi_bmc_bt_aspeed.c} (100%)

diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index a8734a369cb0..09ce9f64abf8 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -84,12 +84,3 @@ config IPMI_BT_I2C
tristate 'BT IPMI bmc driver over I2c'
 
 endif # IPMI_HANDLER
-
-config ASPEED_BT_IPMI_BMC
-   depends on ARCH_ASPEED || COMPILE_TEST
-   depends on REGMAP && REGMAP_MMIO && MFD_SYSCON
-   tristate "BT IPMI bmc driver"
-   help
- Provides a driver for the BT (Block Transfer) IPMI interface
- found on Aspeed SOCs (AST2400 and AST2500). The driver
- implements the BMC side of the BT interface.
diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
index 323de0b0b8b5..f0b5672cdca9 100644
--- a/drivers/char/ipmi/Makefile
+++ b/drivers/char/ipmi/Makefile
@@ -13,4 +13,3 @@ obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
 obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
 obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
 obj-$(CONFIG_IPMI_BT_I2C) += ipmi_bt_i2c.o
-obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
diff --git a/drivers/char/ipmi_bmc/Kconfig b/drivers/char/ipmi_bmc/Kconfig
index 26c8e0cb765c..b6af38455702 100644
--- a/drivers/char/ipmi_bmc/Kconfig
+++ b/drivers/char/ipmi_bmc/Kconfig
@@ -19,4 +19,13 @@ config IPMI_BMC_BT_I2C
  Provides a driver that uses IPMI Block Transfer messages and
  semantics on top of plain old I2C.
 
+config ASPEED_BT_IPMI_BMC
+   depends on ARCH_ASPEED || COMPILE_TEST
+   depends on REGMAP && REGMAP_MMIO && MFD_SYSCON
+   tristate "BT IPMI bmc driver"
+   help
+ Provides a driver for the BT (Block Transfer) IPMI interface
+ found on Aspeed SOCs (AST2400 and AST2500). The driver
+ implements the BMC side of the BT interface.
+
 endif # IPMI_BMC
diff --git a/drivers/char/ipmi_bmc/Makefile b/drivers/char/ipmi_bmc/Makefile
index dfe5128f8158..8bff32b55c24 100644
--- a/drivers/char/ipmi_bmc/Makefile
+++ b/drivers/char/ipmi_bmc/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_IPMI_BMC_BT_I2C) += ipmi_bmc_bt_i2c.o
+obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += ipmi_bmc_bt_aspeed.o
diff --git a/drivers/char/ipmi/bt-bmc.c 
b/drivers/char/ipmi_bmc/ipmi_bmc_bt_aspeed.c
similarity index 100%
rename from drivers/char/ipmi/bt-bmc.c
rename to drivers/char/ipmi_bmc/ipmi_bmc_bt_aspeed.c
-- 
2.14.0.rc1.383.gd1ce394fe2-goog

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

[Brendan Higgins]

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 same BMC side file system interface as "ipmi-bt-host".

Signed-off-by: Brendan Higgins 
---
Changes for v2:
  - None
---
 drivers/char/Kconfig|   1 +
 drivers/char/Makefile   |   1 +
 drivers/char/ipmi_bmc/Kconfig   |  22 ++
 drivers/char/ipmi_bmc/Makefile  |   5 +
 drivers/char/ipmi_bmc/ipmi_bmc_bt_i2c.c | 346 
 include/linux/ipmi_bmc.h|  76 +++
 6 files changed, 451 insertions(+)
 create mode 100644 drivers/char/ipmi_bmc/Kconfig
 create mode 100644 drivers/char/ipmi_bmc/Makefile
 create mode 100644 drivers/char/ipmi_bmc/ipmi_bmc_bt_i2c.c
 create mode 100644 include/linux/ipmi_bmc.h

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index ccd239ab879f..2a6ca2325a45 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -195,6 +195,7 @@ config POWERNV_OP_PANEL
  If unsure, say M here to build it as a module called powernv-op-panel.
 
 source "drivers/char/ipmi/Kconfig"
+source "drivers/char/ipmi_bmc/Kconfig"
 
 config DS1620
tristate "NetWinder thermometer support"
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 53e33720818c..9e143186fa30 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -58,4 +58,5 @@ js-rtc-y = rtc.o
 
 obj-$(CONFIG_TILE_SROM)+= tile-srom.o
 obj-$(CONFIG_XILLYBUS) += xillybus/
+obj-$(CONFIG_IPMI_BMC) += ipmi_bmc/
 obj-$(CONFIG_POWERNV_OP_PANEL) += powernv-op-panel.o
diff --git a/drivers/char/ipmi_bmc/Kconfig b/drivers/char/ipmi_bmc/Kconfig
new file mode 100644
index ..26c8e0cb765c
--- /dev/null
+++ b/drivers/char/ipmi_bmc/Kconfig
@@ -0,0 +1,22 @@
+#
+# IPMI BMC configuration
+#
+
+menuconfig IPMI_BMC
+   tristate 'IPMI BMC core'
+   help
+ This enables the BMC-side IPMI drivers.
+
+ If unsure, say N.
+
+if IPMI_BMC
+
+config IPMI_BMC_BT_I2C
+   depends on I2C
+   select I2C_SLAVE
+   tristate 'Generic I2C BT IPMI BMC driver'
+   help
+ Provides a driver that uses IPMI Block Transfer messages and
+ semantics on top of plain old I2C.
+
+endif # IPMI_BMC
diff --git a/drivers/char/ipmi_bmc/Makefile b/drivers/char/ipmi_bmc/Makefile
new file mode 100644
index ..dfe5128f8158
--- /dev/null
+++ b/drivers/char/ipmi_bmc/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the ipmi bmc drivers.
+#
+
+obj-$(CONFIG_IPMI_BMC_BT_I2C) += ipmi_bmc_bt_i2c.o
diff --git a/drivers/char/ipmi_bmc/ipmi_bmc_bt_i2c.c 
b/drivers/char/ipmi_bmc/ipmi_bmc_bt_i2c.c
new file mode 100644
index ..686b83fa42a4
--- /dev/null
+++ b/drivers/char/ipmi_bmc/ipmi_bmc_bt_i2c.c
@@ -0,0 +1,346 @@
+/*
+ * Copyright 2017 Google Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PFX "IPMI BMC BT-I2C: "
+
+/*
+ * TODO: This is "bt-host" to match the bt-host driver; however, I think this 
is
+ * unclear in the context of a CPU side driver. Should probably name this
+ * and the DEVICE_NAME in bt-host to something like "bt-bmc" or "bt-slave".
+ */
+#define DEVICE_NAME"ipmi-bt-host"
+
+static const unsigned long request_queue_max_len = 256;
+
+struct bt_request_elem {
+   struct list_headlist;
+   struct bt_msg   request;
+};
+
+struct bt_i2c_slave {
+   struct i2c_client   *client;
+   struct miscdevice   miscdev;
+   struct bt_msg   request;
+   struct list_headrequest_queue;
+   atomic_trequest_queue_len;
+   struct bt_msg   response;
+   boolresponse_in_progress;
+   size_t  msg_idx;
+   spinlock_t  lock;
+   wait_queue_head_t   wait_queue;
+   struct mutexfile_mutex;
+};
+
+static int receive_bt_request(struct bt_i2c_slave *bt_slave, bool non_blocking,
+ struct bt_msg *bt_request)
+{
+   int res;
+   unsigned long flags;
+   struct bt_request_elem *queue_elem;
+
+   if (!non_blocking) {
+try_again:
+   res = wait_event_interruptible(
+   bt_slave->wait_queue,
+  

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

[Brendan Higgins]

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 | 9 -
 drivers/char/ipmi/Makefile| 1 -
 drivers/char/ipmi_bmc/Kconfig | 9 +
 drivers/char/ipmi_bmc/Makefile| 1 +
 drivers/char/{ipmi/bt-bmc.c => ipmi_bmc/ipmi_bmc_bt_aspeed.c} | 0
 5 files changed, 10 insertions(+), 10 deletions(-)
 rename drivers/char/{ipmi/bt-bmc.c => ipmi_bmc/ipmi_bmc_bt_aspeed.c} (100%)

diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index a8734a369cb0..09ce9f64abf8 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -84,12 +84,3 @@ config IPMI_BT_I2C
tristate 'BT IPMI bmc driver over I2c'
 
 endif # IPMI_HANDLER
-
-config ASPEED_BT_IPMI_BMC
-   depends on ARCH_ASPEED || COMPILE_TEST
-   depends on REGMAP && REGMAP_MMIO && MFD_SYSCON
-   tristate "BT IPMI bmc driver"
-   help
- Provides a driver for the BT (Block Transfer) IPMI interface
- found on Aspeed SOCs (AST2400 and AST2500). The driver
- implements the BMC side of the BT interface.
diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
index 323de0b0b8b5..f0b5672cdca9 100644
--- a/drivers/char/ipmi/Makefile
+++ b/drivers/char/ipmi/Makefile
@@ -13,4 +13,3 @@ obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
 obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
 obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
 obj-$(CONFIG_IPMI_BT_I2C) += ipmi_bt_i2c.o
-obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
diff --git a/drivers/char/ipmi_bmc/Kconfig b/drivers/char/ipmi_bmc/Kconfig
index 26c8e0cb765c..b6af38455702 100644
--- a/drivers/char/ipmi_bmc/Kconfig
+++ b/drivers/char/ipmi_bmc/Kconfig
@@ -19,4 +19,13 @@ config IPMI_BMC_BT_I2C
  Provides a driver that uses IPMI Block Transfer messages and
  semantics on top of plain old I2C.
 
+config ASPEED_BT_IPMI_BMC
+   depends on ARCH_ASPEED || COMPILE_TEST
+   depends on REGMAP && REGMAP_MMIO && MFD_SYSCON
+   tristate "BT IPMI bmc driver"
+   help
+ Provides a driver for the BT (Block Transfer) IPMI interface
+ found on Aspeed SOCs (AST2400 and AST2500). The driver
+ implements the BMC side of the BT interface.
+
 endif # IPMI_BMC
diff --git a/drivers/char/ipmi_bmc/Makefile b/drivers/char/ipmi_bmc/Makefile
index dfe5128f8158..8bff32b55c24 100644
--- a/drivers/char/ipmi_bmc/Makefile
+++ b/drivers/char/ipmi_bmc/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_IPMI_BMC_BT_I2C) += ipmi_bmc_bt_i2c.o
+obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += ipmi_bmc_bt_aspeed.o
diff --git a/drivers/char/ipmi/bt-bmc.c 
b/drivers/char/ipmi_bmc/ipmi_bmc_bt_aspeed.c
similarity index 100%
rename from drivers/char/ipmi/bt-bmc.c
rename to drivers/char/ipmi_bmc/ipmi_bmc_bt_aspeed.c
-- 
2.14.0.rc1.383.gd1ce394fe2-goog

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

[Dan Williams]

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 debugged by the system owner.

Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c |   24 
 drivers/nvdimm/nd.h  |1 +
 drivers/nvdimm/region_devs.c |6 --
 include/linux/libnvdimm.h|1 +
 4 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 19182d091587..be231a549eb0 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1835,6 +1835,30 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
cmp_map_compat, NULL);
nd_set->altcookie = nd_fletcher64(info, sizeof_nfit_set_info(nr), 0);
 
+   /* record the result of the sort for the mapping position */
+   for (i = 0; i < nr; i++) {
+   struct nfit_set_info_map2 *map2 = >mapping[i];
+   int j;
+
+   for (j = 0; j < nr; j++) {
+   struct nd_mapping_desc *mapping = _desc->mapping[j];
+   struct nvdimm *nvdimm = mapping->nvdimm;
+   struct nfit_mem *nfit_mem = 
nvdimm_provider_data(nvdimm);
+
+   if (map2->serial_number
+   == nfit_mem->dcr->serial_number &&
+   map2->vendor_id
+   == nfit_mem->dcr->vendor_id &&
+   map2->manufacturing_date
+   == nfit_mem->dcr->manufacturing_date &&
+   map2->manufacturing_location
+   == nfit_mem->dcr->manufacturing_location) {
+   mapping->position = i;
+   break;
+   }
+   }
+   }
+
ndr_desc->nd_set = nd_set;
devm_kfree(dev, info);
devm_kfree(dev, info2);
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index e9fa9e84b364..a08fc2e24fb3 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -134,6 +134,7 @@ struct nd_mapping {
struct nvdimm *nvdimm;
u64 start;
u64 size;
+   int position;
struct list_head labels;
struct mutex lock;
/*
diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
index 5954cfbea3fc..829d760f651c 100644
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -723,8 +723,9 @@ static ssize_t mappingN(struct device *dev, char *buf, int 
n)
nd_mapping = _region->mapping[n];
nvdimm = nd_mapping->nvdimm;
 
-   return sprintf(buf, "%s,%llu,%llu\n", dev_name(>dev),
-   nd_mapping->start, nd_mapping->size);
+   return sprintf(buf, "%s,%llu,%llu,%d\n", dev_name(>dev),
+   nd_mapping->start, nd_mapping->size,
+   nd_mapping->position);
 }
 
 #define REGION_MAPPING(idx) \
@@ -965,6 +966,7 @@ static struct nd_region *nd_region_create(struct nvdimm_bus 
*nvdimm_bus,
nd_region->mapping[i].nvdimm = nvdimm;
nd_region->mapping[i].start = mapping->start;
nd_region->mapping[i].size = mapping->size;
+   nd_region->mapping[i].position = mapping->position;
INIT_LIST_HEAD(_region->mapping[i].labels);
mutex_init(_region->mapping[i].lock);
 
diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
index f3d3e6af8838..9b8d81a7b80e 100644
--- a/include/linux/libnvdimm.h
+++ b/include/linux/libnvdimm.h
@@ -87,6 +87,7 @@ struct nd_mapping_desc {
struct nvdimm *nvdimm;
u64 start;
u64 size;
+   int position;
 };
 
 struct nd_region_desc {

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

[Dan Williams]

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 debugged by the system owner.

Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c |   24 
 drivers/nvdimm/nd.h  |1 +
 drivers/nvdimm/region_devs.c |6 --
 include/linux/libnvdimm.h|1 +
 4 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 19182d091587..be231a549eb0 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1835,6 +1835,30 @@ static int acpi_nfit_init_interleave_set(struct 
acpi_nfit_desc *acpi_desc,
cmp_map_compat, NULL);
nd_set->altcookie = nd_fletcher64(info, sizeof_nfit_set_info(nr), 0);
 
+   /* record the result of the sort for the mapping position */
+   for (i = 0; i < nr; i++) {
+   struct nfit_set_info_map2 *map2 = >mapping[i];
+   int j;
+
+   for (j = 0; j < nr; j++) {
+   struct nd_mapping_desc *mapping = _desc->mapping[j];
+   struct nvdimm *nvdimm = mapping->nvdimm;
+   struct nfit_mem *nfit_mem = 
nvdimm_provider_data(nvdimm);
+
+   if (map2->serial_number
+   == nfit_mem->dcr->serial_number &&
+   map2->vendor_id
+   == nfit_mem->dcr->vendor_id &&
+   map2->manufacturing_date
+   == nfit_mem->dcr->manufacturing_date &&
+   map2->manufacturing_location
+   == nfit_mem->dcr->manufacturing_location) {
+   mapping->position = i;
+   break;
+   }
+   }
+   }
+
ndr_desc->nd_set = nd_set;
devm_kfree(dev, info);
devm_kfree(dev, info2);
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index e9fa9e84b364..a08fc2e24fb3 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -134,6 +134,7 @@ struct nd_mapping {
struct nvdimm *nvdimm;
u64 start;
u64 size;
+   int position;
struct list_head labels;
struct mutex lock;
/*
diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
index 5954cfbea3fc..829d760f651c 100644
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -723,8 +723,9 @@ static ssize_t mappingN(struct device *dev, char *buf, int 
n)
nd_mapping = _region->mapping[n];
nvdimm = nd_mapping->nvdimm;
 
-   return sprintf(buf, "%s,%llu,%llu\n", dev_name(>dev),
-   nd_mapping->start, nd_mapping->size);
+   return sprintf(buf, "%s,%llu,%llu,%d\n", dev_name(>dev),
+   nd_mapping->start, nd_mapping->size,
+   nd_mapping->position);
 }
 
 #define REGION_MAPPING(idx) \
@@ -965,6 +966,7 @@ static struct nd_region *nd_region_create(struct nvdimm_bus 
*nvdimm_bus,
nd_region->mapping[i].nvdimm = nvdimm;
nd_region->mapping[i].start = mapping->start;
nd_region->mapping[i].size = mapping->size;
+   nd_region->mapping[i].position = mapping->position;
INIT_LIST_HEAD(_region->mapping[i].labels);
mutex_init(_region->mapping[i].lock);
 
diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
index f3d3e6af8838..9b8d81a7b80e 100644
--- a/include/linux/libnvdimm.h
+++ b/include/linux/libnvdimm.h
@@ -87,6 +87,7 @@ struct nd_mapping_desc {
struct nvdimm *nvdimm;
u64 start;
u64 size;
+   int position;
 };
 
 struct nd_region_desc {

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

[Tetsuo Handa]

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 necessary. 
> > 
> > Whether it is a _real_ workload or not cannot become an answer.
> > 
> > If somebody is trying to allocate hundreds/thousands of pages after memory 
> > of
> > an OOM victim was reaped, avoiding this race window makes no sense; next OOM
> > victim will be selected anyway. But if somebody is trying to allocate only 
> > one
> > page and then is planning to release a lot of memory, avoiding this race 
> > window
> > can save somebody from being OOM-killed needlessly. This race window 
> > depends on
> > what the threads are about to do, not whether the workload is natural or
> > artificial.
> 
> And with a desparate lack of crystal ball we cannot do much about that
> really.
> 
> > My question is, how can users know it if somebody was OOM-killed needlessly
> > by allowing MMF_OOM_SKIP to race.
> 
> Is it really important to know that the race is due to MMF_OOM_SKIP?

Yes, it is really important. Needlessly selecting even one OOM victim is
a pain which is difficult to explain to and persuade some of customers.

> Isn't it sufficient to see that we kill too many tasks and then debug it
> further once something hits that?

It is not sufficient.

> 
> [...]
> > Is it guaranteed that __node_reclaim() never (even indirectly) waits for
> > __GFP_DIRECT_RECLAIM && !__GFP_NORETRY memory allocation?
> 
> this is a direct reclaim which can go down to slab shrinkers with all
> the usual fun...

Excuse me, but does that mean "Yes, it is" ?

As far as I checked, most shrinkers use non-scheduling operations other than
cond_resched(). But some shrinkers use lock_page()/down_write() etc. I worry
that such shrinkers might wait for __GFP_DIRECT_RECLAIM && !__GFP_NORETRY
memory allocation (i.e. "No, it isn't").

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

[Tetsuo Handa]

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 necessary. 
> > 
> > Whether it is a _real_ workload or not cannot become an answer.
> > 
> > If somebody is trying to allocate hundreds/thousands of pages after memory 
> > of
> > an OOM victim was reaped, avoiding this race window makes no sense; next OOM
> > victim will be selected anyway. But if somebody is trying to allocate only 
> > one
> > page and then is planning to release a lot of memory, avoiding this race 
> > window
> > can save somebody from being OOM-killed needlessly. This race window 
> > depends on
> > what the threads are about to do, not whether the workload is natural or
> > artificial.
> 
> And with a desparate lack of crystal ball we cannot do much about that
> really.
> 
> > My question is, how can users know it if somebody was OOM-killed needlessly
> > by allowing MMF_OOM_SKIP to race.
> 
> Is it really important to know that the race is due to MMF_OOM_SKIP?

Yes, it is really important. Needlessly selecting even one OOM victim is
a pain which is difficult to explain to and persuade some of customers.

> Isn't it sufficient to see that we kill too many tasks and then debug it
> further once something hits that?

It is not sufficient.

> 
> [...]
> > Is it guaranteed that __node_reclaim() never (even indirectly) waits for
> > __GFP_DIRECT_RECLAIM && !__GFP_NORETRY memory allocation?
> 
> this is a direct reclaim which can go down to slab shrinkers with all
> the usual fun...

Excuse me, but does that mean "Yes, it is" ?

As far as I checked, most shrinkers use non-scheduling operations other than
cond_resched(). But some shrinkers use lock_page()/down_write() etc. I worry
that such shrinkers might wait for __GFP_DIRECT_RECLAIM && !__GFP_NORETRY
memory allocation (i.e. "No, it isn't").

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

[Andrew Lunn]

> @@ -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

[Andrew Lunn]

> @@ -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

[John Stultz]

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 upstreaming it!) to ensure we don't select
modes we cannot generate.

Also, since the ade crtc code will adjust the mode in mode_set,
this patch also adds a mode_fixup callback which we use to make
sure we are validating the mode clock that will eventually be
used.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Rob Clark 
Cc: Xinliang Liu 
Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: Jose Abreu 
Cc: Archit Taneja 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v2: Reworked to calculate if modeclock matches the phy's
byteclock, rather then using a whitelist of known modes.

v3: Reworked to check across all possible crtcs (even though for
us there is only one), and use mode_fixup instead of a custom
function, as suggested by Jose and Daniel.

v4: Fixes and improved error handling as suggested by Jose.
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 67 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 14 ++
 2 files changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index f77dcfa..043a50d 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -603,6 +603,72 @@ static void dsi_encoder_enable(struct drm_encoder *encoder)
dsi->enable = true;
 }
 
+static enum drm_mode_status dsi_encoder_phy_mode_valid(
+   struct drm_encoder *encoder,
+   const struct drm_display_mode *mode)
+{
+   struct dw_dsi *dsi = encoder_to_dsi(encoder);
+   struct mipi_phy_params phy;
+   u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+   u32 req_kHz, act_kHz, lane_byte_clk_kHz;
+
+   /* Calculate the lane byte clk using the adjusted mode clk */
+   memset(, 0, sizeof(phy));
+   req_kHz = mode->clock * bpp / dsi->lanes;
+   act_kHz = dsi_calc_phy_rate(req_kHz, );
+   lane_byte_clk_kHz = act_kHz / 8;
+
+   DRM_DEBUG_DRIVER("Checking mode %ix%i-%i@%i clock: %i...",
+   mode->hdisplay, mode->vdisplay, bpp,
+   drm_mode_vrefresh(mode), mode->clock);
+
+   /*
+* Make sure the adjused mode clock and the lane byte clk
+* have a common denominator base frequency
+*/
+   if (mode->clock/dsi->lanes == lane_byte_clk_kHz/3) {
+   DRM_DEBUG_DRIVER("OK!\n");
+   return MODE_OK;
+   }
+
+   DRM_DEBUG_DRIVER("BAD!\n");
+   return MODE_BAD;
+}
+
+static enum drm_mode_status dsi_encoder_mode_valid(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode)
+
+{
+   const struct drm_crtc_helper_funcs *crtc_funcs = NULL;
+   struct drm_crtc *crtc = NULL;
+   struct drm_display_mode adj_mode;
+   enum drm_mode_status ret;
+
+   /*
+* The crtc might adjust the mode, so go through the
+* possible crtcs (technically just one) and call
+* mode_fixup to figure out the adjusted mode before we
+* validate it.
+*/
+   drm_for_each_crtc(crtc, encoder->dev) {
+   /*
+* reset adj_mode to the mode value each time,
+* so we don't adjust the mode twice
+*/
+   drm_mode_copy(_mode, mode);
+
+   crtc_funcs = crtc->helper_private;
+   if (crtc_funcs && crtc_funcs->mode_fixup)
+   if (!crtc_funcs->mode_fixup(crtc, mode, _mode))
+   return MODE_BAD;
+
+   ret = dsi_encoder_phy_mode_valid(encoder, _mode);
+   if (ret != MODE_OK)
+   return ret;
+   }
+   return MODE_OK;
+}
+
 static void dsi_encoder_mode_set(struct drm_encoder *encoder,
 struct drm_display_mode *mode,
 struct drm_display_mode *adj_mode)
@@ -622,6 +688,7 @@ static int dsi_encoder_atomic_check(struct drm_encoder 
*encoder,
 
 static const struct drm_encoder_helper_funcs dw_encoder_helper_funcs = {
.atomic_check   = dsi_encoder_atomic_check,
+   .mode_valid = dsi_encoder_mode_valid,
.mode_set   = dsi_encoder_mode_set,

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

[John Stultz]

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 upstreaming it!) to ensure we don't select
modes we cannot generate.

Also, since the ade crtc code will adjust the mode in mode_set,
this patch also adds a mode_fixup callback which we use to make
sure we are validating the mode clock that will eventually be
used.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Rob Clark 
Cc: Xinliang Liu 
Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: Jose Abreu 
Cc: Archit Taneja 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v2: Reworked to calculate if modeclock matches the phy's
byteclock, rather then using a whitelist of known modes.

v3: Reworked to check across all possible crtcs (even though for
us there is only one), and use mode_fixup instead of a custom
function, as suggested by Jose and Daniel.

v4: Fixes and improved error handling as suggested by Jose.
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 67 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 14 ++
 2 files changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index f77dcfa..043a50d 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -603,6 +603,72 @@ static void dsi_encoder_enable(struct drm_encoder *encoder)
dsi->enable = true;
 }
 
+static enum drm_mode_status dsi_encoder_phy_mode_valid(
+   struct drm_encoder *encoder,
+   const struct drm_display_mode *mode)
+{
+   struct dw_dsi *dsi = encoder_to_dsi(encoder);
+   struct mipi_phy_params phy;
+   u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+   u32 req_kHz, act_kHz, lane_byte_clk_kHz;
+
+   /* Calculate the lane byte clk using the adjusted mode clk */
+   memset(, 0, sizeof(phy));
+   req_kHz = mode->clock * bpp / dsi->lanes;
+   act_kHz = dsi_calc_phy_rate(req_kHz, );
+   lane_byte_clk_kHz = act_kHz / 8;
+
+   DRM_DEBUG_DRIVER("Checking mode %ix%i-%i@%i clock: %i...",
+   mode->hdisplay, mode->vdisplay, bpp,
+   drm_mode_vrefresh(mode), mode->clock);
+
+   /*
+* Make sure the adjused mode clock and the lane byte clk
+* have a common denominator base frequency
+*/
+   if (mode->clock/dsi->lanes == lane_byte_clk_kHz/3) {
+   DRM_DEBUG_DRIVER("OK!\n");
+   return MODE_OK;
+   }
+
+   DRM_DEBUG_DRIVER("BAD!\n");
+   return MODE_BAD;
+}
+
+static enum drm_mode_status dsi_encoder_mode_valid(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode)
+
+{
+   const struct drm_crtc_helper_funcs *crtc_funcs = NULL;
+   struct drm_crtc *crtc = NULL;
+   struct drm_display_mode adj_mode;
+   enum drm_mode_status ret;
+
+   /*
+* The crtc might adjust the mode, so go through the
+* possible crtcs (technically just one) and call
+* mode_fixup to figure out the adjusted mode before we
+* validate it.
+*/
+   drm_for_each_crtc(crtc, encoder->dev) {
+   /*
+* reset adj_mode to the mode value each time,
+* so we don't adjust the mode twice
+*/
+   drm_mode_copy(_mode, mode);
+
+   crtc_funcs = crtc->helper_private;
+   if (crtc_funcs && crtc_funcs->mode_fixup)
+   if (!crtc_funcs->mode_fixup(crtc, mode, _mode))
+   return MODE_BAD;
+
+   ret = dsi_encoder_phy_mode_valid(encoder, _mode);
+   if (ret != MODE_OK)
+   return ret;
+   }
+   return MODE_OK;
+}
+
 static void dsi_encoder_mode_set(struct drm_encoder *encoder,
 struct drm_display_mode *mode,
 struct drm_display_mode *adj_mode)
@@ -622,6 +688,7 @@ static int dsi_encoder_atomic_check(struct drm_encoder 
*encoder,
 
 static const struct drm_encoder_helper_funcs dw_encoder_helper_funcs = {
.atomic_check   = dsi_encoder_atomic_check,
+   .mode_valid = dsi_encoder_mode_valid,
.mode_set   = dsi_encoder_mode_set,
.enable = dsi_encoder_enable,
.disable= dsi_encoder_disable
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index c96c228..dec7f4e 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ 

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

[Shuah Khan]

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 +++--
 .../functional/futex_wait_private_mapped_file.c  |  6 --
 .../selftests/futex/functional/futex_wait_timeout.c  |  5 +++--
 .../futex/functional/futex_wait_uninitialized_heap.c |  3 ++-
 .../futex/functional/futex_wait_wouldblock.c |  3 ++-
 tools/testing/selftests/futex/include/logging.h  | 20 +---
 8 files changed, 30 insertions(+), 23 deletions(-)

diff --git a/tools/testing/selftests/futex/functional/futex_requeue_pi.c 
b/tools/testing/selftests/futex/functional/futex_requeue_pi.c
index d24ab7421e73..54cd5c414e82 100644
--- a/tools/testing/selftests/futex/functional/futex_requeue_pi.c
+++ b/tools/testing/selftests/futex/functional/futex_requeue_pi.c
@@ -394,9 +394,11 @@ int main(int argc, char *argv[])
}
}
 
-   printf("%s: Test requeue functionality\n", basename(argv[0]));
-   printf("\tArguments: broadcast=%d locked=%d owner=%d timeout=%ldns\n",
-  broadcast, locked, owner, timeout_ns);
+   ksft_print_header();
+   ksft_print_msg("%s: Test requeue functionality\n", basename(argv[0]));
+   ksft_print_msg(
+   "\tArguments: broadcast=%d locked=%d owner=%d timeout=%ldns\n",
+   broadcast, locked, owner, timeout_ns);
 
/*
 * FIXME: unit_test is obsolete now that we parse options and the
diff --git 
a/tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c 
b/tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c
index e0a798ad0d21..08187a16507f 100644
--- a/tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c
+++ b/tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c
@@ -78,7 +78,8 @@ int main(int argc, char *argv[])
}
}
 
-   printf("%s: Detect mismatched requeue_pi operations\n",
+   ksft_print_header();
+   ksft_print_msg("%s: Detect mismatched requeue_pi operations\n",
   basename(argv[0]));
 
if (pthread_create(, NULL, blocking_child, NULL)) {
diff --git 
a/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c 
b/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
index 982f83577501..f0542a344d95 100644
--- a/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
+++ b/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
@@ -143,9 +143,10 @@ int main(int argc, char *argv[])
}
}
 
-   printf("%s: Test signal handling during requeue_pi\n",
+   ksft_print_header();
+   ksft_print_msg("%s: Test signal handling during requeue_pi\n",
   basename(argv[0]));
-   printf("\tArguments: \n");
+   ksft_print_msg("\tArguments: \n");
 
sa.sa_handler = handle_signal;
sigemptyset(_mask);
diff --git 
a/tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c 
b/tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c
index bdc48dc047e5..6216de828093 100644
--- a/tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c
+++ b/tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c
@@ -97,8 +97,10 @@ int main(int argc, char **argv)
}
}
 
-   printf("%s: Test the futex value of private file mappings in 
FUTEX_WAIT\n",
-  basename(argv[0]));
+   ksft_print_header();
+   ksft_print_msg(
+   "%s: Test the futex value of private file mappings in 
FUTEX_WAIT\n",
+   basename(argv[0]));
 
ret = pthread_create(, NULL, thr_futex_wait, NULL);
if (ret < 0) {
diff --git a/tools/testing/selftests/futex/functional/futex_wait_timeout.c 
b/tools/testing/selftests/futex/functional/futex_wait_timeout.c
index 6aadd560366e..bab3dfe1787f 100644
--- a/tools/testing/selftests/futex/functional/futex_wait_timeout.c
+++ b/tools/testing/selftests/futex/functional/futex_wait_timeout.c
@@ -68,9 +68,10 @@ int main(int argc, char *argv[])
}
}
 
-   printf("%s: Block on a futex and wait for timeout\n",
+   ksft_print_header();
+   ksft_print_msg("%s: Block on a futex and wait for timeout\n",
   basename(argv[0]));
-   printf("\tArguments: timeout=%ldns\n", timeout_ns);
+   ksft_print_msg("\tArguments: timeout=%ldns\n", timeout_ns);
 
/* initialize timeout */
to.tv_sec = 0;
diff --git 
a/tools/testing/selftests/futex/functional/futex_wait_uninitialized_heap.c 
b/tools/testing/selftests/futex/functional/futex_wait_uninitialized_heap.c
index d237a8b702f0..26975322545b 100644
--- 

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

[Shuah Khan]

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 +++--
 .../functional/futex_wait_private_mapped_file.c  |  6 --
 .../selftests/futex/functional/futex_wait_timeout.c  |  5 +++--
 .../futex/functional/futex_wait_uninitialized_heap.c |  3 ++-
 .../futex/functional/futex_wait_wouldblock.c |  3 ++-
 tools/testing/selftests/futex/include/logging.h  | 20 +---
 8 files changed, 30 insertions(+), 23 deletions(-)

diff --git a/tools/testing/selftests/futex/functional/futex_requeue_pi.c 
b/tools/testing/selftests/futex/functional/futex_requeue_pi.c
index d24ab7421e73..54cd5c414e82 100644
--- a/tools/testing/selftests/futex/functional/futex_requeue_pi.c
+++ b/tools/testing/selftests/futex/functional/futex_requeue_pi.c
@@ -394,9 +394,11 @@ int main(int argc, char *argv[])
}
}
 
-   printf("%s: Test requeue functionality\n", basename(argv[0]));
-   printf("\tArguments: broadcast=%d locked=%d owner=%d timeout=%ldns\n",
-  broadcast, locked, owner, timeout_ns);
+   ksft_print_header();
+   ksft_print_msg("%s: Test requeue functionality\n", basename(argv[0]));
+   ksft_print_msg(
+   "\tArguments: broadcast=%d locked=%d owner=%d timeout=%ldns\n",
+   broadcast, locked, owner, timeout_ns);
 
/*
 * FIXME: unit_test is obsolete now that we parse options and the
diff --git 
a/tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c 
b/tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c
index e0a798ad0d21..08187a16507f 100644
--- a/tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c
+++ b/tools/testing/selftests/futex/functional/futex_requeue_pi_mismatched_ops.c
@@ -78,7 +78,8 @@ int main(int argc, char *argv[])
}
}
 
-   printf("%s: Detect mismatched requeue_pi operations\n",
+   ksft_print_header();
+   ksft_print_msg("%s: Detect mismatched requeue_pi operations\n",
   basename(argv[0]));
 
if (pthread_create(, NULL, blocking_child, NULL)) {
diff --git 
a/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c 
b/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
index 982f83577501..f0542a344d95 100644
--- a/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
+++ b/tools/testing/selftests/futex/functional/futex_requeue_pi_signal_restart.c
@@ -143,9 +143,10 @@ int main(int argc, char *argv[])
}
}
 
-   printf("%s: Test signal handling during requeue_pi\n",
+   ksft_print_header();
+   ksft_print_msg("%s: Test signal handling during requeue_pi\n",
   basename(argv[0]));
-   printf("\tArguments: \n");
+   ksft_print_msg("\tArguments: \n");
 
sa.sa_handler = handle_signal;
sigemptyset(_mask);
diff --git 
a/tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c 
b/tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c
index bdc48dc047e5..6216de828093 100644
--- a/tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c
+++ b/tools/testing/selftests/futex/functional/futex_wait_private_mapped_file.c
@@ -97,8 +97,10 @@ int main(int argc, char **argv)
}
}
 
-   printf("%s: Test the futex value of private file mappings in 
FUTEX_WAIT\n",
-  basename(argv[0]));
+   ksft_print_header();
+   ksft_print_msg(
+   "%s: Test the futex value of private file mappings in 
FUTEX_WAIT\n",
+   basename(argv[0]));
 
ret = pthread_create(, NULL, thr_futex_wait, NULL);
if (ret < 0) {
diff --git a/tools/testing/selftests/futex/functional/futex_wait_timeout.c 
b/tools/testing/selftests/futex/functional/futex_wait_timeout.c
index 6aadd560366e..bab3dfe1787f 100644
--- a/tools/testing/selftests/futex/functional/futex_wait_timeout.c
+++ b/tools/testing/selftests/futex/functional/futex_wait_timeout.c
@@ -68,9 +68,10 @@ int main(int argc, char *argv[])
}
}
 
-   printf("%s: Block on a futex and wait for timeout\n",
+   ksft_print_header();
+   ksft_print_msg("%s: Block on a futex and wait for timeout\n",
   basename(argv[0]));
-   printf("\tArguments: timeout=%ldns\n", timeout_ns);
+   ksft_print_msg("\tArguments: timeout=%ldns\n", timeout_ns);
 
/* initialize timeout */
to.tv_sec = 0;
diff --git 
a/tools/testing/selftests/futex/functional/futex_wait_uninitialized_heap.c 
b/tools/testing/selftests/futex/functional/futex_wait_uninitialized_heap.c
index d237a8b702f0..26975322545b 100644
---