Re: [PATCH v2] staging: bcm2835-audio: Release resources on module_exit()

[Kirill Marinushkin]

On 03/13/18 22:23, Andy Shevchenko wrote:
> On Tue, Mar 13, 2018 at 9:34 PM, Kirill Marinushkin
>  wrote:
>> In the current implementation, `rmmod snd_bcm2835` does not release
>> resources properly. It causes an oops when trying to list sound devices.
>>
>> This commit fixes it.
> Nice catch!
>
> See my comments below.
>
>>  static void snd_devm_unregister_child(struct device *dev, void *res)
>>  {
>> struct device *childdev = *(struct device **)res;
>> +   struct bcm2835_chip *chip = dev_get_drvdata(childdev);
>> +   struct snd_card *card = chip->card;
>> +
>> +   snd_card_free(card);
>> +   dev_set_drvdata(childdev, NULL);
> AFAIU this is done by device core.

Maybe you are right. But I don't know, which function in the device core does 
it.
It is safe to have this line. So, I suggest to keep it.

>
>> device_unregister(childdev);
>>  }
>> +static void snd_devm_release(struct device *dev)
>> +{
>> +   struct bcm2835_chip *chip = dev_get_drvdata(dev);
>> +
>> +   kfree(chip);
>> +}
>
>>  /* chip-specific constructor
>> @@ -122,7 +136,7 @@ static int snd_bcm2835_create(struct snd_card *card,
>>
>> err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, );
>> if (err) {
>> -   snd_bcm2835_free(chip);
>> +   kfree(chip);
> Do you call device_register() inside snd_device_new()?
> In this case you might need put_device() here instead of simple kfree().

No, from what I see, device_register() does not happen inside snd_device_new().

>> return err;
>> }

Re: [PATCH v2] staging: bcm2835-audio: Release resources on module_exit()

[Kirill Marinushkin]

On 03/13/18 22:23, Andy Shevchenko wrote:
> On Tue, Mar 13, 2018 at 9:34 PM, Kirill Marinushkin
>  wrote:
>> In the current implementation, `rmmod snd_bcm2835` does not release
>> resources properly. It causes an oops when trying to list sound devices.
>>
>> This commit fixes it.
> Nice catch!
>
> See my comments below.
>
>>  static void snd_devm_unregister_child(struct device *dev, void *res)
>>  {
>> struct device *childdev = *(struct device **)res;
>> +   struct bcm2835_chip *chip = dev_get_drvdata(childdev);
>> +   struct snd_card *card = chip->card;
>> +
>> +   snd_card_free(card);
>> +   dev_set_drvdata(childdev, NULL);
> AFAIU this is done by device core.

Maybe you are right. But I don't know, which function in the device core does 
it.
It is safe to have this line. So, I suggest to keep it.

>
>> device_unregister(childdev);
>>  }
>> +static void snd_devm_release(struct device *dev)
>> +{
>> +   struct bcm2835_chip *chip = dev_get_drvdata(dev);
>> +
>> +   kfree(chip);
>> +}
>
>>  /* chip-specific constructor
>> @@ -122,7 +136,7 @@ static int snd_bcm2835_create(struct snd_card *card,
>>
>> err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, );
>> if (err) {
>> -   snd_bcm2835_free(chip);
>> +   kfree(chip);
> Do you call device_register() inside snd_device_new()?
> In this case you might need put_device() here instead of simple kfree().

No, from what I see, device_register() does not happen inside snd_device_new().

>> return err;
>> }

Re: [PATCH v2] kbuild: check for pkg-config on make {menu,n,g,x}config

[Masahiro Yamada]

2018-03-13 11:30 GMT+09:00 Randy Dunlap :
> From: Randy Dunlap 
>
> Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
> that other required files are present, but none of these check that
> pkg-config itself is present.  Add a check for all 4 of these targets.
>
> Fixes kernel bugzilla #77511:
> https://bugzilla.kernel.org/show_bug.cgi?id=77511
>
> Signed-off-by: Randy Dunlap 
> ---
> v2: use 'command -v' instead of 'which'
>
> I'm also OK with just documenting the pkg-config requirement in
> Documentation/Changes (= Documentation/process/changes.rst).
>
>  scripts/kconfig/Makefile   |   15 ++-
>  scripts/kconfig/check-pkgconfig.sh |   12 
>  2 files changed, 26 insertions(+), 1 deletion(-)
>
> --- lnx-416-rc3.orig/scripts/kconfig/Makefile
> +++ lnx-416-rc3/scripts/kconfig/Makefile
> @@ -160,6 +160,9 @@ help:
> @echo  '  xenconfig   - Enable additional options for xen dom0 
> and guest kernel support'
> @echo  '  tinyconfig  - Configure the tiniest possible kernel'
>
> +# pkg-config check
> +check-pkgconfig  := $(srctree)/$(src)/check-pkgconfig.sh
> +
>  # lxdialog stuff
>  check-lxdialog  := $(srctree)/$(src)/lxdialog/check-lxdialog.sh
>
> @@ -205,7 +208,17 @@ $(addprefix $(obj)/, mconf.o $(lxdialog)
>  $(obj)/dochecklxdialog:
> $(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) 
> $(HOST_EXTRACFLAGS) $(HOSTLOADLIBES_mconf)
>
> -always := dochecklxdialog
> +# Check that we have pkg-config (used by each of menu/n/g/xconfig)
> +PHONY += $(obj)/docheckpkgconfig
> +$(addprefix $(obj)/, mconf.o): $(obj)/docheckpkgconfig
> +$(addprefix $(obj)/, nconf.o): $(obj)/docheckpkgconfig
> +$(addprefix $(obj)/, gconf.o): $(obj)/docheckpkgconfig
> +$(addprefix $(obj)/, qconf.o): $(obj)/docheckpkgconfig
> +
> +$(obj)/docheckpkgconfig:
> +   $(Q)$(CONFIG_SHELL) $(check-pkgconfig)
> +
> +always := docheckpkgconfig dochecklxdialog


I did not test this patch, but does this check work as expected?

Probably we want to run 'docheckpkgconfig'
before 'dochecklxdiag', '.tmp_gtkcheck', '.tmp_qtcheck', etc.
But, I do not see such dependencies.


Also, if we make 'pkg-config' mandatory,
should we entirely drop fall-back logics like follows?

https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L10
https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L29
https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/Makefile#L230


What do you think?


>  # Add environment specific flags
>  HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(srctree)/$(src)/check.sh 
> $(HOSTCC) $(HOSTCFLAGS))
> --- /dev/null
> +++ lnx-416-rc3/scripts/kconfig/check-pkgconfig.sh
> @@ -0,0 +1,12 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +# Check for pkg-config presence
> +
> +pkgcfg=`command -v pkg-config`
> +
> +if [ "$pkgcfg" = "" ]; then
> +   echo "'make *config' requires 'pkg-config'. Please install it." 1>&2
> +   exit 1  # error
> +fi
> +
> +exit 0
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2] kbuild: check for pkg-config on make {menu,n,g,x}config

[Masahiro Yamada]

2018-03-13 11:30 GMT+09:00 Randy Dunlap :
> From: Randy Dunlap 
>
> Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
> that other required files are present, but none of these check that
> pkg-config itself is present.  Add a check for all 4 of these targets.
>
> Fixes kernel bugzilla #77511:
> https://bugzilla.kernel.org/show_bug.cgi?id=77511
>
> Signed-off-by: Randy Dunlap 
> ---
> v2: use 'command -v' instead of 'which'
>
> I'm also OK with just documenting the pkg-config requirement in
> Documentation/Changes (= Documentation/process/changes.rst).
>
>  scripts/kconfig/Makefile   |   15 ++-
>  scripts/kconfig/check-pkgconfig.sh |   12 
>  2 files changed, 26 insertions(+), 1 deletion(-)
>
> --- lnx-416-rc3.orig/scripts/kconfig/Makefile
> +++ lnx-416-rc3/scripts/kconfig/Makefile
> @@ -160,6 +160,9 @@ help:
> @echo  '  xenconfig   - Enable additional options for xen dom0 
> and guest kernel support'
> @echo  '  tinyconfig  - Configure the tiniest possible kernel'
>
> +# pkg-config check
> +check-pkgconfig  := $(srctree)/$(src)/check-pkgconfig.sh
> +
>  # lxdialog stuff
>  check-lxdialog  := $(srctree)/$(src)/lxdialog/check-lxdialog.sh
>
> @@ -205,7 +208,17 @@ $(addprefix $(obj)/, mconf.o $(lxdialog)
>  $(obj)/dochecklxdialog:
> $(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) 
> $(HOST_EXTRACFLAGS) $(HOSTLOADLIBES_mconf)
>
> -always := dochecklxdialog
> +# Check that we have pkg-config (used by each of menu/n/g/xconfig)
> +PHONY += $(obj)/docheckpkgconfig
> +$(addprefix $(obj)/, mconf.o): $(obj)/docheckpkgconfig
> +$(addprefix $(obj)/, nconf.o): $(obj)/docheckpkgconfig
> +$(addprefix $(obj)/, gconf.o): $(obj)/docheckpkgconfig
> +$(addprefix $(obj)/, qconf.o): $(obj)/docheckpkgconfig
> +
> +$(obj)/docheckpkgconfig:
> +   $(Q)$(CONFIG_SHELL) $(check-pkgconfig)
> +
> +always := docheckpkgconfig dochecklxdialog


I did not test this patch, but does this check work as expected?

Probably we want to run 'docheckpkgconfig'
before 'dochecklxdiag', '.tmp_gtkcheck', '.tmp_qtcheck', etc.
But, I do not see such dependencies.


Also, if we make 'pkg-config' mandatory,
should we entirely drop fall-back logics like follows?

https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L10
https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L29
https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/Makefile#L230


What do you think?


>  # Add environment specific flags
>  HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(srctree)/$(src)/check.sh 
> $(HOSTCC) $(HOSTCFLAGS))
> --- /dev/null
> +++ lnx-416-rc3/scripts/kconfig/check-pkgconfig.sh
> @@ -0,0 +1,12 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +# Check for pkg-config presence
> +
> +pkgcfg=`command -v pkg-config`
> +
> +if [ "$pkgcfg" = "" ]; then
> +   echo "'make *config' requires 'pkg-config'. Please install it." 1>&2
> +   exit 1  # error
> +fi
> +
> +exit 0
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v5 16/19] tracing: probeevent: Add array type support

[Ravi Bangoria]

Hi Masami,

On 03/08/2018 02:20 PM, Masami Hiramatsu wrote:
> Add array type support for probe events.
> This allows user to get arraied types from memory address.
> The array type syntax is
>
>   TYPE[N]
>
> Where TYPE is one of types (u8/16/32/64,s8/16/32/64,
> x8/16/32/64, symbol, string) and N is a fixed value less
> than 64.
>
> The string array type is a bit different from other types. For
> other base types, [1] is equal to 
> (e.g. +0(%di):x32[1] is same as +0(%di):x32.) But string[1] is not
> equal to string. The string type itself represents "char array",
> but string array type represents "char * array". So, for example,
> +0(%di):string[1] is equal to +0(+0(%di)):string.

I was trying to test this patch. But I'm not getting proper data.
Here is what I'm doing...

$ cat hello.c
#include 

void foo1(int a[])
{
    printf("%d\n", a[2]);
}

void foo(int a[])
{
    printf("%d\n", a[1]);
    foo1(a);
}

void main()
{
    int a[3] = {4, 5, 6};
    printf("%d\n", a[0]);
    foo(a);
}

$ gcc -g hello.c -o hello
$ sudo ./perf probe -x ~/hello foo1 'a=a:x32[3]'
$ sudo cat /sys/kernel/debug/tracing/uprobe_events
p:probe_hello/foo1 /home/ravi/hello:0x05fc a=+96(%gpr31):x32[3]

$ sudo ./perf record -e probe_hello:foo1 ~/hello
$ sudo ./perf script
hello  6913 [038]  2857.704470: probe_hello:foo1: (15fc) 
a={0xd69e4400,0x7fff,0x0}


I don't see proper values of the 'a'? Anything wrong with my perf commands :) ?

Thanks,
Ravi

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

[Dan Williams]

On Tue, Mar 13, 2018 at 3:20 AM, Peter Zijlstra  wrote:
> On Sun, Mar 11, 2018 at 10:15:55AM -0700, Dan Williams wrote:
>> On Sun, Mar 11, 2018 at 4:27 AM, Peter Zijlstra  wrote:
>> > On Fri, Mar 09, 2018 at 10:55:32PM -0800, Dan Williams wrote:
>> >> Add a generic facility for awaiting an atomic_t to reach a value of 1.
>> >>
>> >> Page reference counts typically need to reach 0 to be considered a
>> >> free / inactive page. However, ZONE_DEVICE pages allocated via
>> >> devm_memremap_pages() are never 'onlined', i.e. the put_page() typically
>> >> done at init time to assign pages to the page allocator is skipped.
>> >>
>> >> These pages will have their reference count elevated > 1 by
>> >> get_user_pages() when they are under DMA. In order to coordinate DMA to
>> >> these pages vs filesytem operations like hole-punch and truncate the
>> >> filesystem-dax implementation needs to capture the DMA-idle event i.e.
>> >> the 2 to 1 count transition).
>> >>
>> >> For now, this implementation does not have functional behavior change,
>> >> follow-on patches will add waiters for these page-idle events.
>> >
>> > Argh, no no no.. That whole wait_for_atomic_t thing is a giant
>> > trainwreck already and now you're making it worse still.
>> >
>> > Please have a look here:
>> >
>> >   
>> > https://lkml.kernel.org/r/20171101190644.chwhfpoz3ywxx...@hirez.programming.kicks-ass.net
>>
>> That thread seems to be worried about the object disappearing the
>> moment it's reference count reaches a target. That isn't the case with
>> the memmap / struct page objects for ZONE_DEVICE pages. I understand
>> wait_for_atomic_one() is broken in the general case, but as far as I
>> can see it works fine specifically for ZONE_DEVICE page busy tracking,
>> just not generic object lifetime.
>
> How's this, compile tested (x86_64-allmodconfig) only.
>
> This allows you to write:
>
> wait_var_event(_atomic, atomic_read(_atomic) == 1);

This works for me, you can add

Tested-by: Dan Williams 

...to the upstream version.

Can we add this new api in an immutable commit tip/sched/core tree, so
I can base my fix on it? The wait_for_atomic_t removal can then come
in follow-on patches.

Re: [PATCH v5 16/19] tracing: probeevent: Add array type support

[Ravi Bangoria]

Hi Masami,

On 03/08/2018 02:20 PM, Masami Hiramatsu wrote:
> Add array type support for probe events.
> This allows user to get arraied types from memory address.
> The array type syntax is
>
>   TYPE[N]
>
> Where TYPE is one of types (u8/16/32/64,s8/16/32/64,
> x8/16/32/64, symbol, string) and N is a fixed value less
> than 64.
>
> The string array type is a bit different from other types. For
> other base types, [1] is equal to 
> (e.g. +0(%di):x32[1] is same as +0(%di):x32.) But string[1] is not
> equal to string. The string type itself represents "char array",
> but string array type represents "char * array". So, for example,
> +0(%di):string[1] is equal to +0(+0(%di)):string.

I was trying to test this patch. But I'm not getting proper data.
Here is what I'm doing...

$ cat hello.c
#include 

void foo1(int a[])
{
    printf("%d\n", a[2]);
}

void foo(int a[])
{
    printf("%d\n", a[1]);
    foo1(a);
}

void main()
{
    int a[3] = {4, 5, 6};
    printf("%d\n", a[0]);
    foo(a);
}

$ gcc -g hello.c -o hello
$ sudo ./perf probe -x ~/hello foo1 'a=a:x32[3]'
$ sudo cat /sys/kernel/debug/tracing/uprobe_events
p:probe_hello/foo1 /home/ravi/hello:0x05fc a=+96(%gpr31):x32[3]

$ sudo ./perf record -e probe_hello:foo1 ~/hello
$ sudo ./perf script
hello  6913 [038]  2857.704470: probe_hello:foo1: (15fc) 
a={0xd69e4400,0x7fff,0x0}


I don't see proper values of the 'a'? Anything wrong with my perf commands :) ?

Thanks,
Ravi

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

[Dan Williams]

On Tue, Mar 13, 2018 at 3:20 AM, Peter Zijlstra  wrote:
> On Sun, Mar 11, 2018 at 10:15:55AM -0700, Dan Williams wrote:
>> On Sun, Mar 11, 2018 at 4:27 AM, Peter Zijlstra  wrote:
>> > On Fri, Mar 09, 2018 at 10:55:32PM -0800, Dan Williams wrote:
>> >> Add a generic facility for awaiting an atomic_t to reach a value of 1.
>> >>
>> >> Page reference counts typically need to reach 0 to be considered a
>> >> free / inactive page. However, ZONE_DEVICE pages allocated via
>> >> devm_memremap_pages() are never 'onlined', i.e. the put_page() typically
>> >> done at init time to assign pages to the page allocator is skipped.
>> >>
>> >> These pages will have their reference count elevated > 1 by
>> >> get_user_pages() when they are under DMA. In order to coordinate DMA to
>> >> these pages vs filesytem operations like hole-punch and truncate the
>> >> filesystem-dax implementation needs to capture the DMA-idle event i.e.
>> >> the 2 to 1 count transition).
>> >>
>> >> For now, this implementation does not have functional behavior change,
>> >> follow-on patches will add waiters for these page-idle events.
>> >
>> > Argh, no no no.. That whole wait_for_atomic_t thing is a giant
>> > trainwreck already and now you're making it worse still.
>> >
>> > Please have a look here:
>> >
>> >   
>> > https://lkml.kernel.org/r/20171101190644.chwhfpoz3ywxx...@hirez.programming.kicks-ass.net
>>
>> That thread seems to be worried about the object disappearing the
>> moment it's reference count reaches a target. That isn't the case with
>> the memmap / struct page objects for ZONE_DEVICE pages. I understand
>> wait_for_atomic_one() is broken in the general case, but as far as I
>> can see it works fine specifically for ZONE_DEVICE page busy tracking,
>> just not generic object lifetime.
>
> How's this, compile tested (x86_64-allmodconfig) only.
>
> This allows you to write:
>
> wait_var_event(_atomic, atomic_read(_atomic) == 1);

This works for me, you can add

Tested-by: Dan Williams 

...to the upstream version.

Can we add this new api in an immutable commit tip/sched/core tree, so
I can base my fix on it? The wait_for_atomic_t removal can then come
in follow-on patches.

Re: [PATCH 00/47] arch-removal: device drivers

[Boris Brezillon]

Hi Arnd,

On Wed, 14 Mar 2018 16:35:13 +0100
Arnd Bergmann  wrote:

> Hi driver maintainers,
> 
> I just posted one series with the removal of eight architectures,
> see https://lkml.org/lkml/2018/3/14/505 for details, or
> https://lwn.net/Articles/748074/ for more background.
> 
> These are the device drivers that go along with them. I have already
> picked up the drivers for arch/metag/ into my tree, they were reviewed
> earlier.
> 
> Please let me know if you have any concerns with the patch, or if you
> prefer to pick up the patches in your respective trees.  I created
> the patches with 'git format-patch -D', so they will not apply without
> manually removing those files.
> 
> For anything else, I'd keep the removal patches in my asm-generic tree
> and will send a pull request for 4.17 along with the actual arch removal.
> 
>Arnd
> 
> Arnd Bergmann
>   edac: remove tile driver
>   net: tile: remove ethernet drivers
>   net: adi: remove blackfin ethernet drivers
>   net: 8390: remove m32r specific bits
>   net: remove cris etrax ethernet driver
>   net: smsc: remove m32r specific smc91x configuration
>   raid: remove tile specific raid6 implementation
>   rtc: remove tile driver
>   rtc: remove bfin driver
>   char: remove obsolete ds1302 rtc driver
>   char: remove tile-srom.c
>   char: remove blackfin OTP driver
>   pcmcia: remove m32r drivers
>   pcmcia: remove blackfin driver
>   ASoC: remove blackfin drivers
>   video/logo: remove obsolete logo files
>   fbdev: remove blackfin drivers
>   fbdev: s1d13xxxfb: remove m32r specific hacks
>   crypto: remove blackfin CRC driver
>   media: platform: remove blackfin capture driver
>   media: platform: remove m32r specific arv driver
>   cpufreq: remove blackfin driver
>   cpufreq: remove cris specific drivers
>   gpio: remove etraxfs driver
>   pinctrl: remove adi2/blackfin drivers
>   ata: remove bf54x driver
>   input: keyboard: remove bf54x driver
>   input: misc: remove blackfin rotary driver
>   mmc: remove bfin_sdh driver
>   can: remove bfin_can driver
>   watchdog: remove bfin_wdt driver
>   mtd: maps: remove bfin-async-flash driver
>   mtd: nand: remove bf5xx_nand driver

If you don't mind, I'd like to take the mtd patches through the MTD
tree. As you've probably noticed, nand code has been moved around and
it's easier for me to carry those 2 simple changes in my tree than
creating an immutable branch.

Let me know if this is a problem.

Regards,

Boris

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 00/47] arch-removal: device drivers

[Boris Brezillon]

Hi Arnd,

On Wed, 14 Mar 2018 16:35:13 +0100
Arnd Bergmann  wrote:

> Hi driver maintainers,
> 
> I just posted one series with the removal of eight architectures,
> see https://lkml.org/lkml/2018/3/14/505 for details, or
> https://lwn.net/Articles/748074/ for more background.
> 
> These are the device drivers that go along with them. I have already
> picked up the drivers for arch/metag/ into my tree, they were reviewed
> earlier.
> 
> Please let me know if you have any concerns with the patch, or if you
> prefer to pick up the patches in your respective trees.  I created
> the patches with 'git format-patch -D', so they will not apply without
> manually removing those files.
> 
> For anything else, I'd keep the removal patches in my asm-generic tree
> and will send a pull request for 4.17 along with the actual arch removal.
> 
>Arnd
> 
> Arnd Bergmann
>   edac: remove tile driver
>   net: tile: remove ethernet drivers
>   net: adi: remove blackfin ethernet drivers
>   net: 8390: remove m32r specific bits
>   net: remove cris etrax ethernet driver
>   net: smsc: remove m32r specific smc91x configuration
>   raid: remove tile specific raid6 implementation
>   rtc: remove tile driver
>   rtc: remove bfin driver
>   char: remove obsolete ds1302 rtc driver
>   char: remove tile-srom.c
>   char: remove blackfin OTP driver
>   pcmcia: remove m32r drivers
>   pcmcia: remove blackfin driver
>   ASoC: remove blackfin drivers
>   video/logo: remove obsolete logo files
>   fbdev: remove blackfin drivers
>   fbdev: s1d13xxxfb: remove m32r specific hacks
>   crypto: remove blackfin CRC driver
>   media: platform: remove blackfin capture driver
>   media: platform: remove m32r specific arv driver
>   cpufreq: remove blackfin driver
>   cpufreq: remove cris specific drivers
>   gpio: remove etraxfs driver
>   pinctrl: remove adi2/blackfin drivers
>   ata: remove bf54x driver
>   input: keyboard: remove bf54x driver
>   input: misc: remove blackfin rotary driver
>   mmc: remove bfin_sdh driver
>   can: remove bfin_can driver
>   watchdog: remove bfin_wdt driver
>   mtd: maps: remove bfin-async-flash driver
>   mtd: nand: remove bf5xx_nand driver

If you don't mind, I'd like to take the mtd patches through the MTD
tree. As you've probably noticed, nand code has been moved around and
it's easier for me to carry those 2 simple changes in my tree than
creating an immutable branch.

Let me know if this is a problem.

Regards,

Boris

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

linux-next: manual merge of the irqchip tree with the nds32 tree

[Stephen Rothwell]

Hi Marc,

Today's linux-next merge of the irqchip tree got a conflict in:

  drivers/irqchip/Makefile

between commit:

  abe45fd9f1b0 ("irqchip: Andestech Internal Vector Interrupt Controller 
driver")

from the nds32 tree and commit:

  f55c73aef890 ("irqchip/pdc: Add PDC interrupt controller for QCOM SoCs")

from the irqchip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/irqchip/Makefile
index 110de02bb215,c35ee5345a53..
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@@ -83,4 -85,4 +83,5 @@@ obj-$(CONFIG_IRQ_UNIPHIER_AIDET)  += irq
  obj-$(CONFIG_ARCH_SYNQUACER)  += irq-sni-exiu.o
  obj-$(CONFIG_MESON_IRQ_GPIO)  += irq-meson-gpio.o
  obj-$(CONFIG_GOLDFISH_PIC)+= irq-goldfish-pic.o
 +obj-$(CONFIG_NDS32)   += irq-ativic32.o
+ obj-$(CONFIG_QCOM_PDC)+= qcom-pdc.o


pgpOV2OhLAKRj.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the irqchip tree with the nds32 tree

[Stephen Rothwell]

Hi Marc,

Today's linux-next merge of the irqchip tree got a conflict in:

  drivers/irqchip/Makefile

between commit:

  abe45fd9f1b0 ("irqchip: Andestech Internal Vector Interrupt Controller 
driver")

from the nds32 tree and commit:

  f55c73aef890 ("irqchip/pdc: Add PDC interrupt controller for QCOM SoCs")

from the irqchip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/irqchip/Makefile
index 110de02bb215,c35ee5345a53..
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@@ -83,4 -85,4 +83,5 @@@ obj-$(CONFIG_IRQ_UNIPHIER_AIDET)  += irq
  obj-$(CONFIG_ARCH_SYNQUACER)  += irq-sni-exiu.o
  obj-$(CONFIG_MESON_IRQ_GPIO)  += irq-meson-gpio.o
  obj-$(CONFIG_GOLDFISH_PIC)+= irq-goldfish-pic.o
 +obj-$(CONFIG_NDS32)   += irq-ativic32.o
+ obj-$(CONFIG_QCOM_PDC)+= qcom-pdc.o


pgpOV2OhLAKRj.pgp
Description: OpenPGP digital signature

Re: [PATCH 12/16] asm-generic: siginfo: remove obsolete #ifdefs

[Dominik Brodowski]

On Wed, Mar 14, 2018 at 09:40:28PM +0100, Arnd Bergmann wrote:
> On Wed, Mar 14, 2018 at 9:31 PM, Dominik Brodowski
>  wrote:
> > On Wed, Mar 14, 2018 at 03:43:47PM +0100, Arnd Bergmann wrote:
> >> The frv, tile and blackfin architectures are being removed, so
> >> we can clean up this header by removing all the special cases
> >> except those for ia64.
> >>
> >> Signed-off-by: Arnd Bergmann 
> >
> > AFAICS, score is the only architecture which still defines
> >
> > __ARCH_WANT_SYSCALL_NO_FLAGS
> > __ARCH_WANT_SYSCALL_OFF_T
> > __ARCH_WANT_SYSCALL_DEPRECATED .
> >
> > So maybe you want to clean up include/uapi/asm-generic/unistd.h as well?
> 
> Definitely. In fact, this was patch 14/16, but for some reason the mail never
> made it out. I tried again and it should be there now.

Thanks!

Dominik

Re: [PATCH 12/16] asm-generic: siginfo: remove obsolete #ifdefs

[Dominik Brodowski]

On Wed, Mar 14, 2018 at 09:40:28PM +0100, Arnd Bergmann wrote:
> On Wed, Mar 14, 2018 at 9:31 PM, Dominik Brodowski
>  wrote:
> > On Wed, Mar 14, 2018 at 03:43:47PM +0100, Arnd Bergmann wrote:
> >> The frv, tile and blackfin architectures are being removed, so
> >> we can clean up this header by removing all the special cases
> >> except those for ia64.
> >>
> >> Signed-off-by: Arnd Bergmann 
> >
> > AFAICS, score is the only architecture which still defines
> >
> > __ARCH_WANT_SYSCALL_NO_FLAGS
> > __ARCH_WANT_SYSCALL_OFF_T
> > __ARCH_WANT_SYSCALL_DEPRECATED .
> >
> > So maybe you want to clean up include/uapi/asm-generic/unistd.h as well?
> 
> Definitely. In fact, this was patch 14/16, but for some reason the mail never
> made it out. I tried again and it should be there now.

Thanks!

Dominik

Re: [PATCH v2] ARM: dts: msm8974: castor: Fix typo and add startup delay in touchscreen node

[Andy Gross]

On Tue, Mar 13, 2018 at 04:46:38PM +, Craig Tatlor wrote:
> The compatible string was mistakenly pulled from the downstream tree and the
> startup delay property is needed to prevent io errors on initial page select.
> 
> Signed-off-by: Craig Tatlor 

Thanks for the patch.  I'll add Bjorn's reviewed-by and apply it.

Regards,
Andy

Re: [PATCH v2] ARM: dts: msm8974: castor: Fix typo and add startup delay in touchscreen node

[Andy Gross]

On Tue, Mar 13, 2018 at 04:46:38PM +, Craig Tatlor wrote:
> The compatible string was mistakenly pulled from the downstream tree and the
> startup delay property is needed to prevent io errors on initial page select.
> 
> Signed-off-by: Craig Tatlor 

Thanks for the patch.  I'll add Bjorn's reviewed-by and apply it.

Regards,
Andy

Re: [RFC v2 04/83] NOVA inode definition.

[Darrick J. Wong]

On Sat, Mar 10, 2018 at 10:17:45AM -0800, Andiry Xu wrote:
> From: Andiry Xu 
> 
> inode.h defines the non-volatile and volatile NOVA inode data structures.
> 
> The non-volatile NOVA inode (nova_inode) is aligned to 128 bytes and contains
> file/directory metadata information. The most important fields
> are log_head and log_tail. log_head points to the start of
> the log, and log_tail points to the end of the latest committed
> log entry. NOVA make updates to the inode by appending
> to the log tail and update the log_tail pointer atomically.
> 
> The volatile NOVA inode (nova_inode_info) contains necessary
> information to limit access to the non-volatile NOVA inode during runtime.
> It has a radix tree to map file offset or filenames to the corresponding
> log entries.
> 
> Signed-off-by: Andiry Xu 
> ---
>  fs/nova/inode.h | 187 
> 
>  1 file changed, 187 insertions(+)
>  create mode 100644 fs/nova/inode.h
> 
> diff --git a/fs/nova/inode.h b/fs/nova/inode.h
> new file mode 100644
> index 000..f9187e3
> --- /dev/null
> +++ b/fs/nova/inode.h
> @@ -0,0 +1,187 @@
> +#ifndef __INODE_H
> +#define __INODE_H
> +
> +struct nova_inode_info_header;
> +struct nova_inode;
> +
> +#include "super.h"
> +
> +enum nova_new_inode_type {
> + TYPE_CREATE = 0,
> + TYPE_MKNOD,
> + TYPE_SYMLINK,
> + TYPE_MKDIR
> +};
> +
> +
> +/*
> + * Structure of an inode in PMEM
> + * Keep the inode size to within 120 bytes: We use the last eight bytes
> + * as inode table tail pointer.

I would've expected a
BUILD_BUG_ON(NOVA_INODE_SIZE - sizeof(struct nova_inode) == 8);
or something to enforce this.

(Or just equate inode number with byte offset?  I looked ahead at the
directory entries and they seem to be 64-bit...)

I guess I'm being lazy and doing a on-disk-format-only review. :)

> + */
> +struct nova_inode {
> +
> + /* first 40 bytes */
> + u8  i_rsvd;  /* reserved. used to be checksum */

Magic number?

> + u8  valid;   /* Is this inode valid? */
> + u8  deleted; /* Is this inode deleted? */

Would i_mode == 0 cover these?

> + u8  i_blk_type;  /* data block size this inode uses */

I would've thought these would just be bits of i_flags?

Also, if I have a 1G blocksize file and free space fragments to the
point that there's > 1G of free space but none of it contiguous, I guess
I can expect ENOSPC?

> + __le32  i_flags; /* Inode flags */
> + __le64  i_size;  /* Size of data in bytes */
> + __le32  i_ctime; /* Inode modification time */
> + __le32  i_mtime; /* Inode b-tree Modification time */
> + __le32  i_atime; /* Access time */

Same y2038 grumble from the previous patch.

> + __le16  i_mode;  /* File mode */
> + __le16  i_links_count;   /* Links count */
> +
> + __le64  i_xattr; /* Extended attribute block */
> +
> + /* second 40 bytes */
> + __le32  i_uid;   /* Owner Uid */
> + __le32  i_gid;   /* Group Id */
> + __le32  i_generation;/* File version (for NFS) */
> + __le32  i_create_time;   /* Create time */
> + __le64  nova_ino;/* nova inode number */
> +
> + __le64  log_head;/* Log head pointer */
> + __le64  log_tail;/* Log tail pointer */
> +
> + /* last 40 bytes */
> + __le64  create_epoch_id; /* Transaction ID when create */
> + __le64  delete_epoch_id; /* Transaction ID when deleted */
> +
> + struct {
> + __le32 rdev; /* major/minor # */
> + } dev;   /* device inode */
> +
> + __le32  csum;/* CRC32 checksum */
> + /* Leave 8 bytes for inode table tail pointer */
> +} __attribute((__packed__));
> +
> +/*
> + * NOVA-specific inode state kept in DRAM
> + */
> +struct nova_inode_info_header {
> + /* For files, tree holds a map from file offsets to
> +  * write log entries.
> +  *
> +  * For directories, tree holds a map from a hash of the file name to
> +  * dentry log entry.
> +  */
> + struct radix_tree_root tree;
> + struct rw_semaphore i_sem;  /* Protect log and tree */
> + unsigned short i_mode;  /* Dir or file? */
> + unsigned int i_flags;
> + unsigned long log_pages;/* Num of log pages */
> + unsigned long i_size;
> + unsigned long i_blocks;
> + unsigned long ino;
> + unsigned long pi_addr;
> + unsigned long valid_entries;/* For thorough GC */
> + unsigned long num_entries;  /* For thorough GC */
> + u64 last_setattr;   /* Last setattr entry */
> + u64 last_link_change;   /* Last link change entry */
> + u64 last_dentry;/* Last updated dentry */
> + u64 trans_id;   /* Transaction ID */
> + u64 log_head;   /* Log head pointer 

Re: [RFC v2 04/83] NOVA inode definition.

[Darrick J. Wong]

On Sat, Mar 10, 2018 at 10:17:45AM -0800, Andiry Xu wrote:
> From: Andiry Xu 
> 
> inode.h defines the non-volatile and volatile NOVA inode data structures.
> 
> The non-volatile NOVA inode (nova_inode) is aligned to 128 bytes and contains
> file/directory metadata information. The most important fields
> are log_head and log_tail. log_head points to the start of
> the log, and log_tail points to the end of the latest committed
> log entry. NOVA make updates to the inode by appending
> to the log tail and update the log_tail pointer atomically.
> 
> The volatile NOVA inode (nova_inode_info) contains necessary
> information to limit access to the non-volatile NOVA inode during runtime.
> It has a radix tree to map file offset or filenames to the corresponding
> log entries.
> 
> Signed-off-by: Andiry Xu 
> ---
>  fs/nova/inode.h | 187 
> 
>  1 file changed, 187 insertions(+)
>  create mode 100644 fs/nova/inode.h
> 
> diff --git a/fs/nova/inode.h b/fs/nova/inode.h
> new file mode 100644
> index 000..f9187e3
> --- /dev/null
> +++ b/fs/nova/inode.h
> @@ -0,0 +1,187 @@
> +#ifndef __INODE_H
> +#define __INODE_H
> +
> +struct nova_inode_info_header;
> +struct nova_inode;
> +
> +#include "super.h"
> +
> +enum nova_new_inode_type {
> + TYPE_CREATE = 0,
> + TYPE_MKNOD,
> + TYPE_SYMLINK,
> + TYPE_MKDIR
> +};
> +
> +
> +/*
> + * Structure of an inode in PMEM
> + * Keep the inode size to within 120 bytes: We use the last eight bytes
> + * as inode table tail pointer.

I would've expected a
BUILD_BUG_ON(NOVA_INODE_SIZE - sizeof(struct nova_inode) == 8);
or something to enforce this.

(Or just equate inode number with byte offset?  I looked ahead at the
directory entries and they seem to be 64-bit...)

I guess I'm being lazy and doing a on-disk-format-only review. :)

> + */
> +struct nova_inode {
> +
> + /* first 40 bytes */
> + u8  i_rsvd;  /* reserved. used to be checksum */

Magic number?

> + u8  valid;   /* Is this inode valid? */
> + u8  deleted; /* Is this inode deleted? */

Would i_mode == 0 cover these?

> + u8  i_blk_type;  /* data block size this inode uses */

I would've thought these would just be bits of i_flags?

Also, if I have a 1G blocksize file and free space fragments to the
point that there's > 1G of free space but none of it contiguous, I guess
I can expect ENOSPC?

> + __le32  i_flags; /* Inode flags */
> + __le64  i_size;  /* Size of data in bytes */
> + __le32  i_ctime; /* Inode modification time */
> + __le32  i_mtime; /* Inode b-tree Modification time */
> + __le32  i_atime; /* Access time */

Same y2038 grumble from the previous patch.

> + __le16  i_mode;  /* File mode */
> + __le16  i_links_count;   /* Links count */
> +
> + __le64  i_xattr; /* Extended attribute block */
> +
> + /* second 40 bytes */
> + __le32  i_uid;   /* Owner Uid */
> + __le32  i_gid;   /* Group Id */
> + __le32  i_generation;/* File version (for NFS) */
> + __le32  i_create_time;   /* Create time */
> + __le64  nova_ino;/* nova inode number */
> +
> + __le64  log_head;/* Log head pointer */
> + __le64  log_tail;/* Log tail pointer */
> +
> + /* last 40 bytes */
> + __le64  create_epoch_id; /* Transaction ID when create */
> + __le64  delete_epoch_id; /* Transaction ID when deleted */
> +
> + struct {
> + __le32 rdev; /* major/minor # */
> + } dev;   /* device inode */
> +
> + __le32  csum;/* CRC32 checksum */
> + /* Leave 8 bytes for inode table tail pointer */
> +} __attribute((__packed__));
> +
> +/*
> + * NOVA-specific inode state kept in DRAM
> + */
> +struct nova_inode_info_header {
> + /* For files, tree holds a map from file offsets to
> +  * write log entries.
> +  *
> +  * For directories, tree holds a map from a hash of the file name to
> +  * dentry log entry.
> +  */
> + struct radix_tree_root tree;
> + struct rw_semaphore i_sem;  /* Protect log and tree */
> + unsigned short i_mode;  /* Dir or file? */
> + unsigned int i_flags;
> + unsigned long log_pages;/* Num of log pages */
> + unsigned long i_size;
> + unsigned long i_blocks;
> + unsigned long ino;
> + unsigned long pi_addr;
> + unsigned long valid_entries;/* For thorough GC */
> + unsigned long num_entries;  /* For thorough GC */
> + u64 last_setattr;   /* Last setattr entry */
> + u64 last_link_change;   /* Last link change entry */
> + u64 last_dentry;/* Last updated dentry */
> + u64 trans_id;   /* Transaction ID */
> + u64 log_head;   /* Log head pointer */
> + u64 log_tail;  

linux-next: manual merge of the spi tree with the asm-generic tree

[Stephen Rothwell]

Hi Mark,

Today's linux-next merge of the spi tree got a conflict in:

  drivers/spi/Kconfig

between commit:

  588020dcb92a ("treewide: simplify Kconfig dependencies for removed archs")

from the asm-generic tree and commit:

  e3d001a0c29d ("spi: kconfig: Remove AVR32 dep. from SPI_ATMEL")

from the spi tree.

I fixed it up (I just used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpdsP65urGwr.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the spi tree with the asm-generic tree

[Stephen Rothwell]

Hi Mark,

Today's linux-next merge of the spi tree got a conflict in:

  drivers/spi/Kconfig

between commit:

  588020dcb92a ("treewide: simplify Kconfig dependencies for removed archs")

from the asm-generic tree and commit:

  e3d001a0c29d ("spi: kconfig: Remove AVR32 dep. from SPI_ATMEL")

from the spi tree.

I fixed it up (I just used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpdsP65urGwr.pgp
Description: OpenPGP digital signature

Re: [RFC v2 03/83] Add super.h.

[Darrick J. Wong]

On Sat, Mar 10, 2018 at 10:17:44AM -0800, Andiry Xu wrote:
> From: Andiry Xu 
> 
> This header file defines NOVA persistent and volatile superblock
> data structures.
> 
> It also defines NOVA block layout:
> 
> Page 0: Superblock
> Page 1: Reserved inodes
> Page 2 - 15: Reserved
> Page 16 - 31: Inode table pointers
> Page 32 - 47: Journal address pointers
> Page 48 - 63: Reserved
> Pages n-2: Replicate reserved inodes
> Pages n-1: Replicate superblock
> 
> Other pages are for normal inodes, logs and data.
> 
> Signed-off-by: Andiry Xu 
> ---
>  fs/nova/super.h | 149 
> 
>  1 file changed, 149 insertions(+)
>  create mode 100644 fs/nova/super.h
> 
> diff --git a/fs/nova/super.h b/fs/nova/super.h
> new file mode 100644
> index 000..cb53908
> --- /dev/null
> +++ b/fs/nova/super.h
> @@ -0,0 +1,149 @@
> +#ifndef __SUPER_H
> +#define __SUPER_H
> +/*
> + * Structure of the NOVA super block in PMEM
> + *
> + * The fields are partitioned into static and dynamic fields. The static 
> fields
> + * never change after file system creation. This was primarily done because
> + * nova_get_block() returns NULL if the block offset is 0 (helps in catching
> + * bugs). So if we modify any field using journaling (for consistency), we
> + * will have to modify s_sum which is at offset 0. So journaling code fails.
> + * This (static+dynamic fields) is a temporary solution and can be avoided
> + * once the file system becomes stable and nova_get_block() returns correct
> + * pointers even for offset 0.
> + */
> +struct nova_super_block {
> + /* static fields. they never change after file system creation.
> +  * checksum only validates up to s_start_dynamic field below
> +  */
> + __le32  s_sum;  /* checksum of this sb */
> + __le32  s_magic;/* magic signature */
> + __le32  s_padding32;
> + __le32  s_blocksize;/* blocksize in bytes */
> + __le64  s_size; /* total size of fs in bytes */
> + chars_volume_name[16];  /* volume name */
> +
> + /* all the dynamic fields should go here */
> + __le64  s_epoch_id; /* Epoch ID */
> +
> + /* s_mtime and s_wtime should be together and their order should not be
> +  * changed. we use an 8 byte write to update both of them atomically
> +  */
> + __le32  s_mtime;/* mount time */
> + __le32  s_wtime;/* write time */

Hmmm, 32-bit timestamps?  2038 isn't that far away...

> +} __attribute((__packed__));
> +
> +#define NOVA_SB_SIZE 512   /* must be power of two */
> +
> +/* === Reserved blocks = */
> +
> +/*
> + * Page 0 contains super blocks;
> + * Page 1 contains reserved inodes;
> + * Page 2 - 15 are reserved.
> + * Page 16 - 31 contain pointers to inode tables.
> + * Page 32 - 47 contain pointers to journal pages.
> + */
> +#define  HEAD_RESERVED_BLOCKS64
> +#define  NUM_JOURNAL_PAGES   16
> +
> +#define  SUPER_BLOCK_START   0 // Superblock
> +#define  RESERVE_INODE_START 1 // Reserved inodes
> +#define  INODE_TABLE_START   16 // inode table pointers
> +#define  JOURNAL_START   32 // journal pointer table
> +
> +/* For replica super block and replica reserved inodes */
> +#define  TAIL_RESERVED_BLOCKS2
> +
> +/* === Reserved inodes = */
> +
> +/* We have space for 31 reserved inodes */
> +#define NOVA_ROOT_INO(1)
> +#define NOVA_INODETABLE_INO  (2) /* Fake inode associated with inode
> +  * stroage.  We need this because our
> +  * allocator requires inode to be
> +  * associated with each allocation.
> +  * The data actually lives in linked
> +  * lists in INODE_TABLE_START. */
> +#define NOVA_BLOCKNODE_INO   (3) /* Storage for allocator state */
> +#define NOVA_LITEJOURNAL_INO (4) /* Storage for lightweight journals */
> +#define NOVA_INODELIST_INO   (5) /* Storage for Inode free list */
> +
> +
> +/* Normal inode starts at 32 */
> +#define NOVA_NORMAL_INODE_START  (32)

I've been wondering this whole time, why not make the inode number the
byte offset into the pmem?  Then you don't have to lose the last 8 bytes
of each inode block to point to the next one.

--D

> +
> +
> +
> +/*
> + * NOVA super-block data in DRAM
> + */
> +struct nova_sb_info {
> + struct super_block *sb; /* VFS super block */
> + struct nova_super_block *nova_sb;   /* DRAM copy of SB */
> + struct block_device *s_bdev;
> + struct dax_device *s_dax_dev;
> +
> + /*
> +  * 

Re: [RFC v2 03/83] Add super.h.

[Darrick J. Wong]

On Sat, Mar 10, 2018 at 10:17:44AM -0800, Andiry Xu wrote:
> From: Andiry Xu 
> 
> This header file defines NOVA persistent and volatile superblock
> data structures.
> 
> It also defines NOVA block layout:
> 
> Page 0: Superblock
> Page 1: Reserved inodes
> Page 2 - 15: Reserved
> Page 16 - 31: Inode table pointers
> Page 32 - 47: Journal address pointers
> Page 48 - 63: Reserved
> Pages n-2: Replicate reserved inodes
> Pages n-1: Replicate superblock
> 
> Other pages are for normal inodes, logs and data.
> 
> Signed-off-by: Andiry Xu 
> ---
>  fs/nova/super.h | 149 
> 
>  1 file changed, 149 insertions(+)
>  create mode 100644 fs/nova/super.h
> 
> diff --git a/fs/nova/super.h b/fs/nova/super.h
> new file mode 100644
> index 000..cb53908
> --- /dev/null
> +++ b/fs/nova/super.h
> @@ -0,0 +1,149 @@
> +#ifndef __SUPER_H
> +#define __SUPER_H
> +/*
> + * Structure of the NOVA super block in PMEM
> + *
> + * The fields are partitioned into static and dynamic fields. The static 
> fields
> + * never change after file system creation. This was primarily done because
> + * nova_get_block() returns NULL if the block offset is 0 (helps in catching
> + * bugs). So if we modify any field using journaling (for consistency), we
> + * will have to modify s_sum which is at offset 0. So journaling code fails.
> + * This (static+dynamic fields) is a temporary solution and can be avoided
> + * once the file system becomes stable and nova_get_block() returns correct
> + * pointers even for offset 0.
> + */
> +struct nova_super_block {
> + /* static fields. they never change after file system creation.
> +  * checksum only validates up to s_start_dynamic field below
> +  */
> + __le32  s_sum;  /* checksum of this sb */
> + __le32  s_magic;/* magic signature */
> + __le32  s_padding32;
> + __le32  s_blocksize;/* blocksize in bytes */
> + __le64  s_size; /* total size of fs in bytes */
> + chars_volume_name[16];  /* volume name */
> +
> + /* all the dynamic fields should go here */
> + __le64  s_epoch_id; /* Epoch ID */
> +
> + /* s_mtime and s_wtime should be together and their order should not be
> +  * changed. we use an 8 byte write to update both of them atomically
> +  */
> + __le32  s_mtime;/* mount time */
> + __le32  s_wtime;/* write time */

Hmmm, 32-bit timestamps?  2038 isn't that far away...

> +} __attribute((__packed__));
> +
> +#define NOVA_SB_SIZE 512   /* must be power of two */
> +
> +/* === Reserved blocks = */
> +
> +/*
> + * Page 0 contains super blocks;
> + * Page 1 contains reserved inodes;
> + * Page 2 - 15 are reserved.
> + * Page 16 - 31 contain pointers to inode tables.
> + * Page 32 - 47 contain pointers to journal pages.
> + */
> +#define  HEAD_RESERVED_BLOCKS64
> +#define  NUM_JOURNAL_PAGES   16
> +
> +#define  SUPER_BLOCK_START   0 // Superblock
> +#define  RESERVE_INODE_START 1 // Reserved inodes
> +#define  INODE_TABLE_START   16 // inode table pointers
> +#define  JOURNAL_START   32 // journal pointer table
> +
> +/* For replica super block and replica reserved inodes */
> +#define  TAIL_RESERVED_BLOCKS2
> +
> +/* === Reserved inodes = */
> +
> +/* We have space for 31 reserved inodes */
> +#define NOVA_ROOT_INO(1)
> +#define NOVA_INODETABLE_INO  (2) /* Fake inode associated with inode
> +  * stroage.  We need this because our
> +  * allocator requires inode to be
> +  * associated with each allocation.
> +  * The data actually lives in linked
> +  * lists in INODE_TABLE_START. */
> +#define NOVA_BLOCKNODE_INO   (3) /* Storage for allocator state */
> +#define NOVA_LITEJOURNAL_INO (4) /* Storage for lightweight journals */
> +#define NOVA_INODELIST_INO   (5) /* Storage for Inode free list */
> +
> +
> +/* Normal inode starts at 32 */
> +#define NOVA_NORMAL_INODE_START  (32)

I've been wondering this whole time, why not make the inode number the
byte offset into the pmem?  Then you don't have to lose the last 8 bytes
of each inode block to point to the next one.

--D

> +
> +
> +
> +/*
> + * NOVA super-block data in DRAM
> + */
> +struct nova_sb_info {
> + struct super_block *sb; /* VFS super block */
> + struct nova_super_block *nova_sb;   /* DRAM copy of SB */
> + struct block_device *s_bdev;
> + struct dax_device *s_dax_dev;
> +
> + /*
> +  * base physical and virtual address of NOVA 

Re: [PATCH 06/47] net: smsc: remove m32r specific smc91x configuration

[Finn Thain]

On Wed, 14 Mar 2018, Nicolas Pitre wrote:

> On Wed, 14 Mar 2018, Arnd Bergmann wrote:
> 
> > The m32r architecture is getting removed, so this part can be
> > cleaned up as well.
> > 
> > Signed-off-by: Arnd Bergmann 
> 
> Acked-by: Nicolas Pitre 
> 
> > ---
> >  drivers/net/ethernet/smsc/Kconfig  |  4 ++--
> >  drivers/net/ethernet/smsc/smc91x.h | 26 --
> >  2 files changed, 2 insertions(+), 28 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/smsc/Kconfig 
> > b/drivers/net/ethernet/smsc/Kconfig
> > index 4c2f612e4414..1c2b6663f7ce 100644
> > --- a/drivers/net/ethernet/smsc/Kconfig
> > +++ b/drivers/net/ethernet/smsc/Kconfig
> > @@ -37,8 +37,8 @@ config SMC91X
> > select CRC32
> > select MII
> > depends on !OF || GPIOLIB
> > -   depends on ARM || ARM64 || ATARI_ETHERNAT || BLACKFIN || COLDFIRE || \
> > -  M32R || MIPS || MN10300 || NIOS2 || SUPERH || XTENSA || H8300
> > +   depends on ARM || ARM64 || ATARI_ETHERNAT || COLDFIRE || \
> > +  MIPS || NIOS2 || SUPERH || XTENSA || H8300
> > ---help---
> >   This is a driver for SMC's 91x series of Ethernet chipsets,
> >   including the SMC91C94 and the SMC91C111. Say Y if you want it
> > diff --git a/drivers/net/ethernet/smsc/smc91x.h 
> > b/drivers/net/ethernet/smsc/smc91x.h
> > index 08b17adf0a65..b337ee97e0c0 100644
> > --- a/drivers/net/ethernet/smsc/smc91x.h
> > +++ b/drivers/net/ethernet/smsc/smc91x.h
> > @@ -144,32 +144,6 @@ static inline void _SMC_outw_align4(u16 val, void 
> > __iomem *ioaddr, int reg,
> >  
> >  #define SMC_IRQ_FLAGS  (0)
> >  
> > -#elif   defined(CONFIG_M32R)
> > -
> > -#define SMC_CAN_USE_8BIT   0
> > -#define SMC_CAN_USE_16BIT  1
> > -#define SMC_CAN_USE_32BIT  0
> > -
> > -#define SMC_inb(a, r)  inb(((u32)a) + (r))
> > -#define SMC_inw(a, r)  inw(((u32)a) + (r))
> > -#define SMC_outb(v, a, r)  outb(v, ((u32)a) + (r))
> > -#define SMC_outw(lp, v, a, r)  outw(v, ((u32)a) + (r))
> > -#define SMC_insw(a, r, p, l)   insw(((u32)a) + (r), p, l)
> > -#define SMC_outsw(a, r, p, l)  outsw(((u32)a) + (r), p, l)
> > -
> > -#define SMC_IRQ_FLAGS  (0)
> > -
> > -#define RPC_LSA_DEFAULTRPC_LED_TX_RX
> > -#define RPC_LSB_DEFAULTRPC_LED_100_10
> > -
> > -#elif defined(CONFIG_MN10300)

MN103 is a separate architecture, unrelated to M32R afaict...

-- 

> > -
> > -/*
> > - * MN10300/AM33 configuration
> > - */
> > -
> > -#include 
> > -
> >  #elif defined(CONFIG_ATARI)
> >  
> >  #define SMC_CAN_USE_8BIT1
> > -- 
> > 2.9.0
> > 
> > 
> 

Re: [PATCH 06/47] net: smsc: remove m32r specific smc91x configuration

[Finn Thain]

On Wed, 14 Mar 2018, Nicolas Pitre wrote:

> On Wed, 14 Mar 2018, Arnd Bergmann wrote:
> 
> > The m32r architecture is getting removed, so this part can be
> > cleaned up as well.
> > 
> > Signed-off-by: Arnd Bergmann 
> 
> Acked-by: Nicolas Pitre 
> 
> > ---
> >  drivers/net/ethernet/smsc/Kconfig  |  4 ++--
> >  drivers/net/ethernet/smsc/smc91x.h | 26 --
> >  2 files changed, 2 insertions(+), 28 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/smsc/Kconfig 
> > b/drivers/net/ethernet/smsc/Kconfig
> > index 4c2f612e4414..1c2b6663f7ce 100644
> > --- a/drivers/net/ethernet/smsc/Kconfig
> > +++ b/drivers/net/ethernet/smsc/Kconfig
> > @@ -37,8 +37,8 @@ config SMC91X
> > select CRC32
> > select MII
> > depends on !OF || GPIOLIB
> > -   depends on ARM || ARM64 || ATARI_ETHERNAT || BLACKFIN || COLDFIRE || \
> > -  M32R || MIPS || MN10300 || NIOS2 || SUPERH || XTENSA || H8300
> > +   depends on ARM || ARM64 || ATARI_ETHERNAT || COLDFIRE || \
> > +  MIPS || NIOS2 || SUPERH || XTENSA || H8300
> > ---help---
> >   This is a driver for SMC's 91x series of Ethernet chipsets,
> >   including the SMC91C94 and the SMC91C111. Say Y if you want it
> > diff --git a/drivers/net/ethernet/smsc/smc91x.h 
> > b/drivers/net/ethernet/smsc/smc91x.h
> > index 08b17adf0a65..b337ee97e0c0 100644
> > --- a/drivers/net/ethernet/smsc/smc91x.h
> > +++ b/drivers/net/ethernet/smsc/smc91x.h
> > @@ -144,32 +144,6 @@ static inline void _SMC_outw_align4(u16 val, void 
> > __iomem *ioaddr, int reg,
> >  
> >  #define SMC_IRQ_FLAGS  (0)
> >  
> > -#elif   defined(CONFIG_M32R)
> > -
> > -#define SMC_CAN_USE_8BIT   0
> > -#define SMC_CAN_USE_16BIT  1
> > -#define SMC_CAN_USE_32BIT  0
> > -
> > -#define SMC_inb(a, r)  inb(((u32)a) + (r))
> > -#define SMC_inw(a, r)  inw(((u32)a) + (r))
> > -#define SMC_outb(v, a, r)  outb(v, ((u32)a) + (r))
> > -#define SMC_outw(lp, v, a, r)  outw(v, ((u32)a) + (r))
> > -#define SMC_insw(a, r, p, l)   insw(((u32)a) + (r), p, l)
> > -#define SMC_outsw(a, r, p, l)  outsw(((u32)a) + (r), p, l)
> > -
> > -#define SMC_IRQ_FLAGS  (0)
> > -
> > -#define RPC_LSA_DEFAULTRPC_LED_TX_RX
> > -#define RPC_LSB_DEFAULTRPC_LED_100_10
> > -
> > -#elif defined(CONFIG_MN10300)

MN103 is a separate architecture, unrelated to M32R afaict...

-- 

> > -
> > -/*
> > - * MN10300/AM33 configuration
> > - */
> > -
> > -#include 
> > -
> >  #elif defined(CONFIG_ATARI)
> >  
> >  #define SMC_CAN_USE_8BIT1
> > -- 
> > 2.9.0
> > 
> > 
> 

Re: [PATCH v2] aic7xxx/aic79xx: remove VLAs

[Martin K. Petersen]

Stephen,

> In preparation to enabling -Wvla, remove VLAs and replace them with
> fixed-length arrays instead.
>
> The arrays fixed here, using the number of constant sections, aren't
> really VLAs, but they appear so to the compiler. Replace the array
> sizes with a pre-processor-level constant instead using ARRAY_SIZE.

Applied to 4.17/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2] aic7xxx/aic79xx: remove VLAs

[Martin K. Petersen]

Stephen,

> In preparation to enabling -Wvla, remove VLAs and replace them with
> fixed-length arrays instead.
>
> The arrays fixed here, using the number of constant sections, aren't
> really VLAs, but they appear so to the compiler. Replace the array
> sizes with a pre-processor-level constant instead using ARRAY_SIZE.

Applied to 4.17/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Intel GemniLake xHCI connected devices can never wake up the system from suspend

[Chris Chiu]

Hi,
I  have a ASUS AIO V222GA and another Acer Desktop XC-830 both
have Intel CPU J5005 and they both hit the same problem. The XHCI
connected USB keyboard/mouse can never wakeup the system from suspend.
It reminds me that similiar thing happens on ApolloLake too which
needs the XHCI_PME_STUCK_QUIRK to get it work. It's also mentioned in
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-celeron-n-series-spec-update.pdf
page #14 for N-seris intel CPU. And I also find the same problem
description in 
https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/silver-celeron-spec-update.pdf
page #16 for J-series Intel CPU. Seems that they have different
workaround so I can not simply apply XHCI_PME_STUCK_QUIRK to make it
work.

Anyone can help here?

Chris

Intel GemniLake xHCI connected devices can never wake up the system from suspend

[Chris Chiu]

Hi,
I  have a ASUS AIO V222GA and another Acer Desktop XC-830 both
have Intel CPU J5005 and they both hit the same problem. The XHCI
connected USB keyboard/mouse can never wakeup the system from suspend.
It reminds me that similiar thing happens on ApolloLake too which
needs the XHCI_PME_STUCK_QUIRK to get it work. It's also mentioned in
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-celeron-n-series-spec-update.pdf
page #14 for N-seris intel CPU. And I also find the same problem
description in 
https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/silver-celeron-spec-update.pdf
page #16 for J-series Intel CPU. Seems that they have different
workaround so I can not simply apply XHCI_PME_STUCK_QUIRK to make it
work.

Anyone can help here?

Chris

Re: [PATCH] bfa: remove VLA

[Martin K. Petersen]

Stephen,

> bfad_bsg.c uses a variable-length array declaration to measure the
> size of a putative array; this can be replaced by the product of the
> size of an element and the number of elements, avoiding the VLA
> altogether.
>
> - sizeof(wwn_t[iocmd->nports])) != BFA_STATUS_OK) {
> + sizeof(wwn_t) * iocmd->nports) != BFA_STATUS_OK) {

These parentheses made me blurry eyed but it's actually OK.

Applied to 4.17/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] bfa: remove VLA

[Martin K. Petersen]

Stephen,

> bfad_bsg.c uses a variable-length array declaration to measure the
> size of a putative array; this can be replaced by the product of the
> size of an element and the number of elements, avoiding the VLA
> altogether.
>
> - sizeof(wwn_t[iocmd->nports])) != BFA_STATUS_OK) {
> + sizeof(wwn_t) * iocmd->nports) != BFA_STATUS_OK) {

These parentheses made me blurry eyed but it's actually OK.

Applied to 4.17/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

[Dan Williams]

On Wed, Mar 14, 2018 at 12:34 PM, Stephen  Bates  wrote:
>> P2P over PCI/PCI-X is quite common in devices like raid controllers.
>
> Hi Dan
>
> Do you mean between PCIe devices below the RAID controller? Isn't it pretty 
> novel to be able to support PCIe EPs below a RAID controller (as opposed to 
> SCSI based devices)?

I'm thinking of the classic I/O offload card where there's an NTB to
an internal PCI bus that has a storage controller and raid offload
engines.

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

[Dan Williams]

On Wed, Mar 14, 2018 at 12:34 PM, Stephen  Bates  wrote:
>> P2P over PCI/PCI-X is quite common in devices like raid controllers.
>
> Hi Dan
>
> Do you mean between PCIe devices below the RAID controller? Isn't it pretty 
> novel to be able to support PCIe EPs below a RAID controller (as opposed to 
> SCSI based devices)?

I'm thinking of the classic I/O offload card where there's an NTB to
an internal PCI bus that has a storage controller and raid offload
engines.

Re: [PATCH v4 1/2] hwmon: (ucd9000) Add gpio chip interface

[Guenter Roeck]

On Wed, Mar 14, 2018 at 05:32:13PM -0500, Eddie James wrote:
> From: Christopher Bostic 
> 
> Add a struct gpio_chip and define some methods so that this device's
> I/O can be accessed via /sys/class/gpio.
> 
> Signed-off-by: Christopher Bostic 
> Signed-off-by: Andrew Jeffery 
> Signed-off-by: Eddie James 

This patch looks good to me. Any further comments ? Otherwise I'll
go ahead and apply to hwmon-next.

Thanks,
Guenter

> ---
>  drivers/hwmon/pmbus/ucd9000.c | 201 
> ++
>  1 file changed, 201 insertions(+)
> 
> diff --git a/drivers/hwmon/pmbus/ucd9000.c b/drivers/hwmon/pmbus/ucd9000.c
> index b74dbec..a34ffc4 100644
> --- a/drivers/hwmon/pmbus/ucd9000.c
> +++ b/drivers/hwmon/pmbus/ucd9000.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "pmbus.h"
>  
>  enum chips { ucd9000, ucd90120, ucd90124, ucd90160, ucd9090, ucd90910 };
> @@ -35,8 +36,18 @@
>  #define UCD9000_NUM_PAGES0xd6
>  #define UCD9000_FAN_CONFIG_INDEX 0xe7
>  #define UCD9000_FAN_CONFIG   0xe8
> +#define UCD9000_GPIO_SELECT  0xfa
> +#define UCD9000_GPIO_CONFIG  0xfb
>  #define UCD9000_DEVICE_ID0xfd
>  
> +/* GPIO CONFIG bits */
> +#define UCD9000_GPIO_CONFIG_ENABLE   BIT(0)
> +#define UCD9000_GPIO_CONFIG_OUT_ENABLE   BIT(1)
> +#define UCD9000_GPIO_CONFIG_OUT_VALUEBIT(2)
> +#define UCD9000_GPIO_CONFIG_STATUS   BIT(3)
> +#define UCD9000_GPIO_INPUT   0
> +#define UCD9000_GPIO_OUTPUT  1
> +
>  #define UCD9000_MON_TYPE(x)  (((x) >> 5) & 0x07)
>  #define UCD9000_MON_PAGE(x)  ((x) & 0x0f)
>  
> @@ -47,9 +58,15 @@
>  
>  #define UCD9000_NUM_FAN  4
>  
> +#define UCD9000_GPIO_NAME_LEN16
> +#define UCD9090_NUM_GPIOS23
> +#define UCD901XX_NUM_GPIOS   26
> +#define UCD90910_NUM_GPIOS   26
> +
>  struct ucd9000_data {
>   u8 fan_data[UCD9000_NUM_FAN][I2C_SMBUS_BLOCK_MAX];
>   struct pmbus_driver_info info;
> + struct gpio_chip gpio;
>  };
>  #define to_ucd9000_data(_info) container_of(_info, struct ucd9000_data, info)
>  
> @@ -149,6 +166,188 @@ static int ucd9000_read_byte_data(struct i2c_client 
> *client, int page, int reg)
>  };
>  MODULE_DEVICE_TABLE(of, ucd9000_of_match);
>  
> +static int ucd9000_gpio_read_config(struct i2c_client *client,
> + unsigned int offset)
> +{
> + int ret;
> +
> + /* No page set required */
> + ret = i2c_smbus_write_byte_data(client, UCD9000_GPIO_SELECT, offset);
> + if (ret < 0)
> + return ret;
> +
> + return i2c_smbus_read_byte_data(client, UCD9000_GPIO_CONFIG);
> +}
> +
> +static int ucd9000_gpio_get(struct gpio_chip *gc, unsigned int offset)
> +{
> + struct i2c_client *client  = gpiochip_get_data(gc);
> + int ret;
> +
> + ret = ucd9000_gpio_read_config(client, offset);
> + if (ret < 0)
> + return ret;
> +
> + return !!(ret & UCD9000_GPIO_CONFIG_STATUS);
> +}
> +
> +static void ucd9000_gpio_set(struct gpio_chip *gc, unsigned int offset,
> +  int value)
> +{
> + struct i2c_client *client = gpiochip_get_data(gc);
> + int ret;
> +
> + ret = ucd9000_gpio_read_config(client, offset);
> + if (ret < 0) {
> + dev_dbg(>dev, "failed to read GPIO %d config: %d\n",
> + offset, ret);
> + return;
> + }
> +
> + if (value) {
> + if (ret & UCD9000_GPIO_CONFIG_STATUS)
> + return;
> +
> + ret |= UCD9000_GPIO_CONFIG_STATUS;
> + } else {
> + if (!(ret & UCD9000_GPIO_CONFIG_STATUS))
> + return;
> +
> + ret &= ~UCD9000_GPIO_CONFIG_STATUS;
> + }
> +
> + ret |= UCD9000_GPIO_CONFIG_ENABLE;
> +
> + /* Page set not required */
> + ret = i2c_smbus_write_byte_data(client, UCD9000_GPIO_CONFIG, ret);
> + if (ret < 0) {
> + dev_dbg(>dev, "Failed to write GPIO %d config: %d\n",
> + offset, ret);
> + return;
> + }
> +
> + ret &= ~UCD9000_GPIO_CONFIG_ENABLE;
> +
> + ret = i2c_smbus_write_byte_data(client, UCD9000_GPIO_CONFIG, ret);
> + if (ret < 0)
> + dev_dbg(>dev, "Failed to write GPIO %d config: %d\n",
> + offset, ret);
> +}
> +
> +static int ucd9000_gpio_get_direction(struct gpio_chip *gc,
> +   unsigned int offset)
> +{
> + struct i2c_client *client = gpiochip_get_data(gc);
> + int ret;
> +
> + ret = ucd9000_gpio_read_config(client, offset);
> + if (ret < 0)
> + return ret;
> +
> + return !(ret & UCD9000_GPIO_CONFIG_OUT_ENABLE);
> +}
> +
> +static int ucd9000_gpio_set_direction(struct gpio_chip *gc,
> +   unsigned int offset, bool direction_out,
> + 

Re: [PATCH v4 1/2] hwmon: (ucd9000) Add gpio chip interface

[Guenter Roeck]

On Wed, Mar 14, 2018 at 05:32:13PM -0500, Eddie James wrote:
> From: Christopher Bostic 
> 
> Add a struct gpio_chip and define some methods so that this device's
> I/O can be accessed via /sys/class/gpio.
> 
> Signed-off-by: Christopher Bostic 
> Signed-off-by: Andrew Jeffery 
> Signed-off-by: Eddie James 

This patch looks good to me. Any further comments ? Otherwise I'll
go ahead and apply to hwmon-next.

Thanks,
Guenter

> ---
>  drivers/hwmon/pmbus/ucd9000.c | 201 
> ++
>  1 file changed, 201 insertions(+)
> 
> diff --git a/drivers/hwmon/pmbus/ucd9000.c b/drivers/hwmon/pmbus/ucd9000.c
> index b74dbec..a34ffc4 100644
> --- a/drivers/hwmon/pmbus/ucd9000.c
> +++ b/drivers/hwmon/pmbus/ucd9000.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "pmbus.h"
>  
>  enum chips { ucd9000, ucd90120, ucd90124, ucd90160, ucd9090, ucd90910 };
> @@ -35,8 +36,18 @@
>  #define UCD9000_NUM_PAGES0xd6
>  #define UCD9000_FAN_CONFIG_INDEX 0xe7
>  #define UCD9000_FAN_CONFIG   0xe8
> +#define UCD9000_GPIO_SELECT  0xfa
> +#define UCD9000_GPIO_CONFIG  0xfb
>  #define UCD9000_DEVICE_ID0xfd
>  
> +/* GPIO CONFIG bits */
> +#define UCD9000_GPIO_CONFIG_ENABLE   BIT(0)
> +#define UCD9000_GPIO_CONFIG_OUT_ENABLE   BIT(1)
> +#define UCD9000_GPIO_CONFIG_OUT_VALUEBIT(2)
> +#define UCD9000_GPIO_CONFIG_STATUS   BIT(3)
> +#define UCD9000_GPIO_INPUT   0
> +#define UCD9000_GPIO_OUTPUT  1
> +
>  #define UCD9000_MON_TYPE(x)  (((x) >> 5) & 0x07)
>  #define UCD9000_MON_PAGE(x)  ((x) & 0x0f)
>  
> @@ -47,9 +58,15 @@
>  
>  #define UCD9000_NUM_FAN  4
>  
> +#define UCD9000_GPIO_NAME_LEN16
> +#define UCD9090_NUM_GPIOS23
> +#define UCD901XX_NUM_GPIOS   26
> +#define UCD90910_NUM_GPIOS   26
> +
>  struct ucd9000_data {
>   u8 fan_data[UCD9000_NUM_FAN][I2C_SMBUS_BLOCK_MAX];
>   struct pmbus_driver_info info;
> + struct gpio_chip gpio;
>  };
>  #define to_ucd9000_data(_info) container_of(_info, struct ucd9000_data, info)
>  
> @@ -149,6 +166,188 @@ static int ucd9000_read_byte_data(struct i2c_client 
> *client, int page, int reg)
>  };
>  MODULE_DEVICE_TABLE(of, ucd9000_of_match);
>  
> +static int ucd9000_gpio_read_config(struct i2c_client *client,
> + unsigned int offset)
> +{
> + int ret;
> +
> + /* No page set required */
> + ret = i2c_smbus_write_byte_data(client, UCD9000_GPIO_SELECT, offset);
> + if (ret < 0)
> + return ret;
> +
> + return i2c_smbus_read_byte_data(client, UCD9000_GPIO_CONFIG);
> +}
> +
> +static int ucd9000_gpio_get(struct gpio_chip *gc, unsigned int offset)
> +{
> + struct i2c_client *client  = gpiochip_get_data(gc);
> + int ret;
> +
> + ret = ucd9000_gpio_read_config(client, offset);
> + if (ret < 0)
> + return ret;
> +
> + return !!(ret & UCD9000_GPIO_CONFIG_STATUS);
> +}
> +
> +static void ucd9000_gpio_set(struct gpio_chip *gc, unsigned int offset,
> +  int value)
> +{
> + struct i2c_client *client = gpiochip_get_data(gc);
> + int ret;
> +
> + ret = ucd9000_gpio_read_config(client, offset);
> + if (ret < 0) {
> + dev_dbg(>dev, "failed to read GPIO %d config: %d\n",
> + offset, ret);
> + return;
> + }
> +
> + if (value) {
> + if (ret & UCD9000_GPIO_CONFIG_STATUS)
> + return;
> +
> + ret |= UCD9000_GPIO_CONFIG_STATUS;
> + } else {
> + if (!(ret & UCD9000_GPIO_CONFIG_STATUS))
> + return;
> +
> + ret &= ~UCD9000_GPIO_CONFIG_STATUS;
> + }
> +
> + ret |= UCD9000_GPIO_CONFIG_ENABLE;
> +
> + /* Page set not required */
> + ret = i2c_smbus_write_byte_data(client, UCD9000_GPIO_CONFIG, ret);
> + if (ret < 0) {
> + dev_dbg(>dev, "Failed to write GPIO %d config: %d\n",
> + offset, ret);
> + return;
> + }
> +
> + ret &= ~UCD9000_GPIO_CONFIG_ENABLE;
> +
> + ret = i2c_smbus_write_byte_data(client, UCD9000_GPIO_CONFIG, ret);
> + if (ret < 0)
> + dev_dbg(>dev, "Failed to write GPIO %d config: %d\n",
> + offset, ret);
> +}
> +
> +static int ucd9000_gpio_get_direction(struct gpio_chip *gc,
> +   unsigned int offset)
> +{
> + struct i2c_client *client = gpiochip_get_data(gc);
> + int ret;
> +
> + ret = ucd9000_gpio_read_config(client, offset);
> + if (ret < 0)
> + return ret;
> +
> + return !(ret & UCD9000_GPIO_CONFIG_OUT_ENABLE);
> +}
> +
> +static int ucd9000_gpio_set_direction(struct gpio_chip *gc,
> +   unsigned int offset, bool direction_out,
> +   int requested_out)
> +{
> + struct i2c_client *client = gpiochip_get_data(gc);
> + int 

Re: [PATCH v4 2/2] hwmon: (ucd9000) Add debugfs attributes to provide mfr_status

[Guenter Roeck]

On Wed, Mar 14, 2018 at 05:32:14PM -0500, Eddie James wrote:
> From: Christopher Bostic 
> 
> Expose the gpiN_fault fields of mfr_status as individual debugfs
> attributes. This provides a way for users to be easily notified of gpi
> faults. Also provide the whole mfr_status register in debugfs.
> 
> Signed-off-by: Christopher Bostic 
> Signed-off-by: Andrew Jeffery 
> Signed-off-by: Eddie James 
> ---
>  drivers/hwmon/pmbus/ucd9000.c | 153 
> +-
>  1 file changed, 152 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/pmbus/ucd9000.c b/drivers/hwmon/pmbus/ucd9000.c
> index a34ffc4..f03c404 100644
> --- a/drivers/hwmon/pmbus/ucd9000.c
> +++ b/drivers/hwmon/pmbus/ucd9000.c
> @@ -19,6 +19,7 @@
>   * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -36,6 +37,7 @@
>  #define UCD9000_NUM_PAGES0xd6
>  #define UCD9000_FAN_CONFIG_INDEX 0xe7
>  #define UCD9000_FAN_CONFIG   0xe8
> +#define UCD9000_MFR_STATUS   0xf3
>  #define UCD9000_GPIO_SELECT  0xfa
>  #define UCD9000_GPIO_CONFIG  0xfb
>  #define UCD9000_DEVICE_ID0xfd
> @@ -63,13 +65,22 @@
>  #define UCD901XX_NUM_GPIOS   26
>  #define UCD90910_NUM_GPIOS   26
>  
> +#define UCD9000_DEBUGFS_NAME_LEN 24
> +#define UCD9000_GPI_COUNT8
> +
>  struct ucd9000_data {
>   u8 fan_data[UCD9000_NUM_FAN][I2C_SMBUS_BLOCK_MAX];
>   struct pmbus_driver_info info;
>   struct gpio_chip gpio;
> + struct dentry *debugfs;
>  };
>  #define to_ucd9000_data(_info) container_of(_info, struct ucd9000_data, info)
>  
> +struct ucd9000_debugfs_entry {
> + struct i2c_client *client;
> + u8 index;
> +};
> +
>  static int ucd9000_get_fan_config(struct i2c_client *client, int fan)
>  {
>   int fan_config = 0;
> @@ -306,6 +317,137 @@ static int ucd9000_gpio_direction_output(struct 
> gpio_chip *gc,
> val);
>  }
>  
> +#ifdef CONFIG_DEBUG_FS
> +static int ucd9000_get_mfr_status(struct i2c_client *client, u8 *buffer)
> +{
> + int ret = pmbus_set_page(client, 0);
> +
> + if (ret < 0)
> + return ret;
> +
> + /*
> +  * With the ucd90120 and ucd90124 devices, this command [MFR_STATUS]
> +  * is 2 bytes long (bits 0-15).  With the ucd90240 this command is 5
> +  * bytes long.  With all other devices, it is 4 bytes long.
> +  */

I am really uneasy about the limited buffer sizes.

The limited transfer size isn't guaranteed by the protocol. You are making 
assumptions about chip operation which adds risk. It would be much safer if
you would just use the maximum smbus block transfer size for all buffers.
It is not as if the few extra bytes on the stack would hurt, or am I missing
something ? As a bonus, all the comments about the transfers presumably being
safe would no longer be needed.

> + return i2c_smbus_read_block_data(client, UCD9000_MFR_STATUS, buffer);
> +}
> +
> +static int ucd9000_debugfs_show_mfr_status_bit(void *data, u64 *val)
> +{
> + struct ucd9000_debugfs_entry *entry = data;
> + struct i2c_client *client = entry->client;
> + u8 buffer[4];
> + int ret;
> +
> + /*
> +  * This attribute is only created for devices that return 4 bytes for
> +  * status_mfr, so it's safe to call with 4-byte buffer.
> +  */
> + ret = ucd9000_get_mfr_status(client, buffer);
> + if (ret < 0)
> + return ret;
> +
> + /*
> +  * Attribute only created for devices with gpi fault bits at bits
> +  * 16-23, which is the second byte of the response.
> +  */
> + *val = !!(buffer[1] & BIT(entry->index));
> +
> + return 0;
> +}
> +DEFINE_DEBUGFS_ATTRIBUTE(ucd9000_debugfs_mfr_status_bit,
> +  ucd9000_debugfs_show_mfr_status_bit, NULL, "%1lld\n");
> +
> +static ssize_t ucd9000_debugfs_read_mfr_status(struct file *file,
> +char __user *buf, size_t count,
> +loff_t *ppos)
> +{
> + struct i2c_client *client = file->private_data;
> + u8 buffer[5] = { 0 };   /* Need max 5 bytes for any ucd9000 chip. */
> + char str[12] = { 0 };   /* Two chars per byte plus \n and \0. */
> + int i, num_bytes, num_chars = 0, rc;
> +
> + num_bytes = ucd9000_get_mfr_status(client, buffer);
> + if (num_bytes < 0)
> + return num_bytes;
> +
> + for (i = 0; i < num_bytes; ++i) {
> + rc = snprintf([num_chars], (sizeof(str) - 1) - num_chars,
> +   "%02x", buffer[i]);
> + if (rc <= 0)
> + break;
> +
> + num_chars += rc;
> + }
> +
> + str[num_chars] = '\n';

Sorry for being annoying, but have you considered using hex_dump_to_buffer() ?

Thanks,

Re: [PATCH v4 2/2] hwmon: (ucd9000) Add debugfs attributes to provide mfr_status

[Guenter Roeck]

On Wed, Mar 14, 2018 at 05:32:14PM -0500, Eddie James wrote:
> From: Christopher Bostic 
> 
> Expose the gpiN_fault fields of mfr_status as individual debugfs
> attributes. This provides a way for users to be easily notified of gpi
> faults. Also provide the whole mfr_status register in debugfs.
> 
> Signed-off-by: Christopher Bostic 
> Signed-off-by: Andrew Jeffery 
> Signed-off-by: Eddie James 
> ---
>  drivers/hwmon/pmbus/ucd9000.c | 153 
> +-
>  1 file changed, 152 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/pmbus/ucd9000.c b/drivers/hwmon/pmbus/ucd9000.c
> index a34ffc4..f03c404 100644
> --- a/drivers/hwmon/pmbus/ucd9000.c
> +++ b/drivers/hwmon/pmbus/ucd9000.c
> @@ -19,6 +19,7 @@
>   * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -36,6 +37,7 @@
>  #define UCD9000_NUM_PAGES0xd6
>  #define UCD9000_FAN_CONFIG_INDEX 0xe7
>  #define UCD9000_FAN_CONFIG   0xe8
> +#define UCD9000_MFR_STATUS   0xf3
>  #define UCD9000_GPIO_SELECT  0xfa
>  #define UCD9000_GPIO_CONFIG  0xfb
>  #define UCD9000_DEVICE_ID0xfd
> @@ -63,13 +65,22 @@
>  #define UCD901XX_NUM_GPIOS   26
>  #define UCD90910_NUM_GPIOS   26
>  
> +#define UCD9000_DEBUGFS_NAME_LEN 24
> +#define UCD9000_GPI_COUNT8
> +
>  struct ucd9000_data {
>   u8 fan_data[UCD9000_NUM_FAN][I2C_SMBUS_BLOCK_MAX];
>   struct pmbus_driver_info info;
>   struct gpio_chip gpio;
> + struct dentry *debugfs;
>  };
>  #define to_ucd9000_data(_info) container_of(_info, struct ucd9000_data, info)
>  
> +struct ucd9000_debugfs_entry {
> + struct i2c_client *client;
> + u8 index;
> +};
> +
>  static int ucd9000_get_fan_config(struct i2c_client *client, int fan)
>  {
>   int fan_config = 0;
> @@ -306,6 +317,137 @@ static int ucd9000_gpio_direction_output(struct 
> gpio_chip *gc,
> val);
>  }
>  
> +#ifdef CONFIG_DEBUG_FS
> +static int ucd9000_get_mfr_status(struct i2c_client *client, u8 *buffer)
> +{
> + int ret = pmbus_set_page(client, 0);
> +
> + if (ret < 0)
> + return ret;
> +
> + /*
> +  * With the ucd90120 and ucd90124 devices, this command [MFR_STATUS]
> +  * is 2 bytes long (bits 0-15).  With the ucd90240 this command is 5
> +  * bytes long.  With all other devices, it is 4 bytes long.
> +  */

I am really uneasy about the limited buffer sizes.

The limited transfer size isn't guaranteed by the protocol. You are making 
assumptions about chip operation which adds risk. It would be much safer if
you would just use the maximum smbus block transfer size for all buffers.
It is not as if the few extra bytes on the stack would hurt, or am I missing
something ? As a bonus, all the comments about the transfers presumably being
safe would no longer be needed.

> + return i2c_smbus_read_block_data(client, UCD9000_MFR_STATUS, buffer);
> +}
> +
> +static int ucd9000_debugfs_show_mfr_status_bit(void *data, u64 *val)
> +{
> + struct ucd9000_debugfs_entry *entry = data;
> + struct i2c_client *client = entry->client;
> + u8 buffer[4];
> + int ret;
> +
> + /*
> +  * This attribute is only created for devices that return 4 bytes for
> +  * status_mfr, so it's safe to call with 4-byte buffer.
> +  */
> + ret = ucd9000_get_mfr_status(client, buffer);
> + if (ret < 0)
> + return ret;
> +
> + /*
> +  * Attribute only created for devices with gpi fault bits at bits
> +  * 16-23, which is the second byte of the response.
> +  */
> + *val = !!(buffer[1] & BIT(entry->index));
> +
> + return 0;
> +}
> +DEFINE_DEBUGFS_ATTRIBUTE(ucd9000_debugfs_mfr_status_bit,
> +  ucd9000_debugfs_show_mfr_status_bit, NULL, "%1lld\n");
> +
> +static ssize_t ucd9000_debugfs_read_mfr_status(struct file *file,
> +char __user *buf, size_t count,
> +loff_t *ppos)
> +{
> + struct i2c_client *client = file->private_data;
> + u8 buffer[5] = { 0 };   /* Need max 5 bytes for any ucd9000 chip. */
> + char str[12] = { 0 };   /* Two chars per byte plus \n and \0. */
> + int i, num_bytes, num_chars = 0, rc;
> +
> + num_bytes = ucd9000_get_mfr_status(client, buffer);
> + if (num_bytes < 0)
> + return num_bytes;
> +
> + for (i = 0; i < num_bytes; ++i) {
> + rc = snprintf([num_chars], (sizeof(str) - 1) - num_chars,
> +   "%02x", buffer[i]);
> + if (rc <= 0)
> + break;
> +
> + num_chars += rc;
> + }
> +
> + str[num_chars] = '\n';

Sorry for being annoying, but have you considered using hex_dump_to_buffer() ?

Thanks,
Guenter

> +
> + return simple_read_from_buffer(buf, count, ppos, str, num_chars + 2);
> +}
> +
> 

Re: [PATCH] certs/blacklist: fix const confusion

[Nick Desaulniers]

bumping for review

On Sat, Mar 3, 2018 at 10:50 PM, Nick Desaulniers
 wrote:
> Fixes commit 2be04df5668d ("certs/blacklist_nohashes.c: fix const confusion
> in certs blacklist")
>
> Signed-off-by: Nick Desaulniers 
> ---
>  certs/blacklist.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/certs/blacklist.h b/certs/blacklist.h
> index 150d82da8e99..1efd6fa0dc60 100644
> --- a/certs/blacklist.h
> +++ b/certs/blacklist.h
> @@ -1,3 +1,3 @@
>  #include 
>
> -extern const char __initdata *const blacklist_hashes[];
> +extern const char __initconst *const blacklist_hashes[];
> --
> 2.14.1
>

Re: [PATCH] certs/blacklist: fix const confusion

[Nick Desaulniers]

bumping for review

On Sat, Mar 3, 2018 at 10:50 PM, Nick Desaulniers
 wrote:
> Fixes commit 2be04df5668d ("certs/blacklist_nohashes.c: fix const confusion
> in certs blacklist")
>
> Signed-off-by: Nick Desaulniers 
> ---
>  certs/blacklist.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/certs/blacklist.h b/certs/blacklist.h
> index 150d82da8e99..1efd6fa0dc60 100644
> --- a/certs/blacklist.h
> +++ b/certs/blacklist.h
> @@ -1,3 +1,3 @@
>  #include 
>
> -extern const char __initdata *const blacklist_hashes[];
> +extern const char __initconst *const blacklist_hashes[];
> --
> 2.14.1
>

Re: [PATCH] scsi: iscsi_tcp: set BDI_CAP_STABLE_WRITES when data digest enabled

[Martin K. Petersen]

> iscsi tcp will first send out data, then calculate and send data
> digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will
> be written in spite of the on going writeback. Consequently, wrong
> digest will be got and sent to target.
>
> To fix this, set BDI_CAP_STABLE_WRITES when data digest is enabled
> in iscsi_tcp .slave_configure callback.

Lee, Chris: Please review!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: iscsi_tcp: set BDI_CAP_STABLE_WRITES when data digest enabled

[Martin K. Petersen]

> iscsi tcp will first send out data, then calculate and send data
> digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will
> be written in spite of the on going writeback. Consequently, wrong
> digest will be got and sent to target.
>
> To fix this, set BDI_CAP_STABLE_WRITES when data digest is enabled
> in iscsi_tcp .slave_configure callback.

Lee, Chris: Please review!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: scsi_transport_iscsi: use put_device() instead of kfree()

[Martin K. Petersen]

> Never directly free @dev after calling device_register(), even
> if it returned an error! Always use put_device() to give up the
> reference initialized.

Lee, Chris: Please review!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: scsi_transport_iscsi: use put_device() instead of kfree()

[Martin K. Petersen]

> Never directly free @dev after calling device_register(), even
> if it returned an error! Always use put_device() to give up the
> reference initialized.

Lee, Chris: Please review!

-- 
Martin K. Petersen  Oracle Linux Engineering

drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of 'stb0899_attach' being applied to a already existing, static definition

[kbuild test robot]

Hi Wolfgang,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0aa3fdb8b3a6df3c2e3b61dbfe079db9d30e03cd
commit: 6cdeaed3b1420bd2569891be0c4123ff59628e9e media: dvb_usb_pctv452e: 
module refcount changes were unbalanced
date:   3 months ago
config: x86_64-randconfig-a0-03151117 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 6cdeaed3b1420bd2569891be0c4123ff59628e9e
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from drivers/media/usb/dvb-usb/pctv452e.c:20:0:
   drivers/media/usb/dvb-usb/pctv452e.c: In function 'pctv452e_frontend_attach':
>> drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of 
>> 'stb0899_attach' being applied to a already existing, static definition
static inline struct dvb_frontend *stb0899_attach(struct stb0899_config 
*config,
   ^~

vim +/stb0899_attach +151 drivers/media/dvb-frontends/stb0899_drv.h

ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  150 
 
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08 @151 
 static inline struct dvb_frontend *stb0899_attach(struct stb0899_config 
*config,
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  152 
  struct i2c_adapter *i2c)
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  153 
 {
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  154 
printk(KERN_WARNING "%s: Driver disabled by Kconfig\n", __func__);
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  155 
return NULL;
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  156 
 }
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  157 
 

:: The code at line 151 was first introduced by commit
:: ae9902da96b4d2d82707706c7fbc93a8e501dde8 V4L/DVB (9417): DVB_ATTACH for 
STB0899, STB6100, TDA8261

:: TO: Manu Abraham 
:: CC: Mauro Carvalho Chehab 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of 'stb0899_attach' being applied to a already existing, static definition

[kbuild test robot]

Hi Wolfgang,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0aa3fdb8b3a6df3c2e3b61dbfe079db9d30e03cd
commit: 6cdeaed3b1420bd2569891be0c4123ff59628e9e media: dvb_usb_pctv452e: 
module refcount changes were unbalanced
date:   3 months ago
config: x86_64-randconfig-a0-03151117 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 6cdeaed3b1420bd2569891be0c4123ff59628e9e
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from drivers/media/usb/dvb-usb/pctv452e.c:20:0:
   drivers/media/usb/dvb-usb/pctv452e.c: In function 'pctv452e_frontend_attach':
>> drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of 
>> 'stb0899_attach' being applied to a already existing, static definition
static inline struct dvb_frontend *stb0899_attach(struct stb0899_config 
*config,
   ^~

vim +/stb0899_attach +151 drivers/media/dvb-frontends/stb0899_drv.h

ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  150 
 
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08 @151 
 static inline struct dvb_frontend *stb0899_attach(struct stb0899_config 
*config,
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  152 
  struct i2c_adapter *i2c)
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  153 
 {
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  154 
printk(KERN_WARNING "%s: Driver disabled by Kconfig\n", __func__);
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  155 
return NULL;
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  156 
 }
ae9902da drivers/media/dvb/frontends/stb0899_drv.h Manu Abraham 2007-10-08  157 
 

:: The code at line 151 was first introduced by commit
:: ae9902da96b4d2d82707706c7fbc93a8e501dde8 V4L/DVB (9417): DVB_ATTACH for 
STB0899, STB6100, TDA8261

:: TO: Manu Abraham 
:: CC: Mauro Carvalho Chehab 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/2] x86/microcode: Fix CPU synchronization routine

[Henrique de Moraes Holschuh]

On Thu, 15 Mar 2018, Borislav Petkov wrote:
> On Wed, Mar 14, 2018 at 10:00:14PM -0300, Henrique de Moraes Holschuh wrote:
> > Intel takes anything from twenty thousand cycles to several *million*
> > cycles per core, proportional to microcode update size.
> 
> Got any hard data to back that claim up?

A reasonably well-known paper on intel microcode updates[1] profiled
that very well, years ago (2013).  The information about a linear
increase in update time versus update size comes from that paper (I did
not attempt to reproduce his findings, though).

When I measured my Xeon X5550 workstation doing an early update, the
Xeon took about 1M cycles for the BSP, and 800k cycles for the APs (see
below).

To measure that, as far as I recall I just did a rdtsc right before the
wrmsr, and another right after, and stashed the result somewhere to be
able to print it out later in the BSP's case.  I repeated the process
(by rebooting) a few times.  There was a *lot* of variation, but not
enough to get it wrong by an order of magnitude.

I am surprised that this would be news to you, though.  It is not like I
have been quiet about how expensive these updates are on Intel over the
past years every time I sent you a patch related to this...

Anyway, here's my measurement data from 2013:

Xeon X5550:
microcode_early: CPU0: entire core updated early to revision 0x19, in 1016168 
cycles
microcode_early: CPU1: entire core updated early to revision 0x19, in 842264 
cycles
microcode_early: CPU2: entire core updated early to revision 0x19, in 846784 
cycles
microcode_early: CPU3: entire core updated early to revision 0x19, in 838196 
cycles


[1] HAWKES, Ben. "Notes on Intel Microcode Updates", March 2013.

-- 
  Henrique Holschuh

Re: [PATCH 2/2] x86/microcode: Fix CPU synchronization routine

[Henrique de Moraes Holschuh]

On Thu, 15 Mar 2018, Borislav Petkov wrote:
> On Wed, Mar 14, 2018 at 10:00:14PM -0300, Henrique de Moraes Holschuh wrote:
> > Intel takes anything from twenty thousand cycles to several *million*
> > cycles per core, proportional to microcode update size.
> 
> Got any hard data to back that claim up?

A reasonably well-known paper on intel microcode updates[1] profiled
that very well, years ago (2013).  The information about a linear
increase in update time versus update size comes from that paper (I did
not attempt to reproduce his findings, though).

When I measured my Xeon X5550 workstation doing an early update, the
Xeon took about 1M cycles for the BSP, and 800k cycles for the APs (see
below).

To measure that, as far as I recall I just did a rdtsc right before the
wrmsr, and another right after, and stashed the result somewhere to be
able to print it out later in the BSP's case.  I repeated the process
(by rebooting) a few times.  There was a *lot* of variation, but not
enough to get it wrong by an order of magnitude.

I am surprised that this would be news to you, though.  It is not like I
have been quiet about how expensive these updates are on Intel over the
past years every time I sent you a patch related to this...

Anyway, here's my measurement data from 2013:

Xeon X5550:
microcode_early: CPU0: entire core updated early to revision 0x19, in 1016168 
cycles
microcode_early: CPU1: entire core updated early to revision 0x19, in 842264 
cycles
microcode_early: CPU2: entire core updated early to revision 0x19, in 846784 
cycles
microcode_early: CPU3: entire core updated early to revision 0x19, in 838196 
cycles


[1] HAWKES, Ben. "Notes on Intel Microcode Updates", March 2013.

-- 
  Henrique Holschuh

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

[Martin K. Petersen]

Stephen,

>> It would be useful if those configurations were not left behind so
>> that Linux could feasibly deploy offload code to a controller in the
>> PCI domain.
>
> Agreed. I think this would be great. Kind of like the XCOPY framework
> that was proposed a while back for SCSI devices [1] but updated to also
> include NVMe devices. That is definitely a use case we would like this
> framework to support.

I'm on my umpteenth rewrite of the block/SCSI offload code. It is not as
protocol-agnostic as I would like in the block layer facing downwards.
It has proven quite hard to reconcile token-based and EXTENDED COPY
semantics along with the desire to support stacking. But from an
application/filesystem perspective everything looks the same regardless
of the intricacies of the device. Nothing is preventing us from
supporting other protocols...

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

[Martin K. Petersen]

Stephen,

>> It would be useful if those configurations were not left behind so
>> that Linux could feasibly deploy offload code to a controller in the
>> PCI domain.
>
> Agreed. I think this would be great. Kind of like the XCOPY framework
> that was proposed a while back for SCSI devices [1] but updated to also
> include NVMe devices. That is definitely a use case we would like this
> framework to support.

I'm on my umpteenth rewrite of the block/SCSI offload code. It is not as
protocol-agnostic as I would like in the block layer facing downwards.
It has proven quite hard to reconcile token-based and EXTENDED COPY
semantics along with the desire to support stacking. But from an
application/filesystem perspective everything looks the same regardless
of the intricacies of the device. Nothing is preventing us from
supporting other protocols...

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH][next] scsi: lpfc: make several unions static, fix non-ANSI prototype

[Martin K. Petersen]

Colin,

> There are several unions that are local to the source and do not need
> to be in global scope, so make them static. Also add in a missing void
> parameter to functions lpfc_nvme_cmd_template and
> lpfc_nvmet_cmd_template to clean up non-ANSI warning.

Applied to 4.17/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH][next] scsi: lpfc: make several unions static, fix non-ANSI prototype

[Martin K. Petersen]

Colin,

> There are several unions that are local to the source and do not need
> to be in global scope, so make them static. Also add in a missing void
> parameter to functions lpfc_nvme_cmd_template and
> lpfc_nvmet_cmd_template to clean up non-ANSI warning.

Applied to 4.17/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

linux-next: manual merge of the drm-misc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  sound/pci/hda/hda_intel.c

between commits:

  1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist")
  40088dc4e1ea ("ALSA: hda - Revert power_save option default value")

from Linus' tree and commit:

  07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc sound/pci/hda/hda_intel.c
index d5017adf9feb,ec4e6b829ee2..
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@@ -2219,8 -2201,8 +2223,9 @@@ static int azx_probe_continue(struct az
struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
struct hdac_bus *bus = azx_bus(chip);
struct pci_dev *pci = chip->pci;
+   struct hda_codec *codec;
int dev = chip->dev_index;
 +  int val;
int err;
  
hda->probe_continued = 1;
@@@ -2302,21 -2284,16 +2307,30 @@@
chip->running = 1;
azx_add_card_list(chip);
  
 +  val = power_save;
 +#ifdef CONFIG_PM
 +  if (pm_blacklist) {
 +  const struct snd_pci_quirk *q;
 +
 +  q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
 +  if (q && val) {
 +  dev_info(chip->card->dev, "device %04x:%04x is on the 
power_save blacklist, forcing power_save to 0\n",
 +   q->subvendor, q->subdevice);
 +  val = 0;
 +  }
 +  }
 +#endif /* CONFIG_PM */
++
+   /*
+* The discrete GPU cannot power down unless the HDA controller runtime
+* suspends, so activate runtime PM on codecs even if power_save == 0.
+*/
+   if (use_vga_switcheroo(hda))
+   list_for_each_codec(codec, >bus)
+   codec->auto_runtime_pm = 1;
+ 
 -  snd_hda_set_power_save(>bus, power_save * 1000);
 +  snd_hda_set_power_save(>bus, val * 1000);
-   if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo)
+   if (azx_has_pm_runtime(chip))
pm_runtime_put_autosuspend(>dev);
  
  out_free:


pgp0IJPk8Eunq.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the drm-misc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  sound/pci/hda/hda_intel.c

between commits:

  1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist")
  40088dc4e1ea ("ALSA: hda - Revert power_save option default value")

from Linus' tree and commit:

  07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc sound/pci/hda/hda_intel.c
index d5017adf9feb,ec4e6b829ee2..
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@@ -2219,8 -2201,8 +2223,9 @@@ static int azx_probe_continue(struct az
struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
struct hdac_bus *bus = azx_bus(chip);
struct pci_dev *pci = chip->pci;
+   struct hda_codec *codec;
int dev = chip->dev_index;
 +  int val;
int err;
  
hda->probe_continued = 1;
@@@ -2302,21 -2284,16 +2307,30 @@@
chip->running = 1;
azx_add_card_list(chip);
  
 +  val = power_save;
 +#ifdef CONFIG_PM
 +  if (pm_blacklist) {
 +  const struct snd_pci_quirk *q;
 +
 +  q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
 +  if (q && val) {
 +  dev_info(chip->card->dev, "device %04x:%04x is on the 
power_save blacklist, forcing power_save to 0\n",
 +   q->subvendor, q->subdevice);
 +  val = 0;
 +  }
 +  }
 +#endif /* CONFIG_PM */
++
+   /*
+* The discrete GPU cannot power down unless the HDA controller runtime
+* suspends, so activate runtime PM on codecs even if power_save == 0.
+*/
+   if (use_vga_switcheroo(hda))
+   list_for_each_codec(codec, >bus)
+   codec->auto_runtime_pm = 1;
+ 
 -  snd_hda_set_power_save(>bus, power_save * 1000);
 +  snd_hda_set_power_save(>bus, val * 1000);
-   if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo)
+   if (azx_has_pm_runtime(chip))
pm_runtime_put_autosuspend(>dev);
  
  out_free:


pgp0IJPk8Eunq.pgp
Description: OpenPGP digital signature

Re: [PATCH v1 0/4] perf annotate: Create a new '--tui-dump' option

[Jin, Yao]

On 3/14/2018 9:54 PM, Arnaldo Carvalho de Melo wrote:

Em Wed, Mar 14, 2018 at 10:04:49AM +0800, Jin, Yao escreveu:



On 3/13/2018 11:20 PM, Arnaldo Carvalho de Melo wrote:

Em Tue, Mar 13, 2018 at 10:16:50PM +0800, Jin Yao escreveu:

There is a requirement to let perf annotate support displaying the IPC/Cycle.
In previous patch, this is supported in TUI mode. While it's not convenient
for users since they have to take screen shots and copy/paste data.

This patch series introduces a new option '--tui-dump' in perf annotate to
dump the TUI output to stdio.

User can easily use the command line like:
'perf annotate --tui-dump > /tmp/log.txt'


My first impression is that this pollutes the code with way too many
ifs, I was thinking more of a:

while (read parsed objdump line) {
ins__fprintf();
}



Yes, the issue in my patch is that it uses many 'if' to check if it's
tui_dump(or called 'stdio2') or tui mode.


Going from the refresh routine, I started doing the conversion, but haven't
completed it, there are opportunities for more __scnprintf like routines, also
one to find the percent_max, etc then those would be used both in these two for
--stdio2, that eventually would become --stdio with the old one becoming
--stdio1, till we're satisfied with the new default.



I have some questions for the following code. Please correct me if I
misunderstand anything.


static void annotation_line__fprintf(struct annotate_line *al, FILE *fp)
{
struct browser_line *bl = browser_line(al);
int i;
double percent_max = 0.0;
char bf[256];

for (i = 0; i < browser->nr_events; i++) {
if (al->samples[i].percent > percent_max)
percent_max = al->samples[i].percent;
}

/* the following if/else block should be transformed into a __scnprintf 
routine
  that formats a buffer and then the TUI and --stdio2 use it */

if (al->offset != -1 && percent_max != 0.0) {
for (i = 0; i < ab->nr_events; i++) {
if (annotate_browser__opts.show_total_period) {
fprintf(fp, browser, "%11" PRIu64 " ", 
al->samples[i].he.period);
} else if (annotate_browser__opts.show_nr_samples) {
fprintf(fp, browser, "%6" PRIu64 " ", 
al->samples[i].he.nr_samples);
} else {
fprintf(fp, "%6.2f ", al->samples[i].percent);
}
}
} else {
ui_browser__printf(browser, "%*s", pcnt_width,
   annotate_browser__opts.show_total_period ? 
"Period" :
   annotate_browser__opts.show_nr_samples ? "Samples" : 
"Percent");

}



I guess the above code has not been completed yet. My understanding for
Arnaldo's idea is that the output should be written to a buffer via
scnprintf and the buffer will be passed to TUI or stdio2 and printed out
later.

One potential issue is how to process the color for TUI? For example, the
call to ui_browser__set_percent_color. If we need to set color for TUI, it
looks we still have to check if it's a TUI mode.


That is part of the uncompleted code, if you want to show colors in
--stdio2 (and I think it is worth) then use color_fprintf() like other
stdio code.

For instance, 'perf top --stdio' uses red for hot lines, etc.
  


Maybe we can support showing color in a followup patch after the basic 
function is ready.



For example,

Suppose the bf[] has been written with the Percent string yet, next we need,

if (--tui) {
ui_browser__set_percent_color(...);
ui_browser__printf(bf, ...);
} else {
printf(..., bf);
}

Is my understanding correct?


The way I am suggesting there will be no if (tui), it will just reuse
the scnprintf routines that are now used in the TUI code, but will only
use fprintf/color_fprintf, etc.

The loop iterating over the annotation_lines you just lift from the tui
code.

And parts that are useful for both and are not yet in __scnprintf form,
then we need to make it so.



OK, I understand, the key point is to avoid using if (tui).

So looks the code will be divided into 2 parts.

Part1: symbol__tui_annotate ->
annotate_browser__refresh/annotate_browser__write

It's current code-path and it's for TUI mode. We will not change it.

Part2:
symbol__stdio2_annotate -> annotation_lines__fprintf -> 
annotation_line__fprintf


It's a new code-path and it's for --stdio2 only.

Is my understanding correct? If so, the good thing is we can avoid using 
if(tui), while maybe we can't easily reuse common code.


I just think what's the final target we want to reach. For me, I just 
wish we had better maintain only one mode (e.g. TUI mode) in future and 
for other modes (e.g. stdio), there will be no code work (or no much 
code work) for new added 

Re: [PATCH v1 0/4] perf annotate: Create a new '--tui-dump' option

[Jin, Yao]

On 3/14/2018 9:54 PM, Arnaldo Carvalho de Melo wrote:

Em Wed, Mar 14, 2018 at 10:04:49AM +0800, Jin, Yao escreveu:



On 3/13/2018 11:20 PM, Arnaldo Carvalho de Melo wrote:

Em Tue, Mar 13, 2018 at 10:16:50PM +0800, Jin Yao escreveu:

There is a requirement to let perf annotate support displaying the IPC/Cycle.
In previous patch, this is supported in TUI mode. While it's not convenient
for users since they have to take screen shots and copy/paste data.

This patch series introduces a new option '--tui-dump' in perf annotate to
dump the TUI output to stdio.

User can easily use the command line like:
'perf annotate --tui-dump > /tmp/log.txt'


My first impression is that this pollutes the code with way too many
ifs, I was thinking more of a:

while (read parsed objdump line) {
ins__fprintf();
}



Yes, the issue in my patch is that it uses many 'if' to check if it's
tui_dump(or called 'stdio2') or tui mode.


Going from the refresh routine, I started doing the conversion, but haven't
completed it, there are opportunities for more __scnprintf like routines, also
one to find the percent_max, etc then those would be used both in these two for
--stdio2, that eventually would become --stdio with the old one becoming
--stdio1, till we're satisfied with the new default.



I have some questions for the following code. Please correct me if I
misunderstand anything.


static void annotation_line__fprintf(struct annotate_line *al, FILE *fp)
{
struct browser_line *bl = browser_line(al);
int i;
double percent_max = 0.0;
char bf[256];

for (i = 0; i < browser->nr_events; i++) {
if (al->samples[i].percent > percent_max)
percent_max = al->samples[i].percent;
}

/* the following if/else block should be transformed into a __scnprintf 
routine
  that formats a buffer and then the TUI and --stdio2 use it */

if (al->offset != -1 && percent_max != 0.0) {
for (i = 0; i < ab->nr_events; i++) {
if (annotate_browser__opts.show_total_period) {
fprintf(fp, browser, "%11" PRIu64 " ", 
al->samples[i].he.period);
} else if (annotate_browser__opts.show_nr_samples) {
fprintf(fp, browser, "%6" PRIu64 " ", 
al->samples[i].he.nr_samples);
} else {
fprintf(fp, "%6.2f ", al->samples[i].percent);
}
}
} else {
ui_browser__printf(browser, "%*s", pcnt_width,
   annotate_browser__opts.show_total_period ? 
"Period" :
   annotate_browser__opts.show_nr_samples ? "Samples" : 
"Percent");

}



I guess the above code has not been completed yet. My understanding for
Arnaldo's idea is that the output should be written to a buffer via
scnprintf and the buffer will be passed to TUI or stdio2 and printed out
later.

One potential issue is how to process the color for TUI? For example, the
call to ui_browser__set_percent_color. If we need to set color for TUI, it
looks we still have to check if it's a TUI mode.


That is part of the uncompleted code, if you want to show colors in
--stdio2 (and I think it is worth) then use color_fprintf() like other
stdio code.

For instance, 'perf top --stdio' uses red for hot lines, etc.
  


Maybe we can support showing color in a followup patch after the basic 
function is ready.



For example,

Suppose the bf[] has been written with the Percent string yet, next we need,

if (--tui) {
ui_browser__set_percent_color(...);
ui_browser__printf(bf, ...);
} else {
printf(..., bf);
}

Is my understanding correct?


The way I am suggesting there will be no if (tui), it will just reuse
the scnprintf routines that are now used in the TUI code, but will only
use fprintf/color_fprintf, etc.

The loop iterating over the annotation_lines you just lift from the tui
code.

And parts that are useful for both and are not yet in __scnprintf form,
then we need to make it so.



OK, I understand, the key point is to avoid using if (tui).

So looks the code will be divided into 2 parts.

Part1: symbol__tui_annotate ->
annotate_browser__refresh/annotate_browser__write

It's current code-path and it's for TUI mode. We will not change it.

Part2:
symbol__stdio2_annotate -> annotation_lines__fprintf -> 
annotation_line__fprintf


It's a new code-path and it's for --stdio2 only.

Is my understanding correct? If so, the good thing is we can avoid using 
if(tui), while maybe we can't easily reuse common code.


I just think what's the final target we want to reach. For me, I just 
wish we had better maintain only one mode (e.g. TUI mode) in future and 
for other modes (e.g. stdio), there will be no code work (or no much 
code work) for new added 

Re: [PATCH v2 1/2] soc: imx: gpcv2: Do not pass static memory as platform data

[Shawn Guo]

On Thu, Feb 08, 2018 at 02:47:10PM +0800, Shawn Guo wrote:
> On Mon, Jan 22, 2018 at 07:07:47AM -0800, Andrey Smirnov wrote:
> > Platform device core assumes the ownership of dev.platform_data as
> > well as that it is dynamically allocated and it will try to kfree it
> > as a part of platform_device_release(). Change the code to pass
> > kzalloc'ed chunk of memory instead of a pointer to a static memory to
> > avoid causing a BUG() when calling platform_device_put().
> > 
> > The problem can be reproduced by artificially enabling the error path
> > of platform_device_add() call (around line 357).
> > 
> > Note that this change also allows us to constify imx7_pgc_domains,
> > since we no longer need to be able to modify it.
> > 
> > Cc: Shawn Guo 
> > Cc: Stefan Agner 
> > Cc: Lucas Stach 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Andrey Smirnov 
> 
> Applied both, thanks.

I decided to drop these two patches.  Triggered by Fabio's patch on top
of you changes, I just took another look at them, and found that
platform_device_add_data() can help us do the same thing in a nicer way.

Shawn

[1] https://patchwork.kernel.org/patch/10274969/

Re: [PATCH v2 1/2] soc: imx: gpcv2: Do not pass static memory as platform data

[Shawn Guo]

On Thu, Feb 08, 2018 at 02:47:10PM +0800, Shawn Guo wrote:
> On Mon, Jan 22, 2018 at 07:07:47AM -0800, Andrey Smirnov wrote:
> > Platform device core assumes the ownership of dev.platform_data as
> > well as that it is dynamically allocated and it will try to kfree it
> > as a part of platform_device_release(). Change the code to pass
> > kzalloc'ed chunk of memory instead of a pointer to a static memory to
> > avoid causing a BUG() when calling platform_device_put().
> > 
> > The problem can be reproduced by artificially enabling the error path
> > of platform_device_add() call (around line 357).
> > 
> > Note that this change also allows us to constify imx7_pgc_domains,
> > since we no longer need to be able to modify it.
> > 
> > Cc: Shawn Guo 
> > Cc: Stefan Agner 
> > Cc: Lucas Stach 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Andrey Smirnov 
> 
> Applied both, thanks.

I decided to drop these two patches.  Triggered by Fabio's patch on top
of you changes, I just took another look at them, and found that
platform_device_add_data() can help us do the same thing in a nicer way.

Shawn

[1] https://patchwork.kernel.org/patch/10274969/

[PATCH] xen: xenbus_dev_frontend: Really return response string

[Simon Gaiser]

xenbus_command_reply() did not actually copy the response string and
leaked stack content instead.

Fixes: 9a6161fe73bd ("xen: return xenstore command failures via response 
instead of rc")
Signed-off-by: Simon Gaiser 
---

PS: AFAICS this is not a security issue since /dev/xen/xenbus is
normally only accessible by root and giving xenstore access to a less
trusted entity probably has a bunch of other unintended consequences.

 drivers/xen/xenbus/xenbus_dev_frontend.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index a493e99bed21..845a70fa7f79 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -403,7 +403,7 @@ static int xenbus_command_reply(struct xenbus_file_priv *u,
 {
struct {
struct xsd_sockmsg hdr;
-   const char body[16];
+   char body[16];
} msg;
int rc;
 
@@ -412,6 +412,7 @@ static int xenbus_command_reply(struct xenbus_file_priv *u,
msg.hdr.len = strlen(reply) + 1;
if (msg.hdr.len > sizeof(msg.body))
return -E2BIG;
+   memcpy(, reply, msg.hdr.len);
 
mutex_lock(>reply_mutex);
rc = queue_reply(>read_buffers, , sizeof(msg.hdr) + msg.hdr.len);
-- 
2.16.2

[PATCH] xen: xenbus_dev_frontend: Really return response string

[Simon Gaiser]

xenbus_command_reply() did not actually copy the response string and
leaked stack content instead.

Fixes: 9a6161fe73bd ("xen: return xenstore command failures via response 
instead of rc")
Signed-off-by: Simon Gaiser 
---

PS: AFAICS this is not a security issue since /dev/xen/xenbus is
normally only accessible by root and giving xenstore access to a less
trusted entity probably has a bunch of other unintended consequences.

 drivers/xen/xenbus/xenbus_dev_frontend.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index a493e99bed21..845a70fa7f79 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -403,7 +403,7 @@ static int xenbus_command_reply(struct xenbus_file_priv *u,
 {
struct {
struct xsd_sockmsg hdr;
-   const char body[16];
+   char body[16];
} msg;
int rc;
 
@@ -412,6 +412,7 @@ static int xenbus_command_reply(struct xenbus_file_priv *u,
msg.hdr.len = strlen(reply) + 1;
if (msg.hdr.len > sizeof(msg.body))
return -E2BIG;
+   memcpy(, reply, msg.hdr.len);
 
mutex_lock(>reply_mutex);
rc = queue_reply(>read_buffers, , sizeof(msg.hdr) + msg.hdr.len);
-- 
2.16.2

[RFC PATCH v2] ACPI / processor: Fix possible CPUs map

[Dou Liyang]

Rafael J told me in order for the ACPI-based physical CPU hotplug to work,
there have to be objects in the ACPI namespace corresponding to all of the
processors in question. If they are not present, there is no way to signal
insertion and eject the processors safely.

But, Kernel calculates the possible CPU count from the number of Local APIC
entries in ACPI MADT. It doesn't consider with the ACPI namespace and
reports unrealistically high numbers. And kernel allocates resources
according to num_possible_cpus(), such as vectors, that may cause vector
space exhaustion and even bugs.

Depth-first search the namespace tree, check and collect the correct CPUs
and update the possible map.

Signed-off-by: Dou Liyang 
---
Changelog v1 --> v2:
 -Optimize the code by Andy Shevchenko's suggestion
 -modify the changelog

 drivers/acpi/acpi_processor.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 449d86d39965..ac45380f4439 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -671,6 +671,24 @@ static acpi_status __init 
acpi_processor_ids_walk(acpi_handle handle,
 
 }
 
+static void __init acpi_update_possible_map(void)
+{
+   unsigned int cpu;
+
+   if (nr_unique_ids >= nr_cpu_ids)
+   return;
+
+   /* Don't yet figure out if it's superfluous */
+   if (nr_unique_ids >= cpumask_last(cpu_possible_mask))
+   return;
+
+   for_each_cpu_wrap(cpu, cpu_possible_mask, nr_unique_ids)
+   set_cpu_possible(cpu, false);
+
+   nr_cpu_ids = nr_unique_ids;
+   pr_info("Allowing %d possible CPUs\n", nr_cpu_ids);
+}
+
 static void __init acpi_processor_check_duplicates(void)
 {
/* check the correctness for all processors in ACPI namespace */
@@ -680,6 +698,9 @@ static void __init acpi_processor_check_duplicates(void)
NULL, NULL, NULL);
acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, acpi_processor_ids_walk,
NULL, NULL);
+
+   /* make possible CPU count more realistic */
+   acpi_update_possible_map();
 }
 
 bool acpi_duplicate_processor_id(int proc_id)
-- 
2.14.3

[RFC PATCH v2] ACPI / processor: Fix possible CPUs map

[Dou Liyang]

Rafael J told me in order for the ACPI-based physical CPU hotplug to work,
there have to be objects in the ACPI namespace corresponding to all of the
processors in question. If they are not present, there is no way to signal
insertion and eject the processors safely.

But, Kernel calculates the possible CPU count from the number of Local APIC
entries in ACPI MADT. It doesn't consider with the ACPI namespace and
reports unrealistically high numbers. And kernel allocates resources
according to num_possible_cpus(), such as vectors, that may cause vector
space exhaustion and even bugs.

Depth-first search the namespace tree, check and collect the correct CPUs
and update the possible map.

Signed-off-by: Dou Liyang 
---
Changelog v1 --> v2:
 -Optimize the code by Andy Shevchenko's suggestion
 -modify the changelog

 drivers/acpi/acpi_processor.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 449d86d39965..ac45380f4439 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -671,6 +671,24 @@ static acpi_status __init 
acpi_processor_ids_walk(acpi_handle handle,
 
 }
 
+static void __init acpi_update_possible_map(void)
+{
+   unsigned int cpu;
+
+   if (nr_unique_ids >= nr_cpu_ids)
+   return;
+
+   /* Don't yet figure out if it's superfluous */
+   if (nr_unique_ids >= cpumask_last(cpu_possible_mask))
+   return;
+
+   for_each_cpu_wrap(cpu, cpu_possible_mask, nr_unique_ids)
+   set_cpu_possible(cpu, false);
+
+   nr_cpu_ids = nr_unique_ids;
+   pr_info("Allowing %d possible CPUs\n", nr_cpu_ids);
+}
+
 static void __init acpi_processor_check_duplicates(void)
 {
/* check the correctness for all processors in ACPI namespace */
@@ -680,6 +698,9 @@ static void __init acpi_processor_check_duplicates(void)
NULL, NULL, NULL);
acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, acpi_processor_ids_walk,
NULL, NULL);
+
+   /* make possible CPU count more realistic */
+   acpi_update_possible_map();
 }
 
 bool acpi_duplicate_processor_id(int proc_id)
-- 
2.14.3

Re: [PATCH v7 1/3] irqchip/gic-v3-its: add ability to save/restore ITS state

[dbasehore .]

On Wed, Mar 14, 2018 at 2:44 PM, dbasehore .  wrote:
> On Wed, Mar 14, 2018 at 3:22 AM, Marc Zyngier  wrote:
>> On 02/03/18 02:08, dbasehore . wrote:
>>> On Thu, Mar 1, 2018 at 4:29 AM, Marc Zyngier  wrote:
 Hi Mark,

 On 01/03/18 11:41, Mark Rutland wrote:
> On Wed, Feb 28, 2018 at 09:48:18PM -0800, Derek Basehore wrote:
>> Some platforms power off GIC logic in suspend, so we need to
>> save/restore state. The distributor and redistributor registers need
>> to be handled in platform code due to access permissions on those
>> registers, but the ITS registers can be restored in the kernel.
>>
>> Signed-off-by: Derek Basehore 
>
> How much state do we have to save/restore?
>
> Given we can apparently read all this state, couldn't we *always* save
> the state, then upon resume detect if the state has been lost, restoring
> it if so?
>
> That way, we don't need a property in FW tables for DT or ACPI.

 That's a good point. I guess that we could just compare the saved
 GITS_CTLR register and restore the full state only if the ITS comes back
 as disabled.

 I'm just a bit worried that it makes it an implicit convention between
 kernel an FW, which could change in funny ways. Importantly, the PSCI
 spec says states FW should restore *the whole state*. Obviously, it
 cannot to that on HW that doesn't allow you to read out the state, hence
 the DT flag that outlines the departure from the expected behaviour.

 I'm happy to go either way, but then I have the feeling that we should
 go back to quirking it on the actual implementation (GIC500 in this
 case) if we're to from the property.

>
> [...]
>
>> @@ -3261,6 +3363,9 @@ static int __init its_probe_one(struct resource 
>> *res,
>>  ctlr |= GITS_CTLR_ImDe;
>>  writel_relaxed(ctlr, its->base + GITS_CTLR);
>>
>> +if (fwnode_property_present(handle, "reset-on-suspend"))
>> +its->flags |= ITS_FLAGS_SAVE_SUSPEND_STATE;
>
> Does this allow this property on an ACPI system?
>
> If we need this on ACPI, we need a spec update to handle this properly,
> and shouldn't use device properties like this.

 Well spotted. I guess that dropping the property would fix that
 altogether, assuming we feel that the above is safe enough.

 Thoughts?
>>>
>>> I'm fine changing it to get rid of the devicetree property.
>>>
>>> What's the reason for quirking the behavior though? It's not that much
>>> code + data and nothing else relies on the state of the ITS getting
>>> disabled across suspend/resume. Even if something did, we'd have to
>>> resolve it with this feature anyways.
>>
>> The reason we do this is to cope with GIC500 having the collection state
>> in registers instead of memory. If we didn't have this extraordinary
>> misfeature, FW could do a full save/restore of the ITS, and we wouldn't
>> have to do anything (which is what the driver currently expects).
>>
>> A middle ground approach is to limit the feature to systems where
>> GITS_TYPER.HCC is non-zero instead of limiting it to GIC500. Pretty easy
>> to fix. This should have the same effect, as GIC500 is the only
>> implementation I'm aware of with HCC!=0.
>>
>> Given that we're already at -rc5 and that I'd like to queue things for
>> 4.17, I've made this change myself and queued patches 1 and 3 here[1].
>>
>> Can you please have a look at let me know if that works for you?
>>
>
> Assuming that your fine with only having the GIC500 implementations
> that have HCC as non-zero getting ITS registers restored in the
> kernel. As far as I can tell, this can happen in firmware for all
> implementations. It's only the code to resend that MAPC on resume that
> needs to be in the kernel.

Actually, I guess we can't tell if we need to resend MAPC on resume if
the firmware restores the state. Assuming it's a problem to just
resend MAPC all the time, only restoring the ITS registers in the
kernel when HCC != 0 makes sense.

>
>> Thanks,
>>
>> M.
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
>> irq/irqchip-next
>> --
>> Jazz is not dead. It just smells funny...

Re: [PATCH v7 1/3] irqchip/gic-v3-its: add ability to save/restore ITS state

[dbasehore .]

On Wed, Mar 14, 2018 at 2:44 PM, dbasehore .  wrote:
> On Wed, Mar 14, 2018 at 3:22 AM, Marc Zyngier  wrote:
>> On 02/03/18 02:08, dbasehore . wrote:
>>> On Thu, Mar 1, 2018 at 4:29 AM, Marc Zyngier  wrote:
 Hi Mark,

 On 01/03/18 11:41, Mark Rutland wrote:
> On Wed, Feb 28, 2018 at 09:48:18PM -0800, Derek Basehore wrote:
>> Some platforms power off GIC logic in suspend, so we need to
>> save/restore state. The distributor and redistributor registers need
>> to be handled in platform code due to access permissions on those
>> registers, but the ITS registers can be restored in the kernel.
>>
>> Signed-off-by: Derek Basehore 
>
> How much state do we have to save/restore?
>
> Given we can apparently read all this state, couldn't we *always* save
> the state, then upon resume detect if the state has been lost, restoring
> it if so?
>
> That way, we don't need a property in FW tables for DT or ACPI.

 That's a good point. I guess that we could just compare the saved
 GITS_CTLR register and restore the full state only if the ITS comes back
 as disabled.

 I'm just a bit worried that it makes it an implicit convention between
 kernel an FW, which could change in funny ways. Importantly, the PSCI
 spec says states FW should restore *the whole state*. Obviously, it
 cannot to that on HW that doesn't allow you to read out the state, hence
 the DT flag that outlines the departure from the expected behaviour.

 I'm happy to go either way, but then I have the feeling that we should
 go back to quirking it on the actual implementation (GIC500 in this
 case) if we're to from the property.

>
> [...]
>
>> @@ -3261,6 +3363,9 @@ static int __init its_probe_one(struct resource 
>> *res,
>>  ctlr |= GITS_CTLR_ImDe;
>>  writel_relaxed(ctlr, its->base + GITS_CTLR);
>>
>> +if (fwnode_property_present(handle, "reset-on-suspend"))
>> +its->flags |= ITS_FLAGS_SAVE_SUSPEND_STATE;
>
> Does this allow this property on an ACPI system?
>
> If we need this on ACPI, we need a spec update to handle this properly,
> and shouldn't use device properties like this.

 Well spotted. I guess that dropping the property would fix that
 altogether, assuming we feel that the above is safe enough.

 Thoughts?
>>>
>>> I'm fine changing it to get rid of the devicetree property.
>>>
>>> What's the reason for quirking the behavior though? It's not that much
>>> code + data and nothing else relies on the state of the ITS getting
>>> disabled across suspend/resume. Even if something did, we'd have to
>>> resolve it with this feature anyways.
>>
>> The reason we do this is to cope with GIC500 having the collection state
>> in registers instead of memory. If we didn't have this extraordinary
>> misfeature, FW could do a full save/restore of the ITS, and we wouldn't
>> have to do anything (which is what the driver currently expects).
>>
>> A middle ground approach is to limit the feature to systems where
>> GITS_TYPER.HCC is non-zero instead of limiting it to GIC500. Pretty easy
>> to fix. This should have the same effect, as GIC500 is the only
>> implementation I'm aware of with HCC!=0.
>>
>> Given that we're already at -rc5 and that I'd like to queue things for
>> 4.17, I've made this change myself and queued patches 1 and 3 here[1].
>>
>> Can you please have a look at let me know if that works for you?
>>
>
> Assuming that your fine with only having the GIC500 implementations
> that have HCC as non-zero getting ITS registers restored in the
> kernel. As far as I can tell, this can happen in firmware for all
> implementations. It's only the code to resend that MAPC on resume that
> needs to be in the kernel.

Actually, I guess we can't tell if we need to resend MAPC on resume if
the firmware restores the state. Assuming it's a problem to just
resend MAPC all the time, only restoring the ITS registers in the
kernel when HCC != 0 makes sense.

>
>> Thanks,
>>
>> M.
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
>> irq/irqchip-next
>> --
>> Jazz is not dead. It just smells funny...

Re: [RFC PATCH] ACPI / processor: Get accurate possible CPU count

[Dou Liyang]

Hi Andy,

At 03/15/2018 01:24 AM, Andy Shevchenko wrote:

On Wed, Mar 14, 2018 at 12:28 PM, Dou Liyang  wrote:


+static void __init acpi_update_possible_map(void)
+{
+   unsigned int cpu, nr = 0;
+



+   if (nr_cpu_ids <= nr_unique_ids)
+   return;
+
+   for_each_possible_cpu(cpu) {
+   if (nr >= nr_unique_ids)
+   set_cpu_possible(cpu, false);
+   nr++;
+   }


IIUC this can be optimized to:



Yes, I agree, It's smarter and clearer. Will use it.

Thanks,
dou


if (nr_unique_ids >= nr_cpu_ids)
 return;

/* Don't yet figure out if it's superfluous */
if (nr_unique_ids >= cpumask_last(cpu_possible_mask))
 return;

for_each_cpu_wrap(cpu, cpu_possible_mask, nr_unique_ids)
 set_cpu_possible(cpu, false);






+   nr_cpu_ids = nr_unique_ids;
+   pr_info("Allowing %d possible CPUs\n", nr_cpu_ids);
+}

Re: [RFC PATCH] ACPI / processor: Get accurate possible CPU count

[Dou Liyang]

Hi Andy,

At 03/15/2018 01:24 AM, Andy Shevchenko wrote:

On Wed, Mar 14, 2018 at 12:28 PM, Dou Liyang  wrote:


+static void __init acpi_update_possible_map(void)
+{
+   unsigned int cpu, nr = 0;
+



+   if (nr_cpu_ids <= nr_unique_ids)
+   return;
+
+   for_each_possible_cpu(cpu) {
+   if (nr >= nr_unique_ids)
+   set_cpu_possible(cpu, false);
+   nr++;
+   }


IIUC this can be optimized to:



Yes, I agree, It's smarter and clearer. Will use it.

Thanks,
dou


if (nr_unique_ids >= nr_cpu_ids)
 return;

/* Don't yet figure out if it's superfluous */
if (nr_unique_ids >= cpumask_last(cpu_possible_mask))
 return;

for_each_cpu_wrap(cpu, cpu_possible_mask, nr_unique_ids)
 set_cpu_possible(cpu, false);






+   nr_cpu_ids = nr_unique_ids;
+   pr_info("Allowing %d possible CPUs\n", nr_cpu_ids);
+}

Pls assist me to come and establish an industry in your country

[Dim Deng]

Genuine offer

How are you today and your family, I am a citizen of Sudan but
currently staying in Burkina Faso. My name is Miss Mariam Dim Deng,
25years old originated from Sudan.
My late father Dr. Dominic Dim Deng was the former Minister for SPLA
Affair and Special Adviser to President Salva Kiir of South Sudan for
Decentralization. You can read more about the crash through the below
site:
http://news.bbc.co.uk/2/hi/africa/7380412.stm

I am the only survival daughter of my late father, I want to establish
an industry in your country.My father left the sum of eight million,
four hundred thousand dollars, in the bank, so you will help me to
receive the fund for investment in your country.
Please can you be my partner and to direct me the way to establish an
industry,out of this fund I will give you 30% for helping me, please
contact me at email: m.dim.de...@gmail.com

Your beloved Mariam Dim Deng

Pls assist me to come and establish an industry in your country

[Dim Deng]

Genuine offer

How are you today and your family, I am a citizen of Sudan but
currently staying in Burkina Faso. My name is Miss Mariam Dim Deng,
25years old originated from Sudan.
My late father Dr. Dominic Dim Deng was the former Minister for SPLA
Affair and Special Adviser to President Salva Kiir of South Sudan for
Decentralization. You can read more about the crash through the below
site:
http://news.bbc.co.uk/2/hi/africa/7380412.stm

I am the only survival daughter of my late father, I want to establish
an industry in your country.My father left the sum of eight million,
four hundred thousand dollars, in the bank, so you will help me to
receive the fund for investment in your country.
Please can you be my partner and to direct me the way to establish an
industry,out of this fund I will give you 30% for helping me, please
contact me at email: m.dim.de...@gmail.com

Your beloved Mariam Dim Deng

linux-next: manual merge of the crypto tree with the asm-generic tree

[Stephen Rothwell]

Hi Herbert,

Today's linux-next merge of the crypto tree got a conflict in:

  drivers/crypto/bfin_crc.c

between commit:

  1d77094897bc ("crypto: remove blackfin CRC driver")

from the asm-generic tree and commits:

  f1b298103e14 ("crypto: bfin_crc - Add empty hash export and import")
  5471f2e2b5ea ("crypto: bfin_crc - Delete an error message for a failed memory 
allocation in bfin_crypto_crc_probe()")

from the crypto tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpUgDCoBX2jd.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the crypto tree with the asm-generic tree

[Stephen Rothwell]

Hi Herbert,

Today's linux-next merge of the crypto tree got a conflict in:

  drivers/crypto/bfin_crc.c

between commit:

  1d77094897bc ("crypto: remove blackfin CRC driver")

from the asm-generic tree and commits:

  f1b298103e14 ("crypto: bfin_crc - Add empty hash export and import")
  5471f2e2b5ea ("crypto: bfin_crc - Delete an error message for a failed memory 
allocation in bfin_crypto_crc_probe()")

from the crypto tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpUgDCoBX2jd.pgp
Description: OpenPGP digital signature

Re: [Y2038] [PATCH v4 02/10] include: Move compat_timespec/ timeval to compat_time.h

[Deepa Dinamani]

On Wed, Mar 14, 2018 at 1:52 PM, Arnd Bergmann  wrote:
> On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani  
> wrote:
>> The file arch/arm64/kernel/process.c needs asm/compat.h also to be
>> included directly since this is included conditionally from
>> include/compat.h. This does seem to be typical of arm64 as I was not
>> completely able to get rid of asm/compat.h includes for arm64 in this
>> series. My plan is to have separate patches to get rid of asm/compat.h
>> includes for the architectures that are not straight forward to keep
>> this series simple.
>> I will fix this and update the series.
>>
>
> I ran across the same thing in two more files during randconfig testing on
> arm64 now, adding this fixup on top for the moment, but maybe there
> is a better way:

I was looking at how Al tested his uaccess patches:
https://www.spinics.net/lists/linux-fsdevel/msg108752.html

He seems to be running the kbuild bot tests on his own git.
Is it possible to verify it this way on the 2038 tree? Or, I could
host a tree also.

Thanks,
Deepa

Re: [Y2038] [PATCH v4 02/10] include: Move compat_timespec/ timeval to compat_time.h

[Deepa Dinamani]

On Wed, Mar 14, 2018 at 1:52 PM, Arnd Bergmann  wrote:
> On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani  
> wrote:
>> The file arch/arm64/kernel/process.c needs asm/compat.h also to be
>> included directly since this is included conditionally from
>> include/compat.h. This does seem to be typical of arm64 as I was not
>> completely able to get rid of asm/compat.h includes for arm64 in this
>> series. My plan is to have separate patches to get rid of asm/compat.h
>> includes for the architectures that are not straight forward to keep
>> this series simple.
>> I will fix this and update the series.
>>
>
> I ran across the same thing in two more files during randconfig testing on
> arm64 now, adding this fixup on top for the moment, but maybe there
> is a better way:

I was looking at how Al tested his uaccess patches:
https://www.spinics.net/lists/linux-fsdevel/msg108752.html

He seems to be running the kbuild bot tests on his own git.
Is it possible to verify it this way on the 2038 tree? Or, I could
host a tree also.

Thanks,
Deepa

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

[Mike Galbraith]

On Wed, 2018-03-14 at 12:57 -0700, Tejun Heo wrote:
> Hello,
> 
> On Sat, Mar 10, 2018 at 04:47:28AM +0100, Mike Galbraith wrote:
> > Some form of cpu_exclusive (preferably exactly that, but something else
> > could replace it) is needed to define sets that must not overlap any
> > other set at creation time or any time thereafter.  A set with property
> > 'exclusive' is the enabler for fundamentally exclusive (but dynamic!)
> > set properties such as 'isolated' (etc etc).
> 
> I'm not sure cpu_exclusive makes sense.  A controller knob can either
> belong to the parent or the cgroup itself and cpu_exclusive doesn't
> make sense in either case.
> 
> 1. cpu_exclusive is owned by the parent as other usual resource
>control knobs.  IOW, it's not delegatable.
> 
>This is weird because it's asking the kernel to protect against its
>own misconfiguration and there's nothing preventing cpu_exclusive
>itself being cleared by the same entitya.
> 
> 2. cpu_exclusive is owned by the cgroup itself like memory.oom_group.
>IOW, it's delegatable.
> 
>This allows a cgroup to affect what its siblings can or cannot do,
>which is broken.  Semantically, it doesn't make much sense either.
> 
> I don't think it's a good idea to add a kernel mechanism to prevent
> misconfiguration from a single entity.

Under the hood v2 details are entirely up to you.  My input ends at
please don't leave dynamic partitioning standing at the dock when v2
sails.

-Mike

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

[Mike Galbraith]

On Wed, 2018-03-14 at 12:57 -0700, Tejun Heo wrote:
> Hello,
> 
> On Sat, Mar 10, 2018 at 04:47:28AM +0100, Mike Galbraith wrote:
> > Some form of cpu_exclusive (preferably exactly that, but something else
> > could replace it) is needed to define sets that must not overlap any
> > other set at creation time or any time thereafter.  A set with property
> > 'exclusive' is the enabler for fundamentally exclusive (but dynamic!)
> > set properties such as 'isolated' (etc etc).
> 
> I'm not sure cpu_exclusive makes sense.  A controller knob can either
> belong to the parent or the cgroup itself and cpu_exclusive doesn't
> make sense in either case.
> 
> 1. cpu_exclusive is owned by the parent as other usual resource
>control knobs.  IOW, it's not delegatable.
> 
>This is weird because it's asking the kernel to protect against its
>own misconfiguration and there's nothing preventing cpu_exclusive
>itself being cleared by the same entitya.
> 
> 2. cpu_exclusive is owned by the cgroup itself like memory.oom_group.
>IOW, it's delegatable.
> 
>This allows a cgroup to affect what its siblings can or cannot do,
>which is broken.  Semantically, it doesn't make much sense either.
> 
> I don't think it's a good idea to add a kernel mechanism to prevent
> misconfiguration from a single entity.

Under the hood v2 details are entirely up to you.  My input ends at
please don't leave dynamic partitioning standing at the dock when v2
sails.

-Mike

linux-next: manual merge of the nand tree with the asm-generic tree

[Stephen Rothwell]

Hi Boris,

Today's linux-next merge of the nand tree got a conflict in:

  drivers/mtd/nand/Kconfig
  (mostly moved to drivers/mtd/nand/raw/Kconfig)
  drivers/mtd/nand/Makefile
  (mostly moved to drivers/mtd/nand/raw/Makefile)
  drivers/mtd/nand/bf5xx_nand.c
  (renamed to drivers/mtd/nand/raw/bf5xx_nand.c)
  arch/cris/arch-v32/drivers/mach-a3/nandflash.c
  arch/cris/arch-v32/drivers/mach-fs/nandflash.c

between commits:

  2180873c59e1 ("mtd: nand: remove bf5xx_nand driver")
  77b0b77f7812 ("CRIS: Drop support for the CRIS port")

from the asm-generic tree and commits:

  93db446a424c ("mtd: nand: move raw NAND related code to the raw/ subdir")
  187c54488ead ("mtd: nand: State when references to other drivers are no 
longer valid")

from the nand tree.

I fixed it up:

I removed:
drivers/mtd/nand/raw/bf5xx_nand.c
arch/cris/arch-v32/drivers/mach-a3/nandflash.c
arch/cris/arch-v32/drivers/mach-fs/nandflash.c
added the following merge fix patch

and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

From: Stephen Rothwell 
Date: Thu, 15 Mar 2018 13:43:02 +1100
Subject: [PATCH] mtd: nand: fix up for blackfin removal

Signed-off-by: Stephen Rothwell 
---
 drivers/mtd/nand/raw/Kconfig  | 32 
 drivers/mtd/nand/raw/Makefile |  1 -
 2 files changed, 33 deletions(-)

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 605ec8cce67b..0f2b6f348a0a 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -116,38 +116,6 @@ config MTD_NAND_AU1550
  This enables the driver for the NAND flash controller on the
  AMD/Alchemy 1550 SOC.
 
-config MTD_NAND_BF5XX
-   tristate "Blackfin on-chip NAND Flash Controller driver"
-   depends on BF54x || BF52x
-   help
- This enables the Blackfin on-chip NAND flash controller
-
- No board specific support is done by this driver, each board
- must advertise a platform_device for the driver to attach.
-
- This driver can also be built as a module. If so, the module
- will be called bf5xx-nand.
-
-config MTD_NAND_BF5XX_HWECC
-   bool "BF5XX NAND Hardware ECC"
-   default y
-   depends on MTD_NAND_BF5XX
-   help
- Enable the use of the BF5XX's internal ECC generator when
- using NAND.
-
-config MTD_NAND_BF5XX_BOOTROM_ECC
-   bool "Use Blackfin BootROM ECC Layout"
-   default n
-   depends on MTD_NAND_BF5XX_HWECC
-   help
- If you wish to modify NAND pages and allow the Blackfin on-chip
- BootROM to boot from them, say Y here.  This is only necessary
- if you are booting U-Boot out of NAND and you wish to update
- U-Boot from Linux' userspace.  Otherwise, you should say N here.
-
- If unsure, say N.
-
 config MTD_NAND_S3C2410
tristate "NAND Flash support for Samsung S3C SoCs"
depends on ARCH_S3C24XX || ARCH_S3C64XX
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index f16f59a197a3..165b7ef9e9a1 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_MTD_NAND_DENALI) += denali.o
 obj-$(CONFIG_MTD_NAND_DENALI_PCI)  += denali_pci.o
 obj-$(CONFIG_MTD_NAND_DENALI_DT)   += denali_dt.o
 obj-$(CONFIG_MTD_NAND_AU1550)  += au1550nd.o
-obj-$(CONFIG_MTD_NAND_BF5XX)   += bf5xx_nand.o
 obj-$(CONFIG_MTD_NAND_S3C2410) += s3c2410.o
 obj-$(CONFIG_MTD_NAND_TANGO)   += tango_nand.o
 obj-$(CONFIG_MTD_NAND_DAVINCI) += davinci_nand.o
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell


pgpMydHOJVgRg.pgp
Description: OpenPGP digital signature

Re: [PATCH 22/47] cpufreq: remove blackfin driver

[Viresh Kumar]

On 14-03-18, 16:35, Arnd Bergmann wrote:
> The blackfin architecture is getting removed, so this driver is
> now obsolete.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/cpufreq/Makefile   |   1 -
>  drivers/cpufreq/blackfin-cpufreq.c | 217 
> -
>  2 files changed, 218 deletions(-)
>  delete mode 100644 drivers/cpufreq/blackfin-cpufreq.c
> 
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 4987227b67df..2e4495cf9aa8 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -101,7 +101,6 @@ obj-$(CONFIG_POWERNV_CPUFREQ) += 
> powernv-cpufreq.o
>  
>  
> ##
>  # Other platform drivers
> -obj-$(CONFIG_BFIN_CPU_FREQ)  += blackfin-cpufreq.o
>  obj-$(CONFIG_BMIPS_CPUFREQ)  += bmips-cpufreq.o
>  obj-$(CONFIG_CRIS_MACH_ARTPEC3)  += cris-artpec3-cpufreq.o
>  obj-$(CONFIG_ETRAXFS)+= cris-etraxfs-cpufreq.o
> diff --git a/drivers/cpufreq/blackfin-cpufreq.c 
> b/drivers/cpufreq/blackfin-cpufreq.c
> deleted file mode 100644
> index 12e97d8a9db0..

Acked-by: Viresh Kumar 

-- 
viresh

linux-next: manual merge of the nand tree with the asm-generic tree

[Stephen Rothwell]

Hi Boris,

Today's linux-next merge of the nand tree got a conflict in:

  drivers/mtd/nand/Kconfig
  (mostly moved to drivers/mtd/nand/raw/Kconfig)
  drivers/mtd/nand/Makefile
  (mostly moved to drivers/mtd/nand/raw/Makefile)
  drivers/mtd/nand/bf5xx_nand.c
  (renamed to drivers/mtd/nand/raw/bf5xx_nand.c)
  arch/cris/arch-v32/drivers/mach-a3/nandflash.c
  arch/cris/arch-v32/drivers/mach-fs/nandflash.c

between commits:

  2180873c59e1 ("mtd: nand: remove bf5xx_nand driver")
  77b0b77f7812 ("CRIS: Drop support for the CRIS port")

from the asm-generic tree and commits:

  93db446a424c ("mtd: nand: move raw NAND related code to the raw/ subdir")
  187c54488ead ("mtd: nand: State when references to other drivers are no 
longer valid")

from the nand tree.

I fixed it up:

I removed:
drivers/mtd/nand/raw/bf5xx_nand.c
arch/cris/arch-v32/drivers/mach-a3/nandflash.c
arch/cris/arch-v32/drivers/mach-fs/nandflash.c
added the following merge fix patch

and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

From: Stephen Rothwell 
Date: Thu, 15 Mar 2018 13:43:02 +1100
Subject: [PATCH] mtd: nand: fix up for blackfin removal

Signed-off-by: Stephen Rothwell 
---
 drivers/mtd/nand/raw/Kconfig  | 32 
 drivers/mtd/nand/raw/Makefile |  1 -
 2 files changed, 33 deletions(-)

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 605ec8cce67b..0f2b6f348a0a 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -116,38 +116,6 @@ config MTD_NAND_AU1550
  This enables the driver for the NAND flash controller on the
  AMD/Alchemy 1550 SOC.
 
-config MTD_NAND_BF5XX
-   tristate "Blackfin on-chip NAND Flash Controller driver"
-   depends on BF54x || BF52x
-   help
- This enables the Blackfin on-chip NAND flash controller
-
- No board specific support is done by this driver, each board
- must advertise a platform_device for the driver to attach.
-
- This driver can also be built as a module. If so, the module
- will be called bf5xx-nand.
-
-config MTD_NAND_BF5XX_HWECC
-   bool "BF5XX NAND Hardware ECC"
-   default y
-   depends on MTD_NAND_BF5XX
-   help
- Enable the use of the BF5XX's internal ECC generator when
- using NAND.
-
-config MTD_NAND_BF5XX_BOOTROM_ECC
-   bool "Use Blackfin BootROM ECC Layout"
-   default n
-   depends on MTD_NAND_BF5XX_HWECC
-   help
- If you wish to modify NAND pages and allow the Blackfin on-chip
- BootROM to boot from them, say Y here.  This is only necessary
- if you are booting U-Boot out of NAND and you wish to update
- U-Boot from Linux' userspace.  Otherwise, you should say N here.
-
- If unsure, say N.
-
 config MTD_NAND_S3C2410
tristate "NAND Flash support for Samsung S3C SoCs"
depends on ARCH_S3C24XX || ARCH_S3C64XX
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index f16f59a197a3..165b7ef9e9a1 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_MTD_NAND_DENALI) += denali.o
 obj-$(CONFIG_MTD_NAND_DENALI_PCI)  += denali_pci.o
 obj-$(CONFIG_MTD_NAND_DENALI_DT)   += denali_dt.o
 obj-$(CONFIG_MTD_NAND_AU1550)  += au1550nd.o
-obj-$(CONFIG_MTD_NAND_BF5XX)   += bf5xx_nand.o
 obj-$(CONFIG_MTD_NAND_S3C2410) += s3c2410.o
 obj-$(CONFIG_MTD_NAND_TANGO)   += tango_nand.o
 obj-$(CONFIG_MTD_NAND_DAVINCI) += davinci_nand.o
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell


pgpMydHOJVgRg.pgp
Description: OpenPGP digital signature

Re: [PATCH 22/47] cpufreq: remove blackfin driver

[Viresh Kumar]

On 14-03-18, 16:35, Arnd Bergmann wrote:
> The blackfin architecture is getting removed, so this driver is
> now obsolete.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/cpufreq/Makefile   |   1 -
>  drivers/cpufreq/blackfin-cpufreq.c | 217 
> -
>  2 files changed, 218 deletions(-)
>  delete mode 100644 drivers/cpufreq/blackfin-cpufreq.c
> 
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 4987227b67df..2e4495cf9aa8 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -101,7 +101,6 @@ obj-$(CONFIG_POWERNV_CPUFREQ) += 
> powernv-cpufreq.o
>  
>  
> ##
>  # Other platform drivers
> -obj-$(CONFIG_BFIN_CPU_FREQ)  += blackfin-cpufreq.o
>  obj-$(CONFIG_BMIPS_CPUFREQ)  += bmips-cpufreq.o
>  obj-$(CONFIG_CRIS_MACH_ARTPEC3)  += cris-artpec3-cpufreq.o
>  obj-$(CONFIG_ETRAXFS)+= cris-etraxfs-cpufreq.o
> diff --git a/drivers/cpufreq/blackfin-cpufreq.c 
> b/drivers/cpufreq/blackfin-cpufreq.c
> deleted file mode 100644
> index 12e97d8a9db0..

Acked-by: Viresh Kumar 

-- 
viresh

[PATCH 1/3] iommu/vt-d: Global PASID name space

[Lu Baolu]

This adds the algorithm to maintain a system wide PASID name space
for the PASID allocation. Previously we maintained a per IOMMU unit
PASID name space which is not suitable for some use cases. For an
example, one application (associated with one PASID) might talk to
two physical devices simultaneously where two devices could reside
behind two different IOMMU units.

Cc: Ashok Raj 
Cc: Jacob Pan 
Cc: Kevin Tian 
Cc: Liu Yi L 

Suggested-by: Ashok Raj 
Signed-off-by: Lu Baolu 
Reviewed-by: Kevin Tian 
---
 drivers/iommu/intel-iommu.c | 64 +
 include/linux/intel-iommu.h |  5 
 2 files changed, 69 insertions(+)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 582fd01..2a81936 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -518,6 +518,58 @@ static int iommu_identity_mapping;
 int intel_iommu_gfx_mapped;
 EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
 
+/*
+ * Intel IOMMU global PASID pool:
+ *
+ * Eventually I'm promised we will get a multi-level PASID table
+ * and it won't have to be physically contiguous. Until then,
+ * limit the size because 8MiB contiguous allocations can be hard
+ * to come by. The limit of 0x2, which is 1MiB for each of
+ * the PASID and PASID-state tables, is somewhat arbitrary.
+ *
+ * PASID 0 is reserved in caching mode (virtualised IOMMU).
+ */
+#define PASID_MIN  0x1
+#define PASID_MAX  0x2
+static DEFINE_SPINLOCK(pasid_lock);
+u32 intel_iommu_pasid_max = PASID_MAX;
+static DEFINE_IDR(pasid_idr);
+
+int intel_iommu_alloc_pasid(void *ptr, int start, int end, gfp_t gfp)
+{
+   int ret, min, max;
+
+   min = max_t(int, start, PASID_MIN);
+   max = min_t(int, end, intel_iommu_pasid_max);
+
+   WARN_ON(in_interrupt());
+   idr_preload(gfp);
+   spin_lock(_lock);
+   ret = idr_alloc(_idr, ptr, min, max, GFP_ATOMIC);
+   spin_unlock(_lock);
+   idr_preload_end();
+
+   return ret;
+}
+
+void intel_iommu_free_pasid(int pasid)
+{
+   spin_lock(_lock);
+   idr_remove(_idr, pasid);
+   spin_unlock(_lock);
+}
+
+void *intel_iommu_lookup_pasid(int pasid)
+{
+   void *p;
+
+   spin_lock(_lock);
+   p = idr_find(_idr, pasid);
+   spin_unlock(_lock);
+
+   return p;
+}
+
 #define DUMMY_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-1))
 static DEFINE_SPINLOCK(device_domain_lock);
 static LIST_HEAD(device_domain_list);
@@ -3263,6 +3315,18 @@ static int __init init_dmars(void)
}
 
for_each_active_iommu(iommu, drhd) {
+   /*
+* Find the max pasid size of all IOMMU's in the system.
+* we need to ensure the system pasid table is no bigger
+* than the smallest supported.
+*/
+   if (pasid_enabled(iommu)) {
+   u32 temp = 2 << ecap_pss(iommu->ecap);
+
+   intel_iommu_pasid_max = min_t(u32, temp,
+ intel_iommu_pasid_max);
+   }
+
g_iommus[iommu->seq_id] = iommu;
 
intel_iommu_init_qi(iommu);
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 8dad3dd..bf83073 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -494,4 +494,9 @@ extern struct intel_iommu *intel_svm_device_to_iommu(struct 
device *dev);
 
 extern const struct attribute_group *intel_iommu_groups[];
 
+extern u32 intel_iommu_pasid_max;
+int intel_iommu_alloc_pasid(void *ptr, int start, int end, gfp_t gfp);
+void intel_iommu_free_pasid(int pasid);
+void *intel_iommu_lookup_pasid(int pasid);
+
 #endif
-- 
2.7.4

[PATCH 1/3] iommu/vt-d: Global PASID name space

[Lu Baolu]

This adds the algorithm to maintain a system wide PASID name space
for the PASID allocation. Previously we maintained a per IOMMU unit
PASID name space which is not suitable for some use cases. For an
example, one application (associated with one PASID) might talk to
two physical devices simultaneously where two devices could reside
behind two different IOMMU units.

Cc: Ashok Raj 
Cc: Jacob Pan 
Cc: Kevin Tian 
Cc: Liu Yi L 

Suggested-by: Ashok Raj 
Signed-off-by: Lu Baolu 
Reviewed-by: Kevin Tian 
---
 drivers/iommu/intel-iommu.c | 64 +
 include/linux/intel-iommu.h |  5 
 2 files changed, 69 insertions(+)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 582fd01..2a81936 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -518,6 +518,58 @@ static int iommu_identity_mapping;
 int intel_iommu_gfx_mapped;
 EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
 
+/*
+ * Intel IOMMU global PASID pool:
+ *
+ * Eventually I'm promised we will get a multi-level PASID table
+ * and it won't have to be physically contiguous. Until then,
+ * limit the size because 8MiB contiguous allocations can be hard
+ * to come by. The limit of 0x2, which is 1MiB for each of
+ * the PASID and PASID-state tables, is somewhat arbitrary.
+ *
+ * PASID 0 is reserved in caching mode (virtualised IOMMU).
+ */
+#define PASID_MIN  0x1
+#define PASID_MAX  0x2
+static DEFINE_SPINLOCK(pasid_lock);
+u32 intel_iommu_pasid_max = PASID_MAX;
+static DEFINE_IDR(pasid_idr);
+
+int intel_iommu_alloc_pasid(void *ptr, int start, int end, gfp_t gfp)
+{
+   int ret, min, max;
+
+   min = max_t(int, start, PASID_MIN);
+   max = min_t(int, end, intel_iommu_pasid_max);
+
+   WARN_ON(in_interrupt());
+   idr_preload(gfp);
+   spin_lock(_lock);
+   ret = idr_alloc(_idr, ptr, min, max, GFP_ATOMIC);
+   spin_unlock(_lock);
+   idr_preload_end();
+
+   return ret;
+}
+
+void intel_iommu_free_pasid(int pasid)
+{
+   spin_lock(_lock);
+   idr_remove(_idr, pasid);
+   spin_unlock(_lock);
+}
+
+void *intel_iommu_lookup_pasid(int pasid)
+{
+   void *p;
+
+   spin_lock(_lock);
+   p = idr_find(_idr, pasid);
+   spin_unlock(_lock);
+
+   return p;
+}
+
 #define DUMMY_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-1))
 static DEFINE_SPINLOCK(device_domain_lock);
 static LIST_HEAD(device_domain_list);
@@ -3263,6 +3315,18 @@ static int __init init_dmars(void)
}
 
for_each_active_iommu(iommu, drhd) {
+   /*
+* Find the max pasid size of all IOMMU's in the system.
+* we need to ensure the system pasid table is no bigger
+* than the smallest supported.
+*/
+   if (pasid_enabled(iommu)) {
+   u32 temp = 2 << ecap_pss(iommu->ecap);
+
+   intel_iommu_pasid_max = min_t(u32, temp,
+ intel_iommu_pasid_max);
+   }
+
g_iommus[iommu->seq_id] = iommu;
 
intel_iommu_init_qi(iommu);
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 8dad3dd..bf83073 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -494,4 +494,9 @@ extern struct intel_iommu *intel_svm_device_to_iommu(struct 
device *dev);
 
 extern const struct attribute_group *intel_iommu_groups[];
 
+extern u32 intel_iommu_pasid_max;
+int intel_iommu_alloc_pasid(void *ptr, int start, int end, gfp_t gfp);
+void intel_iommu_free_pasid(int pasid);
+void *intel_iommu_lookup_pasid(int pasid);
+
 #endif
-- 
2.7.4

Re: [PATCH 23/47] cpufreq: remove cris specific drivers

[Viresh Kumar]

On 14-03-18, 16:35, Arnd Bergmann wrote:
> The cris architecture is getting removed, including the artpec3
> and etraxfs SoCs, so these cpufreq drivers are now unused.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/cpufreq/Makefile   |  2 -
>  drivers/cpufreq/cris-artpec3-cpufreq.c | 93 
> --
>  drivers/cpufreq/cris-etraxfs-cpufreq.c | 92 -
>  3 files changed, 187 deletions(-)
>  delete mode 100644 drivers/cpufreq/cris-artpec3-cpufreq.c
>  delete mode 100644 drivers/cpufreq/cris-etraxfs-cpufreq.c
> 
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 2e4495cf9aa8..8d24ade3bd02 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -102,8 +102,6 @@ obj-$(CONFIG_POWERNV_CPUFREQ) += 
> powernv-cpufreq.o
>  
> ##
>  # Other platform drivers
>  obj-$(CONFIG_BMIPS_CPUFREQ)  += bmips-cpufreq.o
> -obj-$(CONFIG_CRIS_MACH_ARTPEC3)  += cris-artpec3-cpufreq.o
> -obj-$(CONFIG_ETRAXFS)+= cris-etraxfs-cpufreq.o
>  obj-$(CONFIG_IA64_ACPI_CPUFREQ)  += ia64-acpi-cpufreq.o
>  obj-$(CONFIG_LOONGSON2_CPUFREQ)  += loongson2_cpufreq.o
>  obj-$(CONFIG_LOONGSON1_CPUFREQ)  += loongson1-cpufreq.o
> diff --git a/drivers/cpufreq/cris-artpec3-cpufreq.c 
> b/drivers/cpufreq/cris-artpec3-cpufreq.c
> deleted file mode 100644
> index 455b4fb78cba..
> diff --git a/drivers/cpufreq/cris-etraxfs-cpufreq.c 
> b/drivers/cpufreq/cris-etraxfs-cpufreq.c
> deleted file mode 100644
> index 4c4b5dd685e3..

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 23/47] cpufreq: remove cris specific drivers

[Viresh Kumar]

On 14-03-18, 16:35, Arnd Bergmann wrote:
> The cris architecture is getting removed, including the artpec3
> and etraxfs SoCs, so these cpufreq drivers are now unused.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/cpufreq/Makefile   |  2 -
>  drivers/cpufreq/cris-artpec3-cpufreq.c | 93 
> --
>  drivers/cpufreq/cris-etraxfs-cpufreq.c | 92 -
>  3 files changed, 187 deletions(-)
>  delete mode 100644 drivers/cpufreq/cris-artpec3-cpufreq.c
>  delete mode 100644 drivers/cpufreq/cris-etraxfs-cpufreq.c
> 
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 2e4495cf9aa8..8d24ade3bd02 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -102,8 +102,6 @@ obj-$(CONFIG_POWERNV_CPUFREQ) += 
> powernv-cpufreq.o
>  
> ##
>  # Other platform drivers
>  obj-$(CONFIG_BMIPS_CPUFREQ)  += bmips-cpufreq.o
> -obj-$(CONFIG_CRIS_MACH_ARTPEC3)  += cris-artpec3-cpufreq.o
> -obj-$(CONFIG_ETRAXFS)+= cris-etraxfs-cpufreq.o
>  obj-$(CONFIG_IA64_ACPI_CPUFREQ)  += ia64-acpi-cpufreq.o
>  obj-$(CONFIG_LOONGSON2_CPUFREQ)  += loongson2_cpufreq.o
>  obj-$(CONFIG_LOONGSON1_CPUFREQ)  += loongson1-cpufreq.o
> diff --git a/drivers/cpufreq/cris-artpec3-cpufreq.c 
> b/drivers/cpufreq/cris-artpec3-cpufreq.c
> deleted file mode 100644
> index 455b4fb78cba..
> diff --git a/drivers/cpufreq/cris-etraxfs-cpufreq.c 
> b/drivers/cpufreq/cris-etraxfs-cpufreq.c
> deleted file mode 100644
> index 4c4b5dd685e3..

Acked-by: Viresh Kumar 

-- 
viresh

[PATCH 3/3] iommu/vt-d: Use global PASID for SVM usage

[Lu Baolu]

This patch switches PASID management for SVM from SVM specific
idr to the global idr.

Cc: Ashok Raj 
Cc: Jacob Pan 
Cc: Kevin Tian 
Cc: Liu Yi L 

Signed-off-by: Lu Baolu 
Reviewed-by: Kevin Tian 
---
 drivers/iommu/intel-svm.c   | 20 +---
 include/linux/intel-iommu.h |  1 -
 2 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index f3b7394..1c45f75 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -85,8 +85,6 @@ int intel_svm_alloc_pasid_tables(struct intel_iommu *iommu)
iommu->name);
}
 
-   idr_init(>pasid_idr);
-
return 0;
 }
 
@@ -102,7 +100,7 @@ int intel_svm_free_pasid_tables(struct intel_iommu *iommu)
free_pages((unsigned long)iommu->pasid_state_table, order);
iommu->pasid_state_table = NULL;
}
-   idr_destroy(>pasid_idr);
+
return 0;
 }
 
@@ -392,9 +390,9 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int 
flags, struct svm_dev_
pasid_max = iommu->pasid_max;
 
/* Do not use PASID 0 in caching mode (virtualised IOMMU) */
-   ret = idr_alloc(>pasid_idr, svm,
-   !!cap_caching_mode(iommu->cap),
-   pasid_max - 1, GFP_KERNEL);
+   ret = intel_iommu_alloc_pasid(svm,
+ !!cap_caching_mode(iommu->cap),
+ pasid_max - 1, GFP_KERNEL);
if (ret < 0) {
kfree(svm);
goto out;
@@ -409,7 +407,7 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int 
flags, struct svm_dev_
if (mm) {
ret = mmu_notifier_register(>notifier, mm);
if (ret) {
-   idr_remove(>iommu->pasid_idr, svm->pasid);
+   intel_iommu_free_pasid(svm->pasid);
kfree(svm);
kfree(sdev);
goto out;
@@ -463,7 +461,7 @@ int intel_svm_unbind_mm(struct device *dev, int pasid)
if (!iommu || !iommu->pasid_table)
goto out;
 
-   svm = idr_find(>pasid_idr, pasid);
+   svm = intel_iommu_lookup_pasid(pasid);
if (!svm)
goto out;
 
@@ -488,7 +486,7 @@ int intel_svm_unbind_mm(struct device *dev, int pasid)
svm->iommu->pasid_table[svm->pasid].val 
= 0;
wmb();
 
-   idr_remove(>iommu->pasid_idr, 
svm->pasid);
+   intel_iommu_free_pasid(svm->pasid);
if (svm->mm)

mmu_notifier_unregister(>notifier, svm->mm);
 
@@ -523,7 +521,7 @@ int intel_svm_is_pasid_valid(struct device *dev, int pasid)
if (!iommu || !iommu->pasid_table)
goto out;
 
-   svm = idr_find(>pasid_idr, pasid);
+   svm = intel_iommu_lookup_pasid(pasid);
if (!svm)
goto out;
 
@@ -621,7 +619,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
 
if (!svm || svm->pasid != req->pasid) {
rcu_read_lock();
-   svm = idr_find(>pasid_idr, req->pasid);
+   svm = intel_iommu_lookup_pasid(req->pasid);
/* It *can't* go away, because the driver is not 
permitted
 * to unbind the mm while any page faults are 
outstanding.
 * So we only need RCU to protect the internal idr 
code. */
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index a2013dd..e50bef8 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -418,7 +418,6 @@ struct intel_iommu {
struct pasid_state_entry *pasid_state_table;
struct page_req_dsc *prq;
unsigned char prq_name[16];/* Name for PRQ interrupt */
-   struct idr pasid_idr;
u32 pasid_max;
 #endif
struct q_inval  *qi;/* Queued invalidation info */
-- 
2.7.4

[PATCH v2 3/3] xen: xenbus_dev_frontend: Verify body of XS_TRANSACTION_END

[Simon Gaiser]

By guaranteeing that the argument of XS_TRANSACTION_END is valid we can
assume that the transaction has been closed when we get an XS_ERROR
response from xenstore (Note that we already verify that it's a valid
transaction id).

Signed-off-by: Simon Gaiser 
---
 drivers/xen/xenbus/xenbus_dev_frontend.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index 81a84b3c1c50..0d6d9264d6a9 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -429,6 +429,10 @@ static int xenbus_write_transaction(unsigned msg_type,
 {
int rc;
struct xenbus_transaction_holder *trans = NULL;
+   struct {
+   struct xsd_sockmsg hdr;
+   char body[];
+   } *msg = (void *)u->u.buffer;
 
if (msg_type == XS_TRANSACTION_START) {
trans = kzalloc(sizeof(*trans), GFP_KERNEL);
@@ -437,11 +441,15 @@ static int xenbus_write_transaction(unsigned msg_type,
goto out;
}
list_add(>list, >transactions);
-   } else if (u->u.msg.tx_id != 0 &&
-  !xenbus_get_transaction(u, u->u.msg.tx_id))
+   } else if (msg->hdr.tx_id != 0 &&
+  !xenbus_get_transaction(u, msg->hdr.tx_id))
return xenbus_command_reply(u, XS_ERROR, "ENOENT");
+   else if (msg_type == XS_TRANSACTION_END &&
+!(msg->hdr.len == 2 &&
+  (!strcmp(msg->body, "T") || !strcmp(msg->body, "F"
+   return xenbus_command_reply(u, XS_ERROR, "EINVAL");
 
-   rc = xenbus_dev_request_and_reply(>u.msg, u);
+   rc = xenbus_dev_request_and_reply(>hdr, u);
if (rc && trans) {
list_del(>list);
kfree(trans);
-- 
2.16.2

[PATCH 3/3] iommu/vt-d: Use global PASID for SVM usage

[Lu Baolu]

This patch switches PASID management for SVM from SVM specific
idr to the global idr.

Cc: Ashok Raj 
Cc: Jacob Pan 
Cc: Kevin Tian 
Cc: Liu Yi L 

Signed-off-by: Lu Baolu 
Reviewed-by: Kevin Tian 
---
 drivers/iommu/intel-svm.c   | 20 +---
 include/linux/intel-iommu.h |  1 -
 2 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index f3b7394..1c45f75 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -85,8 +85,6 @@ int intel_svm_alloc_pasid_tables(struct intel_iommu *iommu)
iommu->name);
}
 
-   idr_init(>pasid_idr);
-
return 0;
 }
 
@@ -102,7 +100,7 @@ int intel_svm_free_pasid_tables(struct intel_iommu *iommu)
free_pages((unsigned long)iommu->pasid_state_table, order);
iommu->pasid_state_table = NULL;
}
-   idr_destroy(>pasid_idr);
+
return 0;
 }
 
@@ -392,9 +390,9 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int 
flags, struct svm_dev_
pasid_max = iommu->pasid_max;
 
/* Do not use PASID 0 in caching mode (virtualised IOMMU) */
-   ret = idr_alloc(>pasid_idr, svm,
-   !!cap_caching_mode(iommu->cap),
-   pasid_max - 1, GFP_KERNEL);
+   ret = intel_iommu_alloc_pasid(svm,
+ !!cap_caching_mode(iommu->cap),
+ pasid_max - 1, GFP_KERNEL);
if (ret < 0) {
kfree(svm);
goto out;
@@ -409,7 +407,7 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int 
flags, struct svm_dev_
if (mm) {
ret = mmu_notifier_register(>notifier, mm);
if (ret) {
-   idr_remove(>iommu->pasid_idr, svm->pasid);
+   intel_iommu_free_pasid(svm->pasid);
kfree(svm);
kfree(sdev);
goto out;
@@ -463,7 +461,7 @@ int intel_svm_unbind_mm(struct device *dev, int pasid)
if (!iommu || !iommu->pasid_table)
goto out;
 
-   svm = idr_find(>pasid_idr, pasid);
+   svm = intel_iommu_lookup_pasid(pasid);
if (!svm)
goto out;
 
@@ -488,7 +486,7 @@ int intel_svm_unbind_mm(struct device *dev, int pasid)
svm->iommu->pasid_table[svm->pasid].val 
= 0;
wmb();
 
-   idr_remove(>iommu->pasid_idr, 
svm->pasid);
+   intel_iommu_free_pasid(svm->pasid);
if (svm->mm)

mmu_notifier_unregister(>notifier, svm->mm);
 
@@ -523,7 +521,7 @@ int intel_svm_is_pasid_valid(struct device *dev, int pasid)
if (!iommu || !iommu->pasid_table)
goto out;
 
-   svm = idr_find(>pasid_idr, pasid);
+   svm = intel_iommu_lookup_pasid(pasid);
if (!svm)
goto out;
 
@@ -621,7 +619,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
 
if (!svm || svm->pasid != req->pasid) {
rcu_read_lock();
-   svm = idr_find(>pasid_idr, req->pasid);
+   svm = intel_iommu_lookup_pasid(req->pasid);
/* It *can't* go away, because the driver is not 
permitted
 * to unbind the mm while any page faults are 
outstanding.
 * So we only need RCU to protect the internal idr 
code. */
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index a2013dd..e50bef8 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -418,7 +418,6 @@ struct intel_iommu {
struct pasid_state_entry *pasid_state_table;
struct page_req_dsc *prq;
unsigned char prq_name[16];/* Name for PRQ interrupt */
-   struct idr pasid_idr;
u32 pasid_max;
 #endif
struct q_inval  *qi;/* Queued invalidation info */
-- 
2.7.4

[PATCH v2 3/3] xen: xenbus_dev_frontend: Verify body of XS_TRANSACTION_END

[Simon Gaiser]

By guaranteeing that the argument of XS_TRANSACTION_END is valid we can
assume that the transaction has been closed when we get an XS_ERROR
response from xenstore (Note that we already verify that it's a valid
transaction id).

Signed-off-by: Simon Gaiser 
---
 drivers/xen/xenbus/xenbus_dev_frontend.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index 81a84b3c1c50..0d6d9264d6a9 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -429,6 +429,10 @@ static int xenbus_write_transaction(unsigned msg_type,
 {
int rc;
struct xenbus_transaction_holder *trans = NULL;
+   struct {
+   struct xsd_sockmsg hdr;
+   char body[];
+   } *msg = (void *)u->u.buffer;
 
if (msg_type == XS_TRANSACTION_START) {
trans = kzalloc(sizeof(*trans), GFP_KERNEL);
@@ -437,11 +441,15 @@ static int xenbus_write_transaction(unsigned msg_type,
goto out;
}
list_add(>list, >transactions);
-   } else if (u->u.msg.tx_id != 0 &&
-  !xenbus_get_transaction(u, u->u.msg.tx_id))
+   } else if (msg->hdr.tx_id != 0 &&
+  !xenbus_get_transaction(u, msg->hdr.tx_id))
return xenbus_command_reply(u, XS_ERROR, "ENOENT");
+   else if (msg_type == XS_TRANSACTION_END &&
+!(msg->hdr.len == 2 &&
+  (!strcmp(msg->body, "T") || !strcmp(msg->body, "F"
+   return xenbus_command_reply(u, XS_ERROR, "EINVAL");
 
-   rc = xenbus_dev_request_and_reply(>u.msg, u);
+   rc = xenbus_dev_request_and_reply(>hdr, u);
if (rc && trans) {
list_del(>list);
kfree(trans);
-- 
2.16.2

[PATCH 2/3] iommu/vt-d: Decouple idr bond pointer from svm

[Lu Baolu]

As we move the PASID idr out of SVM code and make it serving
as a global PASID name space, the consumer can specify a ptr
to bind it with a PASID. We shouldn't assume that each PASID
will be bond with a ptr of struct intel_svm anymore.

This patch cleans up a idr_for_each_entry() usage in the SVM
code. It's required to replace the SVM-specific idr with the
global PASID idr.

Cc: Ashok Raj 
Cc: Jacob Pan 
Cc: Kevin Tian 
Cc: Liu Yi L 

Signed-off-by: Lu Baolu 
Reviewed-by: Kevin Tian 
---
 drivers/iommu/intel-svm.c   | 14 ++
 include/linux/intel-iommu.h |  1 +
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 99bc9bd..f3b7394 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -298,6 +298,7 @@ static const struct mmu_notifier_ops intel_mmuops = {
 };
 
 static DEFINE_MUTEX(pasid_mutex);
+static LIST_HEAD(global_svm_list);
 
 int intel_svm_bind_mm(struct device *dev, int *pasid, int flags, struct 
svm_dev_ops *ops)
 {
@@ -329,13 +330,13 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int 
flags, struct svm_dev_
 
mutex_lock(_mutex);
if (pasid && !(flags & SVM_FLAG_PRIVATE_PASID)) {
-   int i;
+   struct intel_svm *t;
 
-   idr_for_each_entry(>pasid_idr, svm, i) {
-   if (svm->mm != mm ||
-   (svm->flags & SVM_FLAG_PRIVATE_PASID))
+   list_for_each_entry(t, _svm_list, list) {
+   if (t->mm != mm || (t->flags & SVM_FLAG_PRIVATE_PASID))
continue;
 
+   svm = t;
if (svm->pasid >= pasid_max) {
dev_warn(dev,
 "Limited PASID width. Cannot use 
existing PASID %d\n",
@@ -403,6 +404,7 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int 
flags, struct svm_dev_
svm->mm = mm;
svm->flags = flags;
INIT_LIST_HEAD_RCU(>devs);
+   INIT_LIST_HEAD(>list);
ret = -ENOMEM;
if (mm) {
ret = mmu_notifier_register(>notifier, mm);
@@ -433,6 +435,8 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int 
flags, struct svm_dev_
 * anyway. Surely that can be left entirely to the guest? */
if (cap_caching_mode(iommu->cap))
intel_flush_pasid_dev(svm, sdev, 0);
+
+   list_add_tail(>list, _svm_list);
}
list_add_rcu(>list, >devs);
 
@@ -488,6 +492,8 @@ int intel_svm_unbind_mm(struct device *dev, int pasid)
if (svm->mm)

mmu_notifier_unregister(>notifier, svm->mm);
 
+   list_del(>list);
+
/* We mandate that no page faults may 
be outstanding
 * for the PASID when 
intel_svm_unbind_mm() is called.
 * If that is not obeyed, subtle errors 
will happen.
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index bf83073..a2013dd 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -486,6 +486,7 @@ struct intel_svm {
int flags;
int pasid;
struct list_head devs;
+   struct list_head list;
 };
 
 extern int intel_iommu_enable_pasid(struct intel_iommu *iommu, struct 
intel_svm_dev *sdev);
-- 
2.7.4

[PATCH 2/3] iommu/vt-d: Decouple idr bond pointer from svm

[Lu Baolu]

As we move the PASID idr out of SVM code and make it serving
as a global PASID name space, the consumer can specify a ptr
to bind it with a PASID. We shouldn't assume that each PASID
will be bond with a ptr of struct intel_svm anymore.

This patch cleans up a idr_for_each_entry() usage in the SVM
code. It's required to replace the SVM-specific idr with the
global PASID idr.

Cc: Ashok Raj 
Cc: Jacob Pan 
Cc: Kevin Tian 
Cc: Liu Yi L 

Signed-off-by: Lu Baolu 
Reviewed-by: Kevin Tian 
---
 drivers/iommu/intel-svm.c   | 14 ++
 include/linux/intel-iommu.h |  1 +
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 99bc9bd..f3b7394 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -298,6 +298,7 @@ static const struct mmu_notifier_ops intel_mmuops = {
 };
 
 static DEFINE_MUTEX(pasid_mutex);
+static LIST_HEAD(global_svm_list);
 
 int intel_svm_bind_mm(struct device *dev, int *pasid, int flags, struct 
svm_dev_ops *ops)
 {
@@ -329,13 +330,13 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int 
flags, struct svm_dev_
 
mutex_lock(_mutex);
if (pasid && !(flags & SVM_FLAG_PRIVATE_PASID)) {
-   int i;
+   struct intel_svm *t;
 
-   idr_for_each_entry(>pasid_idr, svm, i) {
-   if (svm->mm != mm ||
-   (svm->flags & SVM_FLAG_PRIVATE_PASID))
+   list_for_each_entry(t, _svm_list, list) {
+   if (t->mm != mm || (t->flags & SVM_FLAG_PRIVATE_PASID))
continue;
 
+   svm = t;
if (svm->pasid >= pasid_max) {
dev_warn(dev,
 "Limited PASID width. Cannot use 
existing PASID %d\n",
@@ -403,6 +404,7 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int 
flags, struct svm_dev_
svm->mm = mm;
svm->flags = flags;
INIT_LIST_HEAD_RCU(>devs);
+   INIT_LIST_HEAD(>list);
ret = -ENOMEM;
if (mm) {
ret = mmu_notifier_register(>notifier, mm);
@@ -433,6 +435,8 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int 
flags, struct svm_dev_
 * anyway. Surely that can be left entirely to the guest? */
if (cap_caching_mode(iommu->cap))
intel_flush_pasid_dev(svm, sdev, 0);
+
+   list_add_tail(>list, _svm_list);
}
list_add_rcu(>list, >devs);
 
@@ -488,6 +492,8 @@ int intel_svm_unbind_mm(struct device *dev, int pasid)
if (svm->mm)

mmu_notifier_unregister(>notifier, svm->mm);
 
+   list_del(>list);
+
/* We mandate that no page faults may 
be outstanding
 * for the PASID when 
intel_svm_unbind_mm() is called.
 * If that is not obeyed, subtle errors 
will happen.
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index bf83073..a2013dd 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -486,6 +486,7 @@ struct intel_svm {
int flags;
int pasid;
struct list_head devs;
+   struct list_head list;
 };
 
 extern int intel_iommu_enable_pasid(struct intel_iommu *iommu, struct 
intel_svm_dev *sdev);
-- 
2.7.4

[PATCH 0/3] iommu/vt-d: Global PASID name space

[Lu Baolu]

Hi,

This patch series is trying to change the scope of PASID management
used in Intel IOMMU driver from per IOMMU to driver global. This is
required for some cases where current per-IOMMU PASID name space
doesn't work. For an example, one application (associated with one
PASID) might talk to two physical devices simultaneously where two
devices could reside behind two different IOMMU units.

Best regards,
Lu Baolu

Lu Baolu (3):
  iommu/vt-d: Global PASID name space
  iommu/vt-d: Decouple idr bond pointer from svm
  iommu/vt-d: Use global PASID for SVM usage

 drivers/iommu/intel-iommu.c | 64 +
 drivers/iommu/intel-svm.c   | 34 +---
 include/linux/intel-iommu.h |  7 -
 3 files changed, 89 insertions(+), 16 deletions(-)

-- 
2.7.4

[PATCH 0/3] iommu/vt-d: Global PASID name space

[Lu Baolu]

Hi,

This patch series is trying to change the scope of PASID management
used in Intel IOMMU driver from per IOMMU to driver global. This is
required for some cases where current per-IOMMU PASID name space
doesn't work. For an example, one application (associated with one
PASID) might talk to two physical devices simultaneously where two
devices could reside behind two different IOMMU units.

Best regards,
Lu Baolu

Lu Baolu (3):
  iommu/vt-d: Global PASID name space
  iommu/vt-d: Decouple idr bond pointer from svm
  iommu/vt-d: Use global PASID for SVM usage

 drivers/iommu/intel-iommu.c | 64 +
 drivers/iommu/intel-svm.c   | 34 +---
 include/linux/intel-iommu.h |  7 -
 3 files changed, 89 insertions(+), 16 deletions(-)

-- 
2.7.4

[PATCH v2 2/3] xen: xenbus: Catch closing of non existent transactions

[Simon Gaiser]

Users of the xenbus functions should never close a non existent
transaction (for example by trying to closing the same transaction
twice) but better catch it in xs_request_exit() than to corrupt the
reference counter.

Signed-off-by: Simon Gaiser 
---
 drivers/xen/xenbus/xenbus_xs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 3f3b29398ab8..49a3874ae6bb 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -140,7 +140,9 @@ void xs_request_exit(struct xb_req_data *req)
spin_lock(_state_lock);
xs_state_users--;
if ((req->type == XS_TRANSACTION_START && req->msg.type == XS_ERROR) ||
-   req->type == XS_TRANSACTION_END)
+   (req->type == XS_TRANSACTION_END &&
+!WARN_ON_ONCE(req->msg.type == XS_ERROR &&
+  !strcmp(req->body, "ENOENT"
xs_state_users--;
spin_unlock(_state_lock);
 
-- 
2.16.2

[PATCH v2 2/3] xen: xenbus: Catch closing of non existent transactions

[Simon Gaiser]

Users of the xenbus functions should never close a non existent
transaction (for example by trying to closing the same transaction
twice) but better catch it in xs_request_exit() than to corrupt the
reference counter.

Signed-off-by: Simon Gaiser 
---
 drivers/xen/xenbus/xenbus_xs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 3f3b29398ab8..49a3874ae6bb 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -140,7 +140,9 @@ void xs_request_exit(struct xb_req_data *req)
spin_lock(_state_lock);
xs_state_users--;
if ((req->type == XS_TRANSACTION_START && req->msg.type == XS_ERROR) ||
-   req->type == XS_TRANSACTION_END)
+   (req->type == XS_TRANSACTION_END &&
+!WARN_ON_ONCE(req->msg.type == XS_ERROR &&
+  !strcmp(req->body, "ENOENT"
xs_state_users--;
spin_unlock(_state_lock);
 
-- 
2.16.2

[PATCH v2 1/3] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling

[Simon Gaiser]

Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
concurrent xenstore accesses") made a subtle change to the semantic of
xenbus_dev_request_and_reply() and xenbus_transaction_end().

Before on an error response to XS_TRANSACTION_END
xenbus_dev_request_and_reply() would not decrement the active
transaction counter. But xenbus_transaction_end() has always counted the
transaction as finished regardless of the response.

The new behavior is that xenbus_dev_request_and_reply() and
xenbus_transaction_end() will always count the transaction as finished
regardless the response code (handled in xs_request_exit()).

But xenbus_dev_frontend tries to end a transaction on closing of the
device if the XS_TRANSACTION_END failed before. Trying to close the
transaction twice corrupts the reference count. So fix this by also
considering a transaction closed if we have sent XS_TRANSACTION_END once
regardless of the return code.

Cc:  # 4.11
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent 
xenstore accesses")
Signed-off-by: Simon Gaiser 
---
 drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index a493e99bed21..81a84b3c1c50 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -365,7 +365,7 @@ void xenbus_dev_queue_reply(struct xb_req_data *req)
if (WARN_ON(rc))
goto out;
}
-   } else if (req->msg.type == XS_TRANSACTION_END) {
+   } else if (req->type == XS_TRANSACTION_END) {
trans = xenbus_get_transaction(u, req->msg.tx_id);
if (WARN_ON(!trans))
goto out;
-- 
2.16.2

[PATCH v2 1/3] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling

[Simon Gaiser]

Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
concurrent xenstore accesses") made a subtle change to the semantic of
xenbus_dev_request_and_reply() and xenbus_transaction_end().

Before on an error response to XS_TRANSACTION_END
xenbus_dev_request_and_reply() would not decrement the active
transaction counter. But xenbus_transaction_end() has always counted the
transaction as finished regardless of the response.

The new behavior is that xenbus_dev_request_and_reply() and
xenbus_transaction_end() will always count the transaction as finished
regardless the response code (handled in xs_request_exit()).

But xenbus_dev_frontend tries to end a transaction on closing of the
device if the XS_TRANSACTION_END failed before. Trying to close the
transaction twice corrupts the reference count. So fix this by also
considering a transaction closed if we have sent XS_TRANSACTION_END once
regardless of the return code.

Cc:  # 4.11
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent 
xenstore accesses")
Signed-off-by: Simon Gaiser 
---
 drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index a493e99bed21..81a84b3c1c50 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -365,7 +365,7 @@ void xenbus_dev_queue_reply(struct xb_req_data *req)
if (WARN_ON(rc))
goto out;
}
-   } else if (req->msg.type == XS_TRANSACTION_END) {
+   } else if (req->type == XS_TRANSACTION_END) {
trans = xenbus_get_transaction(u, req->msg.tx_id);
if (WARN_ON(!trans))
goto out;
-- 
2.16.2

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

[hl]

Hi Emil,


On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote:

Hi Lin,

On 14 March 2018 at 09:12, Lin Huang  wrote:

From: huang lin 

Refactor Innolux P079ZCA panel driver, let it support
multi panel.

Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
Signed-off-by: Lin Huang 
---
Changes in v2:
- Change regulator property name to meet the panel datasheet
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel, support 
P097PFG panel in another patch
Changes in v4:
- Modify the patch which suggest by Thierry


Thanks for splitting this up. I think there's another piece that fell
through the cracks.
I'm not deeply familiar with the driver, so just sharing some quick notes.



  struct innolux_panel {
 struct drm_panel base;
 struct mipi_dsi_device *link;
+   const struct panel_desc *desc;

 struct backlight_device *backlight;
-   struct regulator *supply;
+   struct regulator *vddi;
+   struct regulator *avdd;
+   struct regulator *avee;

These two seem are new addition, as opposed to a dummy refactor.
Are they optional, does one need them for the existing panel (separate
patch?) or only for the new one (squash with the new panel code)?



 struct gpio_desc *enable_gpio;

 bool prepared;
@@ -77,9 +93,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
 /* T8: 80ms - 1000ms */
 msleep(80);

-   err = regulator_disable(innolux->supply);
-   if (err < 0)
-   return err;

Good call on dropping the early return here.



@@ -207,19 +248,28 @@ static const struct drm_panel_funcs innolux_panel_funcs = 
{
-   innolux->supply = devm_regulator_get(dev, "power");
-   if (IS_ERR(innolux->supply))
-   return PTR_ERR(innolux->supply);
+   innolux = devm_kzalloc(dev, sizeof(*innolux), GFP_KERNEL);
+   if (!innolux)
+   return -ENOMEM;
+
+   innolux->desc = desc;
+   innolux->vddi = devm_regulator_get(dev, "power");
+   innolux->avdd = devm_regulator_get(dev, "avdd");
+   innolux->avee = devm_regulator_get(dev, "avee");


AFAICT devm_regulator_get returns a pointer which is unsuitable to be
passed into regulator_{enable,disable}.
Hence, the IS_ERR check should stay. If any of the regulators are
optional, you want to call regulator_{enable,disable} only as
applicable.


devm_regulator_get() will use dummy_regulator if there not regulator pass to 
driver,
so it not affect regulator_{enable, disable}. These three regulator are 
optional,
the p079zca will use "power" and p097pgf will use "avdd" and "avee",
so i think it better not to check ERR here.




@@ -318,5 +377,6 @@ static struct mipi_dsi_driver innolux_panel_driver = {
  module_mipi_dsi_driver(innolux_panel_driver);

  MODULE_AUTHOR("Chris Zhong ");
+MODULE_AUTHOR("Lin Huang ");

I don't think refactoring existing code classify as being the module author.
Then again, I could be wrong.

HTH
Emil

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

[hl]

Hi Emil,


On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote:

Hi Lin,

On 14 March 2018 at 09:12, Lin Huang  wrote:

From: huang lin 

Refactor Innolux P079ZCA panel driver, let it support
multi panel.

Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
Signed-off-by: Lin Huang 
---
Changes in v2:
- Change regulator property name to meet the panel datasheet
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel, support 
P097PFG panel in another patch
Changes in v4:
- Modify the patch which suggest by Thierry


Thanks for splitting this up. I think there's another piece that fell
through the cracks.
I'm not deeply familiar with the driver, so just sharing some quick notes.



  struct innolux_panel {
 struct drm_panel base;
 struct mipi_dsi_device *link;
+   const struct panel_desc *desc;

 struct backlight_device *backlight;
-   struct regulator *supply;
+   struct regulator *vddi;
+   struct regulator *avdd;
+   struct regulator *avee;

These two seem are new addition, as opposed to a dummy refactor.
Are they optional, does one need them for the existing panel (separate
patch?) or only for the new one (squash with the new panel code)?



 struct gpio_desc *enable_gpio;

 bool prepared;
@@ -77,9 +93,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
 /* T8: 80ms - 1000ms */
 msleep(80);

-   err = regulator_disable(innolux->supply);
-   if (err < 0)
-   return err;

Good call on dropping the early return here.



@@ -207,19 +248,28 @@ static const struct drm_panel_funcs innolux_panel_funcs = 
{
-   innolux->supply = devm_regulator_get(dev, "power");
-   if (IS_ERR(innolux->supply))
-   return PTR_ERR(innolux->supply);
+   innolux = devm_kzalloc(dev, sizeof(*innolux), GFP_KERNEL);
+   if (!innolux)
+   return -ENOMEM;
+
+   innolux->desc = desc;
+   innolux->vddi = devm_regulator_get(dev, "power");
+   innolux->avdd = devm_regulator_get(dev, "avdd");
+   innolux->avee = devm_regulator_get(dev, "avee");


AFAICT devm_regulator_get returns a pointer which is unsuitable to be
passed into regulator_{enable,disable}.
Hence, the IS_ERR check should stay. If any of the regulators are
optional, you want to call regulator_{enable,disable} only as
applicable.


devm_regulator_get() will use dummy_regulator if there not regulator pass to 
driver,
so it not affect regulator_{enable, disable}. These three regulator are 
optional,
the p079zca will use "power" and p097pgf will use "avdd" and "avee",
so i think it better not to check ERR here.




@@ -318,5 +377,6 @@ static struct mipi_dsi_driver innolux_panel_driver = {
  module_mipi_dsi_driver(innolux_panel_driver);

  MODULE_AUTHOR("Chris Zhong ");
+MODULE_AUTHOR("Lin Huang ");

I don't think refactoring existing code classify as being the module author.
Then again, I could be wrong.

HTH
Emil

Re: [PATCH v2] earlycon: Fix __earlycon_table stride... again

[Randy Dunlap]

On 03/14/2018 06:48 PM, Daniel Kurtz wrote:
> Commit 470ca0de69fe ("serial: earlycon: Enable earlycon without command
> line param") added EARLYCON_TABLE().
> 
> Commit 99492c39f39f ("earlycon: Fix __earlycon_table stride") referenced
> commit 07fca0e57fca92 ("tracing: Properly align linker defined symbols")
> and tried to fix EARLYCON_TABLE() using __aligned(32).
> 
> However, the fix copied just works around compiler behavior.  In fact, it
> was subsequently re-implemented for tracing using a table of pointers in
> commit 3d56e331b653 ("tracing: Replace syscall_meta_data struct array with
> pointer array"), commit 654986462939 ("tracepoints: Fix section alignment
> using pointer array") and commit e4a9ea5ee7c8 ("tracing: Replace
> trace_event struct array with pointer array").
> 
> Let's do the same "array of pointers to structs" approach for
> EARLYCON_TABLE.

Please describe what the problem is instead of just what the fix is.
Thanks.

> Signed-off-by: Daniel Kurtz 
> ---
> Changes since v1:
>  * Change __earlycon_table to an array of pointers.
> 
> Note: I do not have a convenient system to test the of/fdt.c part of this
> patch, so would apreciate help verifying it.  Thanks!
> 
>  drivers/of/fdt.c  |  7 +--
>  drivers/tty/serial/earlycon.c |  6 --
>  include/asm-generic/vmlinux.lds.h |  2 +-
>  include/linux/serial_core.h   | 21 ++---
>  4 files changed, 24 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 84aa9d676375..6da20b9688f7 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -942,7 +942,7 @@ int __init early_init_dt_scan_chosen_stdout(void)
>   int offset;
>   const char *p, *q, *options = NULL;
>   int l;
> - const struct earlycon_id *match;
> + const struct earlycon_id **p_match;
>   const void *fdt = initial_boot_params;
>  
>   offset = fdt_path_offset(fdt, "/chosen");
> @@ -969,7 +969,10 @@ int __init early_init_dt_scan_chosen_stdout(void)
>   return 0;
>   }
>  
> - for (match = __earlycon_table; match < __earlycon_table_end; match++) {
> + for (p_match = __earlycon_table; p_match < __earlycon_table_end;
> +  p_match++) {
> + const struct earlycon_id *match = *p_match;
> +
>   if (!match->compatible[0])
>   continue;
>  
> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> index a24278380fec..22683393a0f2 100644
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -169,7 +169,7 @@ static int __init register_earlycon(char *buf, const 
> struct earlycon_id *match)
>   */
>  int __init setup_earlycon(char *buf)
>  {
> - const struct earlycon_id *match;
> + const struct earlycon_id **p_match;
>  
>   if (!buf || !buf[0])
>   return -EINVAL;
> @@ -177,7 +177,9 @@ int __init setup_earlycon(char *buf)
>   if (early_con.flags & CON_ENABLED)
>   return -EALREADY;
>  
> - for (match = __earlycon_table; match < __earlycon_table_end; match++) {
> + for (p_match = __earlycon_table; p_match < __earlycon_table_end;
> +  p_match++) {
> + const struct earlycon_id *match = *p_match;
>   size_t len = strlen(match->name);
>  
>   if (strncmp(buf, match->name, len))
> diff --git a/include/asm-generic/vmlinux.lds.h 
> b/include/asm-generic/vmlinux.lds.h
> index 1ab0e520d6fc..e17de55c2542 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -179,7 +179,7 @@
>  #endif
>  
>  #ifdef CONFIG_SERIAL_EARLYCON
> -#define EARLYCON_TABLE() STRUCT_ALIGN(); \
> +#define EARLYCON_TABLE() . = ALIGN(8);   \
>VMLINUX_SYMBOL(__earlycon_table) = .;  \
>KEEP(*(__earlycon_table))  \
>VMLINUX_SYMBOL(__earlycon_table_end) = .;
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index b32df49a3bd5..93b7add47087 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -351,10 +351,10 @@ struct earlycon_id {
>   charname[16];
>   charcompatible[128];
>   int (*setup)(struct earlycon_device *, const char *options);
> -} __aligned(32);
> +};
>  
> -extern const struct earlycon_id __earlycon_table[];
> -extern const struct earlycon_id __earlycon_table_end[];
> +extern const struct earlycon_id *__earlycon_table[];
> +extern const struct earlycon_id *__earlycon_table_end[];
>  
>  #if defined(CONFIG_SERIAL_EARLYCON) && !defined(MODULE)
>  #define EARLYCON_USED_OR_UNUSED  __used
> @@ -362,12 +362,19 @@ extern const struct earlycon_id __earlycon_table_end[];
>  #define EARLYCON_USED_OR_UNUSED  __maybe_unused
>  #endif
>  
> -#define OF_EARLYCON_DECLARE(_name, compat, fn)   
> \
> - static 

Re: [PATCH v2] earlycon: Fix __earlycon_table stride... again

[Randy Dunlap]

On 03/14/2018 06:48 PM, Daniel Kurtz wrote:
> Commit 470ca0de69fe ("serial: earlycon: Enable earlycon without command
> line param") added EARLYCON_TABLE().
> 
> Commit 99492c39f39f ("earlycon: Fix __earlycon_table stride") referenced
> commit 07fca0e57fca92 ("tracing: Properly align linker defined symbols")
> and tried to fix EARLYCON_TABLE() using __aligned(32).
> 
> However, the fix copied just works around compiler behavior.  In fact, it
> was subsequently re-implemented for tracing using a table of pointers in
> commit 3d56e331b653 ("tracing: Replace syscall_meta_data struct array with
> pointer array"), commit 654986462939 ("tracepoints: Fix section alignment
> using pointer array") and commit e4a9ea5ee7c8 ("tracing: Replace
> trace_event struct array with pointer array").
> 
> Let's do the same "array of pointers to structs" approach for
> EARLYCON_TABLE.

Please describe what the problem is instead of just what the fix is.
Thanks.

> Signed-off-by: Daniel Kurtz 
> ---
> Changes since v1:
>  * Change __earlycon_table to an array of pointers.
> 
> Note: I do not have a convenient system to test the of/fdt.c part of this
> patch, so would apreciate help verifying it.  Thanks!
> 
>  drivers/of/fdt.c  |  7 +--
>  drivers/tty/serial/earlycon.c |  6 --
>  include/asm-generic/vmlinux.lds.h |  2 +-
>  include/linux/serial_core.h   | 21 ++---
>  4 files changed, 24 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 84aa9d676375..6da20b9688f7 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -942,7 +942,7 @@ int __init early_init_dt_scan_chosen_stdout(void)
>   int offset;
>   const char *p, *q, *options = NULL;
>   int l;
> - const struct earlycon_id *match;
> + const struct earlycon_id **p_match;
>   const void *fdt = initial_boot_params;
>  
>   offset = fdt_path_offset(fdt, "/chosen");
> @@ -969,7 +969,10 @@ int __init early_init_dt_scan_chosen_stdout(void)
>   return 0;
>   }
>  
> - for (match = __earlycon_table; match < __earlycon_table_end; match++) {
> + for (p_match = __earlycon_table; p_match < __earlycon_table_end;
> +  p_match++) {
> + const struct earlycon_id *match = *p_match;
> +
>   if (!match->compatible[0])
>   continue;
>  
> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> index a24278380fec..22683393a0f2 100644
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -169,7 +169,7 @@ static int __init register_earlycon(char *buf, const 
> struct earlycon_id *match)
>   */
>  int __init setup_earlycon(char *buf)
>  {
> - const struct earlycon_id *match;
> + const struct earlycon_id **p_match;
>  
>   if (!buf || !buf[0])
>   return -EINVAL;
> @@ -177,7 +177,9 @@ int __init setup_earlycon(char *buf)
>   if (early_con.flags & CON_ENABLED)
>   return -EALREADY;
>  
> - for (match = __earlycon_table; match < __earlycon_table_end; match++) {
> + for (p_match = __earlycon_table; p_match < __earlycon_table_end;
> +  p_match++) {
> + const struct earlycon_id *match = *p_match;
>   size_t len = strlen(match->name);
>  
>   if (strncmp(buf, match->name, len))
> diff --git a/include/asm-generic/vmlinux.lds.h 
> b/include/asm-generic/vmlinux.lds.h
> index 1ab0e520d6fc..e17de55c2542 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -179,7 +179,7 @@
>  #endif
>  
>  #ifdef CONFIG_SERIAL_EARLYCON
> -#define EARLYCON_TABLE() STRUCT_ALIGN(); \
> +#define EARLYCON_TABLE() . = ALIGN(8);   \
>VMLINUX_SYMBOL(__earlycon_table) = .;  \
>KEEP(*(__earlycon_table))  \
>VMLINUX_SYMBOL(__earlycon_table_end) = .;
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index b32df49a3bd5..93b7add47087 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -351,10 +351,10 @@ struct earlycon_id {
>   charname[16];
>   charcompatible[128];
>   int (*setup)(struct earlycon_device *, const char *options);
> -} __aligned(32);
> +};
>  
> -extern const struct earlycon_id __earlycon_table[];
> -extern const struct earlycon_id __earlycon_table_end[];
> +extern const struct earlycon_id *__earlycon_table[];
> +extern const struct earlycon_id *__earlycon_table_end[];
>  
>  #if defined(CONFIG_SERIAL_EARLYCON) && !defined(MODULE)
>  #define EARLYCON_USED_OR_UNUSED  __used
> @@ -362,12 +362,19 @@ extern const struct earlycon_id __earlycon_table_end[];
>  #define EARLYCON_USED_OR_UNUSED  __maybe_unused
>  #endif
>  
> -#define OF_EARLYCON_DECLARE(_name, compat, fn)   
> \
> - static const struct 

Re: [PATCH] Revert "mm/page_alloc: fix memmap_init_zone pageblock alignment"

[Daniel Vacek]

On Wed, Mar 14, 2018 at 6:36 PM, Ard Biesheuvel
 wrote:
> On 14 March 2018 at 16:41, Ard Biesheuvel  wrote:
>> On 14 March 2018 at 15:54, Ard Biesheuvel  wrote:
>>> On 14 March 2018 at 14:54, Michal Hocko  wrote:
 On Wed 14-03-18 14:35:12, Ard Biesheuvel wrote:
> On 14 March 2018 at 14:13, Michal Hocko  wrote:
> > Does http://lkml.kernel.org/r/20180313224240.25295-1-ne...@redhat.com
> > fix your issue? From the debugging info you provided it should because
> > the patch prevents jumping backwards.
> >
>
> The patch does fix the boot hang.
>
> But I am concerned that we are papering over a fundamental flaw in
> memblock_next_valid_pfn().

 It seems that memblock_next_valid_pfn is doing the right thing here. It
 is the alignment which moves the pfn back AFAICS. I am not really
 impressed about the original patch either, to be completely honest.
 It just looks awfully tricky. I still didn't manage to wrap my head
 around the original issue though so I do not have much better ideas to
 be honest.
>>>
>>> So first of all, memblock_next_valid_pfn() never refers to its max_pfn
>>> argument, which is odd nut easily fixed.
>>> Then, the whole idea of substracting one so that the pfn++ will
>>> produce the expected value is rather hacky,
>>>
>>> But the real problem is that rounding down pfn for the next iteration
>>> is dodgy, because early_pfn_valid() isn't guaranteed to return true
>>> for the rounded down value. I know it is probably fine in reality, but
>>> dodgy as hell. The same applies to the call to early_pfn_in_nid() btw
>>>
>>> So how about something like this (apologies on Gmail's behalf for the
>>> whitespace damage, I can resend it as a proper patch)
>>>
>>>
>>> -8<---
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index 3d974cb2a1a1..b89ca999ee3b 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -5352,28 +5352,29 @@
>>>  * function.  They do not exist on hotplugged memory.
>>>  */
>>> if (context != MEMMAP_EARLY)
>>> goto not_early;
>>>
>>> -   if (!early_pfn_valid(pfn)) {
>>> +   if (!early_pfn_valid(pfn) || !early_pfn_in_nid(pfn, nid)) {
>>>  #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
>>> /*
>>>  * Skip to the pfn preceding the next valid one (or
>>>  * end_pfn), such that we hit a valid pfn (or 
>>> end_pfn)
>>>  * on our next iteration of the loop. Note that it 
>>> needs
>>>  * to be pageblock aligned even when the region 
>>> itself
>>>  * is not. move_freepages_block() can shift ahead of
>>>  * the valid region but still depends on correct 
>>> page
>>>  * metadata.
>>>  */
>>> -   pfn = (memblock_next_valid_pfn(pfn, end_pfn) &
>>> -   ~(pageblock_nr_pages-1)) - 1;
>>> -#endif
>>> +   pfn = memblock_next_valid_pfn(pfn, end_pfn);
>>> +   if (pfn >= end_pfn)
>>> +   break;
>>> +   pfn &= ~(pageblock_nr_pages - 1);
>>> +#else
>>> continue;
>>> +#endif
>>> }
>>> -   if (!early_pfn_in_nid(pfn, nid))
>>> -   continue;
>>> if (!update_defer_init(pgdat, pfn, end_pfn, 
>>> _initialised))
>>> break;
>>>
>>>  #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
>>> /*
>>> -8<---
>>>
>>> This ensures that we enter the remainder of the loop with a properly
>>> aligned pfn, rather than tweaking the value of pfn so it assumes the
>>> expected value after 'pfn++'
>>
>> Um, this does not actually solve the issue. I guess this is due to the
>> fact that a single pageblock size chunk could have both valid and
>> invalid PFNs, and so rounding down the first PFN of the second valid
>> chunk moves you back to the first chunk.
>
> OK, so the original patch attempted to ensure that of each pageblock,
> at least the first struct page gets initialized, even though the PFN
> may not be valid. Unfortunately, this code is not complete, given that
> start_pfn itself may be misaligned, and so the issue it attempts to
> solve may still occur.

You're wrong here.

> Then, I think it is absolutely dodgy to settle for only initializing
> the first struct page, rather than all of them, only because a
> specific VM_BUG_ON() references the flag field of the first struct
> page.
> IMO, we should fix this by initializing all struct page entries for
> each pageblock sized chunk that has any valid PFNs.

That's precisely what my patch does. 

Re: [GIT PULL] SCSI fixes for 4.16-rc5

[Martin K. Petersen]

Linus,

> I've pulled it, but I don't see why (and how) this kind of garbage got
> reviewed and acked by multiple people.

My bad. I actually did notice the superfluous ifs and meant to nuke them
when I committed the patch.

However, I had a freak accident with my fixes branch that day that
compelled me to reset to my latest public hash and redo several
commits. I completely forgot that I had intended to tweak this patch
when I finally got around to applying it. I should have looked closer,
but it was already in my "done" pile.

Botched it. Sorry about that!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] Revert "mm/page_alloc: fix memmap_init_zone pageblock alignment"

[Daniel Vacek]

On Wed, Mar 14, 2018 at 6:36 PM, Ard Biesheuvel
 wrote:
> On 14 March 2018 at 16:41, Ard Biesheuvel  wrote:
>> On 14 March 2018 at 15:54, Ard Biesheuvel  wrote:
>>> On 14 March 2018 at 14:54, Michal Hocko  wrote:
 On Wed 14-03-18 14:35:12, Ard Biesheuvel wrote:
> On 14 March 2018 at 14:13, Michal Hocko  wrote:
> > Does http://lkml.kernel.org/r/20180313224240.25295-1-ne...@redhat.com
> > fix your issue? From the debugging info you provided it should because
> > the patch prevents jumping backwards.
> >
>
> The patch does fix the boot hang.
>
> But I am concerned that we are papering over a fundamental flaw in
> memblock_next_valid_pfn().

 It seems that memblock_next_valid_pfn is doing the right thing here. It
 is the alignment which moves the pfn back AFAICS. I am not really
 impressed about the original patch either, to be completely honest.
 It just looks awfully tricky. I still didn't manage to wrap my head
 around the original issue though so I do not have much better ideas to
 be honest.
>>>
>>> So first of all, memblock_next_valid_pfn() never refers to its max_pfn
>>> argument, which is odd nut easily fixed.
>>> Then, the whole idea of substracting one so that the pfn++ will
>>> produce the expected value is rather hacky,
>>>
>>> But the real problem is that rounding down pfn for the next iteration
>>> is dodgy, because early_pfn_valid() isn't guaranteed to return true
>>> for the rounded down value. I know it is probably fine in reality, but
>>> dodgy as hell. The same applies to the call to early_pfn_in_nid() btw
>>>
>>> So how about something like this (apologies on Gmail's behalf for the
>>> whitespace damage, I can resend it as a proper patch)
>>>
>>>
>>> -8<---
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index 3d974cb2a1a1..b89ca999ee3b 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -5352,28 +5352,29 @@
>>>  * function.  They do not exist on hotplugged memory.
>>>  */
>>> if (context != MEMMAP_EARLY)
>>> goto not_early;
>>>
>>> -   if (!early_pfn_valid(pfn)) {
>>> +   if (!early_pfn_valid(pfn) || !early_pfn_in_nid(pfn, nid)) {
>>>  #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
>>> /*
>>>  * Skip to the pfn preceding the next valid one (or
>>>  * end_pfn), such that we hit a valid pfn (or 
>>> end_pfn)
>>>  * on our next iteration of the loop. Note that it 
>>> needs
>>>  * to be pageblock aligned even when the region 
>>> itself
>>>  * is not. move_freepages_block() can shift ahead of
>>>  * the valid region but still depends on correct 
>>> page
>>>  * metadata.
>>>  */
>>> -   pfn = (memblock_next_valid_pfn(pfn, end_pfn) &
>>> -   ~(pageblock_nr_pages-1)) - 1;
>>> -#endif
>>> +   pfn = memblock_next_valid_pfn(pfn, end_pfn);
>>> +   if (pfn >= end_pfn)
>>> +   break;
>>> +   pfn &= ~(pageblock_nr_pages - 1);
>>> +#else
>>> continue;
>>> +#endif
>>> }
>>> -   if (!early_pfn_in_nid(pfn, nid))
>>> -   continue;
>>> if (!update_defer_init(pgdat, pfn, end_pfn, 
>>> _initialised))
>>> break;
>>>
>>>  #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
>>> /*
>>> -8<---
>>>
>>> This ensures that we enter the remainder of the loop with a properly
>>> aligned pfn, rather than tweaking the value of pfn so it assumes the
>>> expected value after 'pfn++'
>>
>> Um, this does not actually solve the issue. I guess this is due to the
>> fact that a single pageblock size chunk could have both valid and
>> invalid PFNs, and so rounding down the first PFN of the second valid
>> chunk moves you back to the first chunk.
>
> OK, so the original patch attempted to ensure that of each pageblock,
> at least the first struct page gets initialized, even though the PFN
> may not be valid. Unfortunately, this code is not complete, given that
> start_pfn itself may be misaligned, and so the issue it attempts to
> solve may still occur.

You're wrong here.

> Then, I think it is absolutely dodgy to settle for only initializing
> the first struct page, rather than all of them, only because a
> specific VM_BUG_ON() references the flag field of the first struct
> page.
> IMO, we should fix this by initializing all struct page entries for
> each pageblock sized chunk that has any valid PFNs.

That's precisely what my patch does. At least with
CONFIG_HAVE_ARCH_PFN_VALID disabled. And it looks only arm implements
arch pfn_valid() which I was not 

Re: [GIT PULL] SCSI fixes for 4.16-rc5

[Martin K. Petersen]

Linus,

> I've pulled it, but I don't see why (and how) this kind of garbage got
> reviewed and acked by multiple people.

My bad. I actually did notice the superfluous ifs and meant to nuke them
when I committed the patch.

However, I had a freak accident with my fixes branch that day that
compelled me to reset to my latest public hash and redo several
commits. I completely forgot that I had intended to tweak this patch
when I finally got around to applying it. I should have looked closer,
but it was already in my "done" pile.

Botched it. Sorry about that!

-- 
Martin K. Petersen  Oracle Linux Engineering