Re: [PATCH v6 1/2] mm: migration: fix migration of huge PMD shared pages
On Thu 30-08-18 14:39:44, Jerome Glisse wrote: > On Thu, Aug 30, 2018 at 11:05:16AM -0700, Mike Kravetz wrote: > > On 08/30/2018 09:57 AM, Jerome Glisse wrote: > > > On Thu, Aug 30, 2018 at 06:19:52PM +0200, Michal Hocko wrote: > > >> On Thu 30-08-18 10:08:25, Jerome Glisse wrote: > > >>> On Thu, Aug 30, 2018 at 12:56:16PM +0200, Michal Hocko wrote: > > On Wed 29-08-18 17:11:07, Jerome Glisse wrote: > > > On Wed, Aug 29, 2018 at 08:39:06PM +0200, Michal Hocko wrote: > > >> On Wed 29-08-18 14:14:25, Jerome Glisse wrote: > > >>> On Wed, Aug 29, 2018 at 10:24:44AM -0700, Mike Kravetz wrote: > > >> [...] > > What would be the best mmu notifier interface to use where there > > are no > > start/end calls? > > Or, is the best solution to add the start/end calls as is done in > > later > > versions of the code? If that is the suggestion, has there been > > any change > > in invalidate start/end semantics that we should take into account? > > >>> > > >>> start/end would be the one to add, 4.4 seems broken in respect to > > >>> THP > > >>> and mmu notification. Another solution is to fix user of mmu > > >>> notifier, > > >>> they were only a handful back then. For instance properly adjust the > > >>> address to match first address covered by pmd or pud and passing > > >>> down > > >>> correct page size to mmu_notifier_invalidate_page() would allow to > > >>> fix > > >>> this easily. > > >>> > > >>> This is ok because user of try_to_unmap_one() replace the > > >>> pte/pmd/pud > > >>> with an invalid one (either poison, migration or swap) inside the > > >>> function. So anyone racing would synchronize on those special entry > > >>> hence why it is fine to delay mmu_notifier_invalidate_page() to > > >>> after > > >>> dropping the page table lock. > > >>> > > >>> Adding start/end might the solution with less code churn as you > > >>> would > > >>> only need to change try_to_unmap_one(). > > >> > > >> What about dependencies? 369ea8242c0fb sounds like it needs work for > > >> all > > >> notifiers need to be updated as well. > > > > > > This commit remove mmu_notifier_invalidate_page() hence why everything > > > need to be updated. But in 4.4 you can get away with just adding > > > start/ > > > end and keep around mmu_notifier_invalidate_page() to minimize > > > disruption. > > > > OK, this is really interesting. I was really worried to change the > > semantic of the mmu notifiers in stable kernels because this is really > > a hard to review change and high risk for anybody running those old > > kernels. If we can keep the mmu_notifier_invalidate_page and wrap them > > into the range scope API then this sounds like the best way forward. > > > > So just to make sure we are at the same page. Does this sounds goo for > > stable 4.4. backport? Mike's hugetlb pmd shared fixup can be applied on > > top. What do you think? > > >>> > > >>> You need to invalidate outside page table lock so before the call to > > >>> page_check_address(). For instance like below patch, which also only > > >>> do the range invalidation for huge page which would avoid too much of > > >>> a behavior change for user of mmu notifier. > > >> > > >> Right. I would rather not make this PageHuge special though. So the > > >> fixed version should be. > > > > > > Why not testing for huge ? Only huge is broken and thus only that > > > need the extra range invalidation. Doing the double invalidation > > > for single page is bit overkill. > > > > I am a bit confused, and hope this does not add to any confusion by others. > > > > IIUC, the patch below does not attempt to 'fix' anything. It is simply > > there to add the start/end notifiers to the v4.4 version of this routine > > so that a subsequent patch can use them (with modified ranges) to handle > > unmapping a shared pmd huge page. That is the mainline fix which started > > this thread. > > > > Since we are only/mostly interested in fixing the shared pmd issue in > > 4.4, how about just adding the start/end notifiers to the very specific > > case where pmd sharing is possible? > > > > I can see the value in trying to back port dependent patches such as this > > so that stable releases look more like mainline. However, I am not sure of > > the value in this case as this patch was part of a larger set changing > > notifier semantics. > > For all intents and purposes this is not a backport of the original > patch so maybe we should just drop the commit reference and just > explains that it is there to fix mmu notifier in respect to huge page > migration. > > The original patches fix more than this case because newer featurers > like THP migration, THP swapping, ... added more cases where things > would have been
Re: [PATCH v6 1/2] mm: migration: fix migration of huge PMD shared pages
On Thu 30-08-18 14:39:44, Jerome Glisse wrote: > On Thu, Aug 30, 2018 at 11:05:16AM -0700, Mike Kravetz wrote: > > On 08/30/2018 09:57 AM, Jerome Glisse wrote: > > > On Thu, Aug 30, 2018 at 06:19:52PM +0200, Michal Hocko wrote: > > >> On Thu 30-08-18 10:08:25, Jerome Glisse wrote: > > >>> On Thu, Aug 30, 2018 at 12:56:16PM +0200, Michal Hocko wrote: > > On Wed 29-08-18 17:11:07, Jerome Glisse wrote: > > > On Wed, Aug 29, 2018 at 08:39:06PM +0200, Michal Hocko wrote: > > >> On Wed 29-08-18 14:14:25, Jerome Glisse wrote: > > >>> On Wed, Aug 29, 2018 at 10:24:44AM -0700, Mike Kravetz wrote: > > >> [...] > > What would be the best mmu notifier interface to use where there > > are no > > start/end calls? > > Or, is the best solution to add the start/end calls as is done in > > later > > versions of the code? If that is the suggestion, has there been > > any change > > in invalidate start/end semantics that we should take into account? > > >>> > > >>> start/end would be the one to add, 4.4 seems broken in respect to > > >>> THP > > >>> and mmu notification. Another solution is to fix user of mmu > > >>> notifier, > > >>> they were only a handful back then. For instance properly adjust the > > >>> address to match first address covered by pmd or pud and passing > > >>> down > > >>> correct page size to mmu_notifier_invalidate_page() would allow to > > >>> fix > > >>> this easily. > > >>> > > >>> This is ok because user of try_to_unmap_one() replace the > > >>> pte/pmd/pud > > >>> with an invalid one (either poison, migration or swap) inside the > > >>> function. So anyone racing would synchronize on those special entry > > >>> hence why it is fine to delay mmu_notifier_invalidate_page() to > > >>> after > > >>> dropping the page table lock. > > >>> > > >>> Adding start/end might the solution with less code churn as you > > >>> would > > >>> only need to change try_to_unmap_one(). > > >> > > >> What about dependencies? 369ea8242c0fb sounds like it needs work for > > >> all > > >> notifiers need to be updated as well. > > > > > > This commit remove mmu_notifier_invalidate_page() hence why everything > > > need to be updated. But in 4.4 you can get away with just adding > > > start/ > > > end and keep around mmu_notifier_invalidate_page() to minimize > > > disruption. > > > > OK, this is really interesting. I was really worried to change the > > semantic of the mmu notifiers in stable kernels because this is really > > a hard to review change and high risk for anybody running those old > > kernels. If we can keep the mmu_notifier_invalidate_page and wrap them > > into the range scope API then this sounds like the best way forward. > > > > So just to make sure we are at the same page. Does this sounds goo for > > stable 4.4. backport? Mike's hugetlb pmd shared fixup can be applied on > > top. What do you think? > > >>> > > >>> You need to invalidate outside page table lock so before the call to > > >>> page_check_address(). For instance like below patch, which also only > > >>> do the range invalidation for huge page which would avoid too much of > > >>> a behavior change for user of mmu notifier. > > >> > > >> Right. I would rather not make this PageHuge special though. So the > > >> fixed version should be. > > > > > > Why not testing for huge ? Only huge is broken and thus only that > > > need the extra range invalidation. Doing the double invalidation > > > for single page is bit overkill. > > > > I am a bit confused, and hope this does not add to any confusion by others. > > > > IIUC, the patch below does not attempt to 'fix' anything. It is simply > > there to add the start/end notifiers to the v4.4 version of this routine > > so that a subsequent patch can use them (with modified ranges) to handle > > unmapping a shared pmd huge page. That is the mainline fix which started > > this thread. > > > > Since we are only/mostly interested in fixing the shared pmd issue in > > 4.4, how about just adding the start/end notifiers to the very specific > > case where pmd sharing is possible? > > > > I can see the value in trying to back port dependent patches such as this > > so that stable releases look more like mainline. However, I am not sure of > > the value in this case as this patch was part of a larger set changing > > notifier semantics. > > For all intents and purposes this is not a backport of the original > patch so maybe we should just drop the commit reference and just > explains that it is there to fix mmu notifier in respect to huge page > migration. > > The original patches fix more than this case because newer featurers > like THP migration, THP swapping, ... added more cases where things > would have been
Re: [PATCH 2/5] gpio: davinci: Use dev name for label and automatic base selection
On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote:
> Use dev_name to get a unique label and use -1 for a base to get our
> selection automatically. We pull in all GPIOs per chip now so this
> does not have the effect of out of order labels like before.
>
> We do these both together so we can drop all the static data in one
> patch. This also lets us normalize the return paths as we don't need
> any cleanup after this change.
echo 28 > /sys/class/gpio/export
/ # echo 28 > /sys/class/gpi[ 12.839205] export_store: invalid GPIO 28
o/export
echo 2 > /sys/class/gp[ 22.165728] export_store: invalid GPIO 2
io/export
/ # echo 1 > /sys/class/gp[ 25.961392] export_store: invalid GPIO 1
io/export
/ # echo 3 > /sys/class/gp[ 29.981918] export_store: invalid GPIO 3
io/export
Export fails with this patch. I am testing this on keystone-k2g-evm.
>
> Signed-off-by: Andrew F. Davis
> ---
> drivers/gpio/gpio-davinci.c | 22 --
> 1 file changed, 4 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index a5ece8ea79bc..14d1729927d3 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> @@ -41,7 +41,6 @@ struct davinci_gpio_regs {
> typedef struct irq_chip *(*gpio_get_irq_chip_cb_t)(unsigned int irq);
>
> #define BINTEN 0x8 /* GPIO Interrupt Per-Bank Enable Register */
> -#define MAX_LABEL_SIZE 20
>
> static void __iomem *gpio_base;
> static unsigned int offset_array[5] = {0x10, 0x38, 0x60, 0x88, 0xb0};
> @@ -166,14 +165,12 @@ davinci_gpio_get_pdata(struct platform_device *pdev)
>
> static int davinci_gpio_probe(struct platform_device *pdev)
> {
> - static int ctrl_num, bank_base;
> int gpio, bank, i, ret = 0;
> unsigned int ngpio, nbank, nirq;
> struct davinci_gpio_controller *chips;
> struct davinci_gpio_platform_data *pdata;
> struct device *dev = >dev;
> struct resource *res;
> - char label[MAX_LABEL_SIZE];
>
> pdata = davinci_gpio_get_pdata(pdev);
> if (!pdata) {
> @@ -228,10 +225,7 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> }
> }
>
> - snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
> - chips->chip.label = devm_kstrdup(dev, label, GFP_KERNEL);
> - if (!chips->chip.label)
> - return -ENOMEM;
> + chips->chip.label = dev_name(dev);
>
> chips->chip.direction_input = davinci_direction_in;
> chips->chip.get = davinci_gpio_get;
> @@ -239,7 +233,7 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> chips->chip.set = davinci_gpio_set;
>
> chips->chip.ngpio = ngpio;
> - chips->chip.base = bank_base;
> + chips->chip.base = -1;
>
> #ifdef CONFIG_OF_GPIO
> chips->chip.of_gpio_n_cells = 2;
> @@ -252,28 +246,20 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> }
> #endif
> spin_lock_init(>lock);
> - bank_base += ngpio;
>
> for (gpio = 0, bank = 0; gpio < ngpio; gpio += 32, bank++)
> chips->regs[bank] = gpio_base + offset_array[bank];
>
> ret = devm_gpiochip_add_data(dev, >chip, chips);
> if (ret)
> - goto err;
> + return ret;
>
> platform_set_drvdata(pdev, chips);
> ret = davinci_gpio_irq_setup(pdev);
> if (ret)
> - goto err;
> + return ret;
>
> return 0;
> -
> -err:
> - /* Revert the static variable increments */
> - ctrl_num--;
> - bank_base -= ngpio;
> -
> - return ret;
> }
>
>
> /*--*/
>
Re: [PATCH 2/5] gpio: davinci: Use dev name for label and automatic base selection
On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote:
> Use dev_name to get a unique label and use -1 for a base to get our
> selection automatically. We pull in all GPIOs per chip now so this
> does not have the effect of out of order labels like before.
>
> We do these both together so we can drop all the static data in one
> patch. This also lets us normalize the return paths as we don't need
> any cleanup after this change.
echo 28 > /sys/class/gpio/export
/ # echo 28 > /sys/class/gpi[ 12.839205] export_store: invalid GPIO 28
o/export
echo 2 > /sys/class/gp[ 22.165728] export_store: invalid GPIO 2
io/export
/ # echo 1 > /sys/class/gp[ 25.961392] export_store: invalid GPIO 1
io/export
/ # echo 3 > /sys/class/gp[ 29.981918] export_store: invalid GPIO 3
io/export
Export fails with this patch. I am testing this on keystone-k2g-evm.
>
> Signed-off-by: Andrew F. Davis
> ---
> drivers/gpio/gpio-davinci.c | 22 --
> 1 file changed, 4 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index a5ece8ea79bc..14d1729927d3 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> @@ -41,7 +41,6 @@ struct davinci_gpio_regs {
> typedef struct irq_chip *(*gpio_get_irq_chip_cb_t)(unsigned int irq);
>
> #define BINTEN 0x8 /* GPIO Interrupt Per-Bank Enable Register */
> -#define MAX_LABEL_SIZE 20
>
> static void __iomem *gpio_base;
> static unsigned int offset_array[5] = {0x10, 0x38, 0x60, 0x88, 0xb0};
> @@ -166,14 +165,12 @@ davinci_gpio_get_pdata(struct platform_device *pdev)
>
> static int davinci_gpio_probe(struct platform_device *pdev)
> {
> - static int ctrl_num, bank_base;
> int gpio, bank, i, ret = 0;
> unsigned int ngpio, nbank, nirq;
> struct davinci_gpio_controller *chips;
> struct davinci_gpio_platform_data *pdata;
> struct device *dev = >dev;
> struct resource *res;
> - char label[MAX_LABEL_SIZE];
>
> pdata = davinci_gpio_get_pdata(pdev);
> if (!pdata) {
> @@ -228,10 +225,7 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> }
> }
>
> - snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
> - chips->chip.label = devm_kstrdup(dev, label, GFP_KERNEL);
> - if (!chips->chip.label)
> - return -ENOMEM;
> + chips->chip.label = dev_name(dev);
>
> chips->chip.direction_input = davinci_direction_in;
> chips->chip.get = davinci_gpio_get;
> @@ -239,7 +233,7 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> chips->chip.set = davinci_gpio_set;
>
> chips->chip.ngpio = ngpio;
> - chips->chip.base = bank_base;
> + chips->chip.base = -1;
>
> #ifdef CONFIG_OF_GPIO
> chips->chip.of_gpio_n_cells = 2;
> @@ -252,28 +246,20 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> }
> #endif
> spin_lock_init(>lock);
> - bank_base += ngpio;
>
> for (gpio = 0, bank = 0; gpio < ngpio; gpio += 32, bank++)
> chips->regs[bank] = gpio_base + offset_array[bank];
>
> ret = devm_gpiochip_add_data(dev, >chip, chips);
> if (ret)
> - goto err;
> + return ret;
>
> platform_set_drvdata(pdev, chips);
> ret = davinci_gpio_irq_setup(pdev);
> if (ret)
> - goto err;
> + return ret;
>
> return 0;
> -
> -err:
> - /* Revert the static variable increments */
> - ctrl_num--;
> - bank_base -= ngpio;
> -
> - return ret;
> }
>
>
> /*--*/
>
Re: Access to non-RAM pages
On 03/09/18 04:10, Linus Torvalds wrote: > So _practically_ this is just a Xen bug, nothing more. > > But since in _theory_ you could have MMIO abut regular RAM directly, > it's worth maybe making sure it's purely theory. And that was exactly the reason I brought it up. :-) Juergen
Re: Access to non-RAM pages
On 03/09/18 04:10, Linus Torvalds wrote: > So _practically_ this is just a Xen bug, nothing more. > > But since in _theory_ you could have MMIO abut regular RAM directly, > it's worth maybe making sure it's purely theory. And that was exactly the reason I brought it up. :-) Juergen
Re: [PATCH 1/2] ARM: dts: imx6: RDU2: Fix the audio CODEC's reset pin
On Fri, Aug 31, 2018 at 02:17:31PM -0500, Andrew F. Davis wrote:
> The correct DT property for specifying a GPIO used for reset
> is "reset-gpios", fix this here.
>
> Fixes: d763762e3b58 ("ARM: dts: imx6: add ZII RDU2 boards")
This Fixes tag and word 'Fix' in subject is inappropriate to me, as you
are not fixing something wrong from the beginning, but actually
replacing a deprecated property with new one.
Shawn
>
> Signed-off-by: Andrew F. Davis
> ---
> arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> index 7fff3717cf7c..a0f5cfda0055 100644
> --- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> @@ -384,7 +384,7 @@
> AVDD-supply = <_3p3v>;
> IOVDD-supply = <_3p3v>;
> DVDD-supply = <_reg>;
> - gpio-reset = < 2 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 2 GPIO_ACTIVE_LOW>;
> };
>
> accel@1c {
> @@ -572,7 +572,7 @@
> AVDD-supply = <_3p3v>;
> IOVDD-supply = <_3p3v>;
> DVDD-supply = <_reg>;
> - gpio-reset = < 0 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 0 GPIO_ACTIVE_LOW>;
> };
>
> touchscreen@20 {
> --
> 2.18.0
>
Re: [PATCH 1/2] ARM: dts: imx6: RDU2: Fix the audio CODEC's reset pin
On Fri, Aug 31, 2018 at 02:17:31PM -0500, Andrew F. Davis wrote:
> The correct DT property for specifying a GPIO used for reset
> is "reset-gpios", fix this here.
>
> Fixes: d763762e3b58 ("ARM: dts: imx6: add ZII RDU2 boards")
This Fixes tag and word 'Fix' in subject is inappropriate to me, as you
are not fixing something wrong from the beginning, but actually
replacing a deprecated property with new one.
Shawn
>
> Signed-off-by: Andrew F. Davis
> ---
> arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> index 7fff3717cf7c..a0f5cfda0055 100644
> --- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> @@ -384,7 +384,7 @@
> AVDD-supply = <_3p3v>;
> IOVDD-supply = <_3p3v>;
> DVDD-supply = <_reg>;
> - gpio-reset = < 2 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 2 GPIO_ACTIVE_LOW>;
> };
>
> accel@1c {
> @@ -572,7 +572,7 @@
> AVDD-supply = <_3p3v>;
> IOVDD-supply = <_3p3v>;
> DVDD-supply = <_reg>;
> - gpio-reset = < 0 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 0 GPIO_ACTIVE_LOW>;
> };
>
> touchscreen@20 {
> --
> 2.18.0
>
Re: [PATCH v2] fs: Convert return type int to vm_fault_t
On Thu, Aug 30, 2018 at 10:55:47PM +0530, Souptick Joarder wrote: > +vm_fault_t block_page_mkwrite(struct vm_area_struct *vma, struct vm_fault > *vmf, > + get_block_t get_block, int *err) I don't like returning both the errno and the vm_fault_t. To me that's a sign we need to rethink this interface. I have two suggestions. First, we could allocate a new VM_FAULT_NOSPC bit. Second, we could repurpose one of the existing bits, such as VM_FAULT_RETRY for this purpose. > -int ext4_page_mkwrite(struct vm_fault *vmf) > +vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf) I also think perhaps we could start by _not_ converting block_page_mkwrite(). Just convert ext4_page_mkwrite(), and save converting block_page_mkwrite() for later.
Re: [PATCH v2] fs: Convert return type int to vm_fault_t
On Thu, Aug 30, 2018 at 10:55:47PM +0530, Souptick Joarder wrote: > +vm_fault_t block_page_mkwrite(struct vm_area_struct *vma, struct vm_fault > *vmf, > + get_block_t get_block, int *err) I don't like returning both the errno and the vm_fault_t. To me that's a sign we need to rethink this interface. I have two suggestions. First, we could allocate a new VM_FAULT_NOSPC bit. Second, we could repurpose one of the existing bits, such as VM_FAULT_RETRY for this purpose. > -int ext4_page_mkwrite(struct vm_fault *vmf) > +vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf) I also think perhaps we could start by _not_ converting block_page_mkwrite(). Just convert ext4_page_mkwrite(), and save converting block_page_mkwrite() for later.
Re: [PATCH v2] perf: Fix clean error
Just find out that da15fc2fa9c07b23db8f5e479bd8a9f0d741ca07 (introduced in v4.19-rc1) already fixes the issue by specifying -j1 on make clean. So this commit is not needed anymore, though I think it does fix the root cause. But if we do want parallel clean, we could revert that and merge this commit. On Mon, Sep 3, 2018 at 10:50 AM Lei YU wrote: > > When make perf with -O, it gets error when make clean with below log: > > $ make -C tools/perf O= # OK > $ make -C tools/perf O= clean # Got below error > > find: cannot delete ‘/builtin-script.o’: No such file or > directory > find: cannot delete ‘/.subcmd-config.o.cmd’: No such file or > directory > ... > Makefile:38: recipe for target 'clean' failed > make[2]: *** [clean] Error 1 > make[1]: *** [fixdep-clean] Error 2 > Makefile:90: recipe for target 'clean' failed > make: *** [clean] Error 2 > > It happens because both fixdep-clean and libsubcmd-clean will delete > files by `find`, where libsubcmd-clean uses `| xargs $(RM)` and > fixdep-clean uses `-delete`. > When a file is find by fixdep-clean, and tries to delete it, it's found > that the file does not exist because it is deleted by libsubcmd-clean. > > This commit changes the delete method of fixdep-clean to use > `| xargs $(RM)` as well, where RM is defined as `rm -f` so it does not > return error when file does not exist. > > Signed-off-by: Lei YU > > --- > v2: Fix missing "make clean" in commit message > --- > tools/build/Makefile | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/tools/build/Makefile b/tools/build/Makefile > index 5edf65e..ae38db2 100644 > --- a/tools/build/Makefile > +++ b/tools/build/Makefile > @@ -18,6 +18,7 @@ $(call allow-override,LD,$(CROSS_COMPILE)ld) > HOSTCC ?= gcc > HOSTLD ?= ld > HOSTAR ?= ar > +RM = rm -f > > export HOSTCC HOSTLD HOSTAR > > @@ -36,7 +37,7 @@ all: $(OUTPUT)fixdep > > clean: > $(call QUIET_CLEAN, fixdep) > - $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -delete -o -name > '\.*.cmd' -delete -o -name '\.*.d' -delete > + $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -o -name '\.*.cmd' > -o -name '\.*.d' | xargs $(RM) > $(Q)rm -f $(OUTPUT)fixdep > > $(OUTPUT)fixdep-in.o: FORCE > -- > 2.7.4 >
Re: [PATCH v2] perf: Fix clean error
Just find out that da15fc2fa9c07b23db8f5e479bd8a9f0d741ca07 (introduced in v4.19-rc1) already fixes the issue by specifying -j1 on make clean. So this commit is not needed anymore, though I think it does fix the root cause. But if we do want parallel clean, we could revert that and merge this commit. On Mon, Sep 3, 2018 at 10:50 AM Lei YU wrote: > > When make perf with -O, it gets error when make clean with below log: > > $ make -C tools/perf O= # OK > $ make -C tools/perf O= clean # Got below error > > find: cannot delete ‘/builtin-script.o’: No such file or > directory > find: cannot delete ‘/.subcmd-config.o.cmd’: No such file or > directory > ... > Makefile:38: recipe for target 'clean' failed > make[2]: *** [clean] Error 1 > make[1]: *** [fixdep-clean] Error 2 > Makefile:90: recipe for target 'clean' failed > make: *** [clean] Error 2 > > It happens because both fixdep-clean and libsubcmd-clean will delete > files by `find`, where libsubcmd-clean uses `| xargs $(RM)` and > fixdep-clean uses `-delete`. > When a file is find by fixdep-clean, and tries to delete it, it's found > that the file does not exist because it is deleted by libsubcmd-clean. > > This commit changes the delete method of fixdep-clean to use > `| xargs $(RM)` as well, where RM is defined as `rm -f` so it does not > return error when file does not exist. > > Signed-off-by: Lei YU > > --- > v2: Fix missing "make clean" in commit message > --- > tools/build/Makefile | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/tools/build/Makefile b/tools/build/Makefile > index 5edf65e..ae38db2 100644 > --- a/tools/build/Makefile > +++ b/tools/build/Makefile > @@ -18,6 +18,7 @@ $(call allow-override,LD,$(CROSS_COMPILE)ld) > HOSTCC ?= gcc > HOSTLD ?= ld > HOSTAR ?= ar > +RM = rm -f > > export HOSTCC HOSTLD HOSTAR > > @@ -36,7 +37,7 @@ all: $(OUTPUT)fixdep > > clean: > $(call QUIET_CLEAN, fixdep) > - $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -delete -o -name > '\.*.cmd' -delete -o -name '\.*.d' -delete > + $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -o -name '\.*.cmd' > -o -name '\.*.d' | xargs $(RM) > $(Q)rm -f $(OUTPUT)fixdep > > $(OUTPUT)fixdep-in.o: FORCE > -- > 2.7.4 >
Re: [PATCH V2] ARM: dts: imx7s: enable cpuidle driver
On Mon, Sep 03, 2018 at 09:45:41AM +0800, Anson Huang wrote: > Enable cpuidle for i.MX7S/D using generic ARM cpuidle > driver, below 2 idle states enabled: > > 1. ARM WFI; > 2. SoC WAIT mode. > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH V2] ARM: dts: imx7s: enable cpuidle driver
On Mon, Sep 03, 2018 at 09:45:41AM +0800, Anson Huang wrote: > Enable cpuidle for i.MX7S/D using generic ARM cpuidle > driver, below 2 idle states enabled: > > 1. ARM WFI; > 2. SoC WAIT mode. > > Signed-off-by: Anson Huang Applied, thanks.
RE: [PATCH 1/7] spi: add slave device size in spi_device struct
Hi Lothar, > -Original Message- > From: Lothar Waßmann [mailto:l...@karo-electronics.de] > Sent: Friday, August 31, 2018 5:28 PM > To: Yogesh Narayan Gaur > Cc: linux-...@lists.infradead.org; boris.brezil...@bootlin.com; > marek.va...@gmail.com; linux-...@vger.kernel.org; > devicet...@vger.kernel.org; mark.rutl...@arm.com; r...@kernel.org; linux- > ker...@vger.kernel.org; frieder.schre...@exceet.de; > computersforpe...@gmail.com; shawn...@kernel.org; linux-arm- > ker...@lists.infradead.org > Subject: Re: [PATCH 1/7] spi: add slave device size in spi_device struct > > Hi, > > On Fri, 31 Aug 2018 15:59:58 +0530 Yogesh Gaur wrote: > > Add 'size' data variable in spi_device struct. > > This is to save the size of the connected slave device. > > > > After slave device scan, spi_nor_scan, size being assigned to this > > from MTD layer. > > > > SFDP read is being requested before completion of spi_nor_scan() > > routine, thus populate device size before making read request to the > > SPI controller. > > > > Signed-off-by: Yogesh Gaur > > --- > > drivers/mtd/devices/m25p80.c | 6 ++ > > drivers/mtd/spi-nor/spi-nor.c | 2 ++ > > include/linux/spi/spi.h | 2 ++ > > 3 files changed, 10 insertions(+) > > > > diff --git a/drivers/mtd/devices/m25p80.c > > b/drivers/mtd/devices/m25p80.c index fe260cc..6c7ad86 100644 > > --- a/drivers/mtd/devices/m25p80.c > > +++ b/drivers/mtd/devices/m25p80.c > > @@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, > loff_t from, size_t len, > > /* convert the dummy cycles to the number of bytes */ > > op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8; > > > > + /* for case of SFDP header read commands, populate spi device size */ > > + if (flash->spimem->spi->size == 0) > > + flash->spimem->spi->size = nor->mtd.size; > > + > If the 'size' is an spimem specific variable it should be added to the spi_mem > struct rather than the spi_device struct. Sure, would move 'size' from struct spi_device to the struct spi_mem. -- Regards Yogesh Gaur. > > Lothar Waßmann
RE: [PATCH 1/7] spi: add slave device size in spi_device struct
Hi Lothar, > -Original Message- > From: Lothar Waßmann [mailto:l...@karo-electronics.de] > Sent: Friday, August 31, 2018 5:28 PM > To: Yogesh Narayan Gaur > Cc: linux-...@lists.infradead.org; boris.brezil...@bootlin.com; > marek.va...@gmail.com; linux-...@vger.kernel.org; > devicet...@vger.kernel.org; mark.rutl...@arm.com; r...@kernel.org; linux- > ker...@vger.kernel.org; frieder.schre...@exceet.de; > computersforpe...@gmail.com; shawn...@kernel.org; linux-arm- > ker...@lists.infradead.org > Subject: Re: [PATCH 1/7] spi: add slave device size in spi_device struct > > Hi, > > On Fri, 31 Aug 2018 15:59:58 +0530 Yogesh Gaur wrote: > > Add 'size' data variable in spi_device struct. > > This is to save the size of the connected slave device. > > > > After slave device scan, spi_nor_scan, size being assigned to this > > from MTD layer. > > > > SFDP read is being requested before completion of spi_nor_scan() > > routine, thus populate device size before making read request to the > > SPI controller. > > > > Signed-off-by: Yogesh Gaur > > --- > > drivers/mtd/devices/m25p80.c | 6 ++ > > drivers/mtd/spi-nor/spi-nor.c | 2 ++ > > include/linux/spi/spi.h | 2 ++ > > 3 files changed, 10 insertions(+) > > > > diff --git a/drivers/mtd/devices/m25p80.c > > b/drivers/mtd/devices/m25p80.c index fe260cc..6c7ad86 100644 > > --- a/drivers/mtd/devices/m25p80.c > > +++ b/drivers/mtd/devices/m25p80.c > > @@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, > loff_t from, size_t len, > > /* convert the dummy cycles to the number of bytes */ > > op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8; > > > > + /* for case of SFDP header read commands, populate spi device size */ > > + if (flash->spimem->spi->size == 0) > > + flash->spimem->spi->size = nor->mtd.size; > > + > If the 'size' is an spimem specific variable it should be added to the spi_mem > struct rather than the spi_device struct. Sure, would move 'size' from struct spi_device to the struct spi_mem. -- Regards Yogesh Gaur. > > Lothar Waßmann
Re: [PATCH v3] sched/pelt: fix update_blocked_averages() for dl and rt
On 08/31/2018 08:22 AM, Vincent Guittot wrote:
update_blocked_averages() is called to periodiccally decay the stalled load
of idle CPUs and to sync all loads before running load balance.
When cfs rq is idle, it trigs a load balance during pick_next_task_fair()
in order to potentially pull tasks and to use this newly idle CPU. This
load balance happens whereas prev task from another class has not been put
and its utilization updated yet. This may lead to wrongly account running
time as idle time for rt or dl classes.
Test that no rt or dl task is running when updating their utilization in
update_blocked_averages().
Shouldn't this be 's/that no/if an' ?
You still update the utilization of the rt or dl task if they are
running (accrue + decay) instead of only decay. Similar to the
'cfs_rq->curr != NULL' in __update_load_avg_cfs_rq().
We still update rt and dl utilization instead of simply skipping them to
make sure that all metrics are synced when used during load balance.
I assume this sentence is indirectly saying this.
Fixes: 371bf4273269 ("sched/rt: Add rt_rq utilization tracking")
Fixes: 3727e0e16340 ("sched/dl: Add dl_rq utilization tracking")
Signed-off-by: Vincent Guittot
---
-V3
- move rq->curr dereference under the rq->lock
-V2
- Add missing fixes tags
- apply fix to other version of update_blocked_averages
kernel/sched/fair.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 309c93f..53bbcd4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7262,6 +7262,7 @@ static void update_blocked_averages(int cpu)
{
struct rq *rq = cpu_rq(cpu);
struct cfs_rq *cfs_rq, *pos;
+ const struct sched_class *curr_class;
struct rq_flags rf;
bool done = true;
@@ -7298,8 +7299,10 @@ static void update_blocked_averages(int cpu)
if (cfs_rq_has_blocked(cfs_rq))
done = false;
}
- update_rt_rq_load_avg(rq_clock_task(rq), rq, 0);
- update_dl_rq_load_avg(rq_clock_task(rq), rq, 0);
+
+ curr_class = rq->curr->sched_class;
+ update_rt_rq_load_avg(rq_clock_task(rq), rq, curr_class ==
_sched_class);
+ update_dl_rq_load_avg(rq_clock_task(rq), rq, curr_class ==
_sched_class);
update_irq_load_avg(rq, 0);
/* Don't need periodic decay once load/util_avg are null */
if (others_have_blocked(rq))
@@ -7364,13 +7367,16 @@ static inline void update_blocked_averages(int cpu)
{
struct rq *rq = cpu_rq(cpu);
struct cfs_rq *cfs_rq = >cfs;
+ const struct sched_class *curr_class;
struct rq_flags rf;
rq_lock_irqsave(rq, );
update_rq_clock(rq);
update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq);
- update_rt_rq_load_avg(rq_clock_task(rq), rq, 0);
- update_dl_rq_load_avg(rq_clock_task(rq), rq, 0);
+
+ curr_class = rq->curr->sched_class;
+ update_rt_rq_load_avg(rq_clock_task(rq), rq, curr_class ==
_sched_class);
+ update_dl_rq_load_avg(rq_clock_task(rq), rq, curr_class ==
_sched_class);
update_irq_load_avg(rq, 0);
#ifdef CONFIG_NO_HZ_COMMON
rq->last_blocked_load_update_tick = jiffies;
Re: [PATCH v3] sched/pelt: fix update_blocked_averages() for dl and rt
On 08/31/2018 08:22 AM, Vincent Guittot wrote:
update_blocked_averages() is called to periodiccally decay the stalled load
of idle CPUs and to sync all loads before running load balance.
When cfs rq is idle, it trigs a load balance during pick_next_task_fair()
in order to potentially pull tasks and to use this newly idle CPU. This
load balance happens whereas prev task from another class has not been put
and its utilization updated yet. This may lead to wrongly account running
time as idle time for rt or dl classes.
Test that no rt or dl task is running when updating their utilization in
update_blocked_averages().
Shouldn't this be 's/that no/if an' ?
You still update the utilization of the rt or dl task if they are
running (accrue + decay) instead of only decay. Similar to the
'cfs_rq->curr != NULL' in __update_load_avg_cfs_rq().
We still update rt and dl utilization instead of simply skipping them to
make sure that all metrics are synced when used during load balance.
I assume this sentence is indirectly saying this.
Fixes: 371bf4273269 ("sched/rt: Add rt_rq utilization tracking")
Fixes: 3727e0e16340 ("sched/dl: Add dl_rq utilization tracking")
Signed-off-by: Vincent Guittot
---
-V3
- move rq->curr dereference under the rq->lock
-V2
- Add missing fixes tags
- apply fix to other version of update_blocked_averages
kernel/sched/fair.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 309c93f..53bbcd4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7262,6 +7262,7 @@ static void update_blocked_averages(int cpu)
{
struct rq *rq = cpu_rq(cpu);
struct cfs_rq *cfs_rq, *pos;
+ const struct sched_class *curr_class;
struct rq_flags rf;
bool done = true;
@@ -7298,8 +7299,10 @@ static void update_blocked_averages(int cpu)
if (cfs_rq_has_blocked(cfs_rq))
done = false;
}
- update_rt_rq_load_avg(rq_clock_task(rq), rq, 0);
- update_dl_rq_load_avg(rq_clock_task(rq), rq, 0);
+
+ curr_class = rq->curr->sched_class;
+ update_rt_rq_load_avg(rq_clock_task(rq), rq, curr_class ==
_sched_class);
+ update_dl_rq_load_avg(rq_clock_task(rq), rq, curr_class ==
_sched_class);
update_irq_load_avg(rq, 0);
/* Don't need periodic decay once load/util_avg are null */
if (others_have_blocked(rq))
@@ -7364,13 +7367,16 @@ static inline void update_blocked_averages(int cpu)
{
struct rq *rq = cpu_rq(cpu);
struct cfs_rq *cfs_rq = >cfs;
+ const struct sched_class *curr_class;
struct rq_flags rf;
rq_lock_irqsave(rq, );
update_rq_clock(rq);
update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq);
- update_rt_rq_load_avg(rq_clock_task(rq), rq, 0);
- update_dl_rq_load_avg(rq_clock_task(rq), rq, 0);
+
+ curr_class = rq->curr->sched_class;
+ update_rt_rq_load_avg(rq_clock_task(rq), rq, curr_class ==
_sched_class);
+ update_dl_rq_load_avg(rq_clock_task(rq), rq, curr_class ==
_sched_class);
update_irq_load_avg(rq, 0);
#ifdef CONFIG_NO_HZ_COMMON
rq->last_blocked_load_update_tick = jiffies;
Re: [PATCH] sched/fair: fix vruntime_normalized for remote non-migration wakeup
On 08/31/2018 03:42 PM, Steve Muckle wrote: When a task which previously ran on a given CPU is remotely queued to wake up on that same CPU, there is a period where the task's state is TASK_WAKING and its vruntime is not normalized. This is not accounted for in vruntime_normalized() which will cause an error in the task's vruntime if it is switched from the fair class during this time, for example if it is boosted to RT priority via rt_mutex_setprio. The rq's min_vruntime will not be subtracted from the task's vruntime but it will be added again when the task returns to the fair class. The task's vruntime will have been erroneously doubled and the effective priority of the task will be reduced. Note this will also lead to inflation of all vruntimes since the doubled vruntime value will become the rq's min_vruntime when other tasks leave the rq. This leads to repeated doubling of the vruntime and priority penalty. Fix this by recognizing a WAKING task's vruntime as normalized only if sched_remote_wakeup is true. This indicates a migration, in which case the vruntime would have been normalized in migrate_task_rq_fair(). Based on a similar patch from joaod...@google.com. Suggested-by: Peter Zijlstra Signed-off-by: Steve Muckle --- kernel/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index b39fb596f6c1..b3b62cf37fb6 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -9638,7 +9638,8 @@ static inline bool vruntime_normalized(struct task_struct *p) * - A task which has been woken up by try_to_wake_up() and * waiting for actually being woken up by sched_ttwu_pending(). */ - if (!se->sum_exec_runtime || p->state == TASK_WAKING) + if (!se->sum_exec_runtime || + (p->state == TASK_WAKING && p->sched_remote_wakeup)) return true; return false; Tested-by: Dietmar Eggemann
Re: [PATCH] sched/fair: fix vruntime_normalized for remote non-migration wakeup
On 08/31/2018 03:42 PM, Steve Muckle wrote: When a task which previously ran on a given CPU is remotely queued to wake up on that same CPU, there is a period where the task's state is TASK_WAKING and its vruntime is not normalized. This is not accounted for in vruntime_normalized() which will cause an error in the task's vruntime if it is switched from the fair class during this time, for example if it is boosted to RT priority via rt_mutex_setprio. The rq's min_vruntime will not be subtracted from the task's vruntime but it will be added again when the task returns to the fair class. The task's vruntime will have been erroneously doubled and the effective priority of the task will be reduced. Note this will also lead to inflation of all vruntimes since the doubled vruntime value will become the rq's min_vruntime when other tasks leave the rq. This leads to repeated doubling of the vruntime and priority penalty. Fix this by recognizing a WAKING task's vruntime as normalized only if sched_remote_wakeup is true. This indicates a migration, in which case the vruntime would have been normalized in migrate_task_rq_fair(). Based on a similar patch from joaod...@google.com. Suggested-by: Peter Zijlstra Signed-off-by: Steve Muckle --- kernel/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index b39fb596f6c1..b3b62cf37fb6 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -9638,7 +9638,8 @@ static inline bool vruntime_normalized(struct task_struct *p) * - A task which has been woken up by try_to_wake_up() and * waiting for actually being woken up by sched_ttwu_pending(). */ - if (!se->sum_exec_runtime || p->state == TASK_WAKING) + if (!se->sum_exec_runtime || + (p->state == TASK_WAKING && p->sched_remote_wakeup)) return true; return false; Tested-by: Dietmar Eggemann
Re: [PATCH] bus: imx-weim: drop unnecessary DT node name NULL check
On Wed, Aug 29, 2018 at 03:02:58PM -0500, Rob Herring wrote: > Checking the child node names is pointless as the DT node name can > never be NULL, so remove it. > > Cc: Shawn Guo > Signed-off-by: Rob Herring Applied, thanks.
Re: [PATCH] bus: imx-weim: drop unnecessary DT node name NULL check
On Wed, Aug 29, 2018 at 03:02:58PM -0500, Rob Herring wrote: > Checking the child node names is pointless as the DT node name can > never be NULL, so remove it. > > Cc: Shawn Guo > Signed-off-by: Rob Herring Applied, thanks.
INQUIRY ORDER
Dear Supplier, Please kindly confirm back in reply if am onto the right contact personin your company responsible for inquiries & orders. Please can you as well send your updated 2018 product catalog/price listing to our Import Department desk. Regards Walter Benson Purchase Manager Aharkco Trading Co., LTD.
INQUIRY ORDER
Dear Supplier, Please kindly confirm back in reply if am onto the right contact personin your company responsible for inquiries & orders. Please can you as well send your updated 2018 product catalog/price listing to our Import Department desk. Regards Walter Benson Purchase Manager Aharkco Trading Co., LTD.
Re: Access to non-RAM pages
On Sun, 2018-09-02 at 19:52 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:47 PM Linus Torvalds
> wrote:
> >
> > The comment actually does talk about it, although the comment also
> > claims that the cs read would use load_unaligned_zeropad(), which it
> > no longer does (now it only does the read_word_at_a_time).
>
> IOW, look at commit 12f8ad4b0533 ("vfs: clean up __d_lookup_rcu() and
> dentry_cmp() interfaces") for why the zeropad went away for the cs
> access (but the comment wasn't updated).
>
> And then bfe7aa6c39b1 ("fs/dcache: Use read_word_at_a_time() in
> dentry_string_cmp()") did the "let's make KASAN happy thing.
>
> And yes, the word-at-a-time code actually matters a lot for certain
> loads. The "copy-and-hash" thing for path components ends up being
> pretty critical in all the pathname handling.
Yup, makes sense.
Thanks !
Cheers,
Ben.
Re: Access to non-RAM pages
On Sun, 2018-09-02 at 19:52 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:47 PM Linus Torvalds
> wrote:
> >
> > The comment actually does talk about it, although the comment also
> > claims that the cs read would use load_unaligned_zeropad(), which it
> > no longer does (now it only does the read_word_at_a_time).
>
> IOW, look at commit 12f8ad4b0533 ("vfs: clean up __d_lookup_rcu() and
> dentry_cmp() interfaces") for why the zeropad went away for the cs
> access (but the comment wasn't updated).
>
> And then bfe7aa6c39b1 ("fs/dcache: Use read_word_at_a_time() in
> dentry_string_cmp()") did the "let's make KASAN happy thing.
>
> And yes, the word-at-a-time code actually matters a lot for certain
> loads. The "copy-and-hash" thing for path components ends up being
> pretty critical in all the pathname handling.
Yup, makes sense.
Thanks !
Cheers,
Ben.
Re: [BUGFIX PATCH -tip] kprobes/x86: Fix to copy RIP relative instruction correctly
Hi Ingo,
Could you pick this fix to urgent branch?
Thank you,
On Fri, 24 Aug 2018 16:57:19 +0900
Masami Hiramatsu wrote:
> On Thu, 23 Aug 2018 21:41:09 -0400
> Steven Rostedt wrote:
>
> > On Fri, 24 Aug 2018 02:16:12 +0900
> > Masami Hiramatsu wrote:
> >
> > > Dump of assembler code from 0xa000207a to 0xa00020ea:
> > > 54 push %rsp
> > > ...
> > > 48 83 c4 08 add$0x8,%rsp
> > > 9d popfq
> > > 48 89 f0mov%rsi,%rax
> > > 8b 35 82 7d db e2 mov-0x1d24827e(%rip),%esi
> > > # 0x82db9e67
> > >
> > > As it shows, the 2nd mov accesses *(nr_cpu_ids+3) instead of
> > > *nr_cpu_ids. This leads a kernel freeze because cpumask_next()
> > > always returns 0 and for_each_cpu() never ended.
> >
> > Ouch! Nice catch.
> >
> > >
> > > Fixing this by adding len correctly to real RIP address while
> > > copying.
> > >
> > > Fixes: 63fef14fc98a ("kprobes/x86: Make insn buffer always ROX and use
> > > text_poke()")
> > > Reported-by: Michael Rodin
> > > Signed-off-by: Masami Hiramatsu
> > > Cc: sta...@vger.kernel.org
> > > ---
> > > arch/x86/kernel/kprobes/opt.c |3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
> > > index eaf02f2e7300..e92672b8b490 100644
> > > --- a/arch/x86/kernel/kprobes/opt.c
> > > +++ b/arch/x86/kernel/kprobes/opt.c
> > > @@ -189,7 +189,8 @@ static int copy_optimized_instructions(u8 *dest, u8
> > > *src, u8 *real)
> > > int len = 0, ret;
> > >
> > > while (len < RELATIVEJUMP_SIZE) {
> > > - ret = __copy_instruction(dest + len, src + len, real, );
> > > + ret = __copy_instruction(dest + len, src + len, real + len,
> > > + );
> > > if (!ret || !can_boost(, src + len))
> > > return -EINVAL;
> > > len += ret;
> >
> > Looking at the change that broke this we have:
> >
> > > -static int copy_optimized_instructions(u8 *dest, u8 *src)
> > > +static int copy_optimized_instructions(u8 *dest, u8 *src, u8 *real)
> > > {
> > > struct insn insn;
> > > int len = 0, ret;
> > >
> > > while (len < RELATIVEJUMP_SIZE) {
> > > - ret = __copy_instruction(dest + len, src + len, );
> > > + ret = __copy_instruction(dest + len, src + len, real,
> > > );
> >
> > Where "real" was added as a parameter to __copy_instruction. Note that
> > we pass in "dest + len" but not "real + len" as you patch fixes.
> > __copy_instruction was changed by the bad commit with:
> >
> > > -int __copy_instruction(u8 *dest, u8 *src, struct insn *insn)
> > > +int __copy_instruction(u8 *dest, u8 *src, u8 *real, struct insn *insn)
> > > {
> > > kprobe_opcode_t buf[MAX_INSN_SIZE];
> > > unsigned long recovered_insn =
> > > @@ -387,11 +388,11 @@ int __copy_instruction(u8 *dest, u8 *src, struct
> > > insn *insn)
> > > * have given.
> > > */
> > > newdisp = (u8 *) src + (s64) insn->displacement.value
> > > - - (u8 *) dest;
> > > + - (u8 *) real;
> >
> > "real" replaces "dest", which was the first parameter to __copy_instruction.
> >
> > > return 0;
> >
> > And:
> >
> > > int arch_prepare_optimized_kprobe(struct optimized_kprobe *op,
> > > struct kprobe *__unused)
> > > {
> > > - u8 *buf;
> > > - int ret;
> > > + u8 *buf = NULL, *slot;
> > > + int ret, len;
> > > long rel;
> > >
> > > if (!can_optimize((unsigned long)op->kp.addr))
> > > return -EILSEQ;
> > >
> > > - op->optinsn.insn = get_optinsn_slot();
> > > - if (!op->optinsn.insn)
> > > + buf = kzalloc(MAX_OPTINSN_SIZE, GFP_KERNEL);
> > > + if (!buf)
> > > return -ENOMEM;
> > >
> > > + op->optinsn.insn = slot = get_optinsn_slot();
> > > + if (!slot) {
> > > + ret = -ENOMEM;
> > > + goto out;
> > > + }
> > > +
> > > /*
> > > * Verify if the address gap is in 2GB range, because this uses
> > > * a relative jump.
> > > */
> > > - rel = (long)op->optinsn.insn - (long)op->kp.addr +
> > > RELATIVEJUMP_SIZE;
> > > + rel = (long)slot - (long)op->kp.addr + RELATIVEJUMP_SIZE;
> > > if (abs(rel) > 0x7fff) {
> > > - __arch_remove_optimized_kprobe(op, 0);
> > > - return -ERANGE;
> > > + ret = -ERANGE;
> > > + goto err;
> > > }
> > >
> > > - buf = (u8 *)op->optinsn.insn;
> >
> > "slot" is equivalent to the old "buf".
> >
> > > - set_memory_rw((unsigned long)buf & PAGE_MASK, 1);
> > > + /* Copy arch-dep-instance from template */
> > > + memcpy(buf, _template_entry, TMPL_END_IDX);
> > >
> > > /* Copy
Re: [BUGFIX PATCH -tip] kprobes/x86: Fix to copy RIP relative instruction correctly
Hi Ingo,
Could you pick this fix to urgent branch?
Thank you,
On Fri, 24 Aug 2018 16:57:19 +0900
Masami Hiramatsu wrote:
> On Thu, 23 Aug 2018 21:41:09 -0400
> Steven Rostedt wrote:
>
> > On Fri, 24 Aug 2018 02:16:12 +0900
> > Masami Hiramatsu wrote:
> >
> > > Dump of assembler code from 0xa000207a to 0xa00020ea:
> > > 54 push %rsp
> > > ...
> > > 48 83 c4 08 add$0x8,%rsp
> > > 9d popfq
> > > 48 89 f0mov%rsi,%rax
> > > 8b 35 82 7d db e2 mov-0x1d24827e(%rip),%esi
> > > # 0x82db9e67
> > >
> > > As it shows, the 2nd mov accesses *(nr_cpu_ids+3) instead of
> > > *nr_cpu_ids. This leads a kernel freeze because cpumask_next()
> > > always returns 0 and for_each_cpu() never ended.
> >
> > Ouch! Nice catch.
> >
> > >
> > > Fixing this by adding len correctly to real RIP address while
> > > copying.
> > >
> > > Fixes: 63fef14fc98a ("kprobes/x86: Make insn buffer always ROX and use
> > > text_poke()")
> > > Reported-by: Michael Rodin
> > > Signed-off-by: Masami Hiramatsu
> > > Cc: sta...@vger.kernel.org
> > > ---
> > > arch/x86/kernel/kprobes/opt.c |3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
> > > index eaf02f2e7300..e92672b8b490 100644
> > > --- a/arch/x86/kernel/kprobes/opt.c
> > > +++ b/arch/x86/kernel/kprobes/opt.c
> > > @@ -189,7 +189,8 @@ static int copy_optimized_instructions(u8 *dest, u8
> > > *src, u8 *real)
> > > int len = 0, ret;
> > >
> > > while (len < RELATIVEJUMP_SIZE) {
> > > - ret = __copy_instruction(dest + len, src + len, real, );
> > > + ret = __copy_instruction(dest + len, src + len, real + len,
> > > + );
> > > if (!ret || !can_boost(, src + len))
> > > return -EINVAL;
> > > len += ret;
> >
> > Looking at the change that broke this we have:
> >
> > > -static int copy_optimized_instructions(u8 *dest, u8 *src)
> > > +static int copy_optimized_instructions(u8 *dest, u8 *src, u8 *real)
> > > {
> > > struct insn insn;
> > > int len = 0, ret;
> > >
> > > while (len < RELATIVEJUMP_SIZE) {
> > > - ret = __copy_instruction(dest + len, src + len, );
> > > + ret = __copy_instruction(dest + len, src + len, real,
> > > );
> >
> > Where "real" was added as a parameter to __copy_instruction. Note that
> > we pass in "dest + len" but not "real + len" as you patch fixes.
> > __copy_instruction was changed by the bad commit with:
> >
> > > -int __copy_instruction(u8 *dest, u8 *src, struct insn *insn)
> > > +int __copy_instruction(u8 *dest, u8 *src, u8 *real, struct insn *insn)
> > > {
> > > kprobe_opcode_t buf[MAX_INSN_SIZE];
> > > unsigned long recovered_insn =
> > > @@ -387,11 +388,11 @@ int __copy_instruction(u8 *dest, u8 *src, struct
> > > insn *insn)
> > > * have given.
> > > */
> > > newdisp = (u8 *) src + (s64) insn->displacement.value
> > > - - (u8 *) dest;
> > > + - (u8 *) real;
> >
> > "real" replaces "dest", which was the first parameter to __copy_instruction.
> >
> > > return 0;
> >
> > And:
> >
> > > int arch_prepare_optimized_kprobe(struct optimized_kprobe *op,
> > > struct kprobe *__unused)
> > > {
> > > - u8 *buf;
> > > - int ret;
> > > + u8 *buf = NULL, *slot;
> > > + int ret, len;
> > > long rel;
> > >
> > > if (!can_optimize((unsigned long)op->kp.addr))
> > > return -EILSEQ;
> > >
> > > - op->optinsn.insn = get_optinsn_slot();
> > > - if (!op->optinsn.insn)
> > > + buf = kzalloc(MAX_OPTINSN_SIZE, GFP_KERNEL);
> > > + if (!buf)
> > > return -ENOMEM;
> > >
> > > + op->optinsn.insn = slot = get_optinsn_slot();
> > > + if (!slot) {
> > > + ret = -ENOMEM;
> > > + goto out;
> > > + }
> > > +
> > > /*
> > > * Verify if the address gap is in 2GB range, because this uses
> > > * a relative jump.
> > > */
> > > - rel = (long)op->optinsn.insn - (long)op->kp.addr +
> > > RELATIVEJUMP_SIZE;
> > > + rel = (long)slot - (long)op->kp.addr + RELATIVEJUMP_SIZE;
> > > if (abs(rel) > 0x7fff) {
> > > - __arch_remove_optimized_kprobe(op, 0);
> > > - return -ERANGE;
> > > + ret = -ERANGE;
> > > + goto err;
> > > }
> > >
> > > - buf = (u8 *)op->optinsn.insn;
> >
> > "slot" is equivalent to the old "buf".
> >
> > > - set_memory_rw((unsigned long)buf & PAGE_MASK, 1);
> > > + /* Copy arch-dep-instance from template */
> > > + memcpy(buf, _template_entry, TMPL_END_IDX);
> > >
> > > /* Copy
[PATCH] fs/cifs: suppress a string overflow warning
A powerpc build of cifs with gcc v8.2.0 produces this warning:
fs/cifs/cifssmb.c: In function ‘CIFSSMBNegotiate’:
fs/cifs/cifssmb.c:605:3: warning: ‘strncpy’ writing 16 bytes into a region of
size 1 overflows the destination [-Wstringop-overflow=]
strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
^
Since we are already doing a strlen() on the source, change the strncpy
to a memcpy().
Signed-off-by: Stephen Rothwell
---
fs/cifs/cifssmb.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index dc2f4cf08fe9..dcf939cb9d2f 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -601,10 +601,14 @@ CIFSSMBNegotiate(const unsigned int xid, struct cifs_ses
*ses)
}
count = 0;
+ /*
+* We know that all the name entries in the protocols array
+* are short (< 16 bytes anyway) and are NUL terminated.
+*/
for (i = 0; i < CIFS_NUM_PROT; i++) {
- strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
- count += strlen(protocols[i].name) + 1;
- /* null at end of source and target buffers anyway */
+ size_t len = strlen(protocols[i].name) + 1;
+ memcpy(pSMB->DialectsArray+count, protocols[i].name, len);
+ count += len;
}
inc_rfc1001_len(pSMB, count);
pSMB->ByteCount = cpu_to_le16(count);
--
2.19.0.rc1
--
Cheers,
Stephen Rothwell
pgpxnEW2hf_nN.pgp
Description: OpenPGP digital signature
[PATCH] fs/cifs: suppress a string overflow warning
A powerpc build of cifs with gcc v8.2.0 produces this warning:
fs/cifs/cifssmb.c: In function ‘CIFSSMBNegotiate’:
fs/cifs/cifssmb.c:605:3: warning: ‘strncpy’ writing 16 bytes into a region of
size 1 overflows the destination [-Wstringop-overflow=]
strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
^
Since we are already doing a strlen() on the source, change the strncpy
to a memcpy().
Signed-off-by: Stephen Rothwell
---
fs/cifs/cifssmb.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index dc2f4cf08fe9..dcf939cb9d2f 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -601,10 +601,14 @@ CIFSSMBNegotiate(const unsigned int xid, struct cifs_ses
*ses)
}
count = 0;
+ /*
+* We know that all the name entries in the protocols array
+* are short (< 16 bytes anyway) and are NUL terminated.
+*/
for (i = 0; i < CIFS_NUM_PROT; i++) {
- strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
- count += strlen(protocols[i].name) + 1;
- /* null at end of source and target buffers anyway */
+ size_t len = strlen(protocols[i].name) + 1;
+ memcpy(pSMB->DialectsArray+count, protocols[i].name, len);
+ count += len;
}
inc_rfc1001_len(pSMB, count);
pSMB->ByteCount = cpu_to_le16(count);
--
2.19.0.rc1
--
Cheers,
Stephen Rothwell
pgpxnEW2hf_nN.pgp
Description: OpenPGP digital signature
Re: [PATCH 5/7] arm64: dts: lx2160a: add fspi node property
On Fri, Aug 31, 2018 at 04:00:02PM +0530, Yogesh Gaur wrote:
> Add fspi node property for LX2160A SoC for FlexSPI driver.
> Property added for the FlexSPI controller and for the connected
> slave device for the LX2160ARDB target.
> This is having two SPI-NOR flash device, mt35xu512aba, connected
> at CS0 and CS1.
>
> Signed-off-by: Yogesh Gaur
> ---
> arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 +
> arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi| 12
> 2 files changed, 33 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> index 70fad20..3646315 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> @@ -32,6 +32,27 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
Have a newline between property and child node.
> + flash0: mt35xu512aba@0 {
Generic name for node, and specific name for label.
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "m25p80";
Please take a look at bindings doc jedec,spi-nor.txt on how compatible
should be written.
> + m25p,fast-read;
> + spi-max-frequency = <2000>;
> + reg = <0>;
> + };
> +
> + flash1: mt35xu512aba@1 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "m25p80";
> + m25p,fast-read;
> + spi-max-frequency = <2000>;
> + reg = <1>;
> + };
> +};
> +
> {
> status = "okay";
> pca9547@77 {
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index e35e494..031eb26 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -568,5 +568,17 @@
> timeout-sec = <30>;
> };
>
> + fspi: flexspi@20c {
> + status = "disabled";
We conventionally put 'status' line at the end of property list.
Shawn
> + compatible = "nxp,lx2160a-fspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x20c 0x0 0x1>,
> + <0x0 0x2000 0x0 0x1000>;
> + reg-names = "fspi_base", "fspi_mmap";
> + interrupts = <0 25 0x4>; /* Level high type */
> + clocks = < 4 3>, < 4 3>;
> + clock-names = "fspi_en", "fspi";
> + };
> };
> };
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 5/7] arm64: dts: lx2160a: add fspi node property
On Fri, Aug 31, 2018 at 04:00:02PM +0530, Yogesh Gaur wrote:
> Add fspi node property for LX2160A SoC for FlexSPI driver.
> Property added for the FlexSPI controller and for the connected
> slave device for the LX2160ARDB target.
> This is having two SPI-NOR flash device, mt35xu512aba, connected
> at CS0 and CS1.
>
> Signed-off-by: Yogesh Gaur
> ---
> arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 +
> arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi| 12
> 2 files changed, 33 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> index 70fad20..3646315 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> @@ -32,6 +32,27 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
Have a newline between property and child node.
> + flash0: mt35xu512aba@0 {
Generic name for node, and specific name for label.
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "m25p80";
Please take a look at bindings doc jedec,spi-nor.txt on how compatible
should be written.
> + m25p,fast-read;
> + spi-max-frequency = <2000>;
> + reg = <0>;
> + };
> +
> + flash1: mt35xu512aba@1 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "m25p80";
> + m25p,fast-read;
> + spi-max-frequency = <2000>;
> + reg = <1>;
> + };
> +};
> +
> {
> status = "okay";
> pca9547@77 {
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index e35e494..031eb26 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -568,5 +568,17 @@
> timeout-sec = <30>;
> };
>
> + fspi: flexspi@20c {
> + status = "disabled";
We conventionally put 'status' line at the end of property list.
Shawn
> + compatible = "nxp,lx2160a-fspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x20c 0x0 0x1>,
> + <0x0 0x2000 0x0 0x1000>;
> + reg-names = "fspi_base", "fspi_mmap";
> + interrupts = <0 25 0x4>; /* Level high type */
> + clocks = < 4 3>, < 4 3>;
> + clock-names = "fspi_en", "fspi";
> + };
> };
> };
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
linux-next: Tree for Sep 3
Hi all, Changes since 20180831: Dropped trees: xarray, ida (temporarily) The net-next tree gained a build failure for which I reverted a commit. Non-merge commits (relative to Linus' tree): 1489 1812 files changed, 56535 insertions(+), 18845 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (57361846b52b Linux 4.19-rc2) Merging fixes/master (217c3e019675 disable stringop truncation warnings for now) Merging kbuild-current/fixes (914b087ff9e0 kbuild: make missing $DEPMOD a Warning instead of an Error) Merging arc-current/for-curr (3fcbb8260a87 ARC: atomics: unbork atomic_fetch_##op()) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (f52bb98f5ade arm64: mm: always enable CONFIG_HOLES_IN_ZONE) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (15a81b418e22 net/ipv6: Only update MTU metric if it set) Merging bpf/master (597222f72a94 bpf: avoid misuse of psock when TCP_ULP_BPF collides with another ULP) Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for new entries) Merging netfilter/master (7acfda539c0b netfilter: nf_tables: release chain in flushing set) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (53ae914d898e net/rds: Use rdma_read_gids to get connection SGID/DGID in IPv6) Merging mac80211/master (aa58acf325b4 mac80211: always account for A-MSDU header changes) Merging rdma-fixes/for-rc (5b394b2ddf03 Linux 4.19-rc1) Merging sound-current/for-linus (16037643969e ALSA: hda - Fix cancel_work_sync() stall from jackpoll work) Merging sound-asoc-fixes/for-linus (f26f753fa175 Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging regulator-fixes/for-linus (ef394f3fbecb regulator: da9063: fix DT probing with constraints) Merging spi-fixes/for-linus (8e9f6c9dd001 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging driver-core.current/driver-core-linus (5b394b2ddf03 Linux 4.19-rc1) Merging tty.current/tty-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb.current/usb-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb-gadget-fixes/fixes (5b394b2ddf03 Linux 4.19-rc1) Merging usb-serial-fixes/usb-linus (5dfdd24eb3d3 USB: serial: ti_usb_3410_5052: fix array underflow in completion handler) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600: Fix wrong enum used for status lines) Merging staging.current/staging-linus (f86cf25a6091 Revert "staging: erofs: disable compiling temporarile") Merging char-misc.current/char-misc-linus (5b394b2ddf03 Linux 4.19-rc1)
linux-next: Tree for Sep 3
Hi all, Changes since 20180831: Dropped trees: xarray, ida (temporarily) The net-next tree gained a build failure for which I reverted a commit. Non-merge commits (relative to Linus' tree): 1489 1812 files changed, 56535 insertions(+), 18845 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (57361846b52b Linux 4.19-rc2) Merging fixes/master (217c3e019675 disable stringop truncation warnings for now) Merging kbuild-current/fixes (914b087ff9e0 kbuild: make missing $DEPMOD a Warning instead of an Error) Merging arc-current/for-curr (3fcbb8260a87 ARC: atomics: unbork atomic_fetch_##op()) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (f52bb98f5ade arm64: mm: always enable CONFIG_HOLES_IN_ZONE) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (15a81b418e22 net/ipv6: Only update MTU metric if it set) Merging bpf/master (597222f72a94 bpf: avoid misuse of psock when TCP_ULP_BPF collides with another ULP) Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for new entries) Merging netfilter/master (7acfda539c0b netfilter: nf_tables: release chain in flushing set) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (53ae914d898e net/rds: Use rdma_read_gids to get connection SGID/DGID in IPv6) Merging mac80211/master (aa58acf325b4 mac80211: always account for A-MSDU header changes) Merging rdma-fixes/for-rc (5b394b2ddf03 Linux 4.19-rc1) Merging sound-current/for-linus (16037643969e ALSA: hda - Fix cancel_work_sync() stall from jackpoll work) Merging sound-asoc-fixes/for-linus (f26f753fa175 Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging regulator-fixes/for-linus (ef394f3fbecb regulator: da9063: fix DT probing with constraints) Merging spi-fixes/for-linus (8e9f6c9dd001 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging driver-core.current/driver-core-linus (5b394b2ddf03 Linux 4.19-rc1) Merging tty.current/tty-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb.current/usb-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb-gadget-fixes/fixes (5b394b2ddf03 Linux 4.19-rc1) Merging usb-serial-fixes/usb-linus (5dfdd24eb3d3 USB: serial: ti_usb_3410_5052: fix array underflow in completion handler) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600: Fix wrong enum used for status lines) Merging staging.current/staging-linus (f86cf25a6091 Revert "staging: erofs: disable compiling temporarile") Merging char-misc.current/char-misc-linus (5b394b2ddf03 Linux 4.19-rc1)
Re: Access to non-RAM pages
On Sun, Sep 2, 2018 at 7:47 PM Linus Torvalds
wrote:
>
> The comment actually does talk about it, although the comment also
> claims that the cs read would use load_unaligned_zeropad(), which it
> no longer does (now it only does the read_word_at_a_time).
IOW, look at commit 12f8ad4b0533 ("vfs: clean up __d_lookup_rcu() and
dentry_cmp() interfaces") for why the zeropad went away for the cs
access (but the comment wasn't updated).
And then bfe7aa6c39b1 ("fs/dcache: Use read_word_at_a_time() in
dentry_string_cmp()") did the "let's make KASAN happy thing.
And yes, the word-at-a-time code actually matters a lot for certain
loads. The "copy-and-hash" thing for path components ends up being
pretty critical in all the pathname handling.
Linus
Re: Access to non-RAM pages
On Sun, Sep 2, 2018 at 7:47 PM Linus Torvalds
wrote:
>
> The comment actually does talk about it, although the comment also
> claims that the cs read would use load_unaligned_zeropad(), which it
> no longer does (now it only does the read_word_at_a_time).
IOW, look at commit 12f8ad4b0533 ("vfs: clean up __d_lookup_rcu() and
dentry_cmp() interfaces") for why the zeropad went away for the cs
access (but the comment wasn't updated).
And then bfe7aa6c39b1 ("fs/dcache: Use read_word_at_a_time() in
dentry_string_cmp()") did the "let's make KASAN happy thing.
And yes, the word-at-a-time code actually matters a lot for certain
loads. The "copy-and-hash" thing for path components ends up being
pretty critical in all the pathname handling.
Linus
Re: Access to non-RAM pages
On Sun, 2018-09-02 at 19:10 -0700, Linus Torvalds wrote: > On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt > wrote: > > > > Still, I can potentially see an issue with DEBUG_PAGEALLOC > > An unmapped page isn't a problem. That's what the whole > load_unaligned_zeropad() is about: it's ok to take a fault on the part > that crosses a page, and we'll just fill the value with zeroes (that's > the "zeropad" part). Ah, my bad reading, I was looking at read_word_at_a_time() instead of load_unaligned_zeropad(). I'm not familiar enough with the dentry qstr stuff, I assume this is safe ? > So as long as it's rare (and it is), it's all fine. > > That said, I think we turn off for DEBUG_PAGEALLOC simply because it's > not rare _enough_. > > And vmalloc() should actually be safe too, simply because I think we > strive for a guard page between vmalloc areas. > > So only a *mapped* page after the page that matters, and only if it's > something you can't read without side effects. > > Which basically doesn't happen on x86 in reality. BIOSes just don't > put MMIO right after the last page of RAM. I think this is why it only > triggered on Xen, due to some crazy "Xen reacts badly" case where we > do the speculation into a balloon address. > > So _practically_ this is just a Xen bug, nothing more. > > But since in _theory_ you could have MMIO abut regular RAM directly, > it's worth maybe making sure it's purely theory.
Re: Access to non-RAM pages
On Sun, 2018-09-02 at 19:10 -0700, Linus Torvalds wrote: > On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt > wrote: > > > > Still, I can potentially see an issue with DEBUG_PAGEALLOC > > An unmapped page isn't a problem. That's what the whole > load_unaligned_zeropad() is about: it's ok to take a fault on the part > that crosses a page, and we'll just fill the value with zeroes (that's > the "zeropad" part). Ah, my bad reading, I was looking at read_word_at_a_time() instead of load_unaligned_zeropad(). I'm not familiar enough with the dentry qstr stuff, I assume this is safe ? > So as long as it's rare (and it is), it's all fine. > > That said, I think we turn off for DEBUG_PAGEALLOC simply because it's > not rare _enough_. > > And vmalloc() should actually be safe too, simply because I think we > strive for a guard page between vmalloc areas. > > So only a *mapped* page after the page that matters, and only if it's > something you can't read without side effects. > > Which basically doesn't happen on x86 in reality. BIOSes just don't > put MMIO right after the last page of RAM. I think this is why it only > triggered on Xen, due to some crazy "Xen reacts badly" case where we > do the speculation into a balloon address. > > So _practically_ this is just a Xen bug, nothing more. > > But since in _theory_ you could have MMIO abut regular RAM directly, > it's worth maybe making sure it's purely theory.
[PATCH v2] perf: Fix clean error
When make perf with -O, it gets error when make clean with below log: $ make -C tools/perf O= # OK $ make -C tools/perf O= clean # Got below error find: cannot delete ‘/builtin-script.o’: No such file or directory find: cannot delete ‘/.subcmd-config.o.cmd’: No such file or directory ... Makefile:38: recipe for target 'clean' failed make[2]: *** [clean] Error 1 make[1]: *** [fixdep-clean] Error 2 Makefile:90: recipe for target 'clean' failed make: *** [clean] Error 2 It happens because both fixdep-clean and libsubcmd-clean will delete files by `find`, where libsubcmd-clean uses `| xargs $(RM)` and fixdep-clean uses `-delete`. When a file is find by fixdep-clean, and tries to delete it, it's found that the file does not exist because it is deleted by libsubcmd-clean. This commit changes the delete method of fixdep-clean to use `| xargs $(RM)` as well, where RM is defined as `rm -f` so it does not return error when file does not exist. Signed-off-by: Lei YU --- v2: Fix missing "make clean" in commit message --- tools/build/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/build/Makefile b/tools/build/Makefile index 5edf65e..ae38db2 100644 --- a/tools/build/Makefile +++ b/tools/build/Makefile @@ -18,6 +18,7 @@ $(call allow-override,LD,$(CROSS_COMPILE)ld) HOSTCC ?= gcc HOSTLD ?= ld HOSTAR ?= ar +RM = rm -f export HOSTCC HOSTLD HOSTAR @@ -36,7 +37,7 @@ all: $(OUTPUT)fixdep clean: $(call QUIET_CLEAN, fixdep) - $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' -delete + $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -o -name '\.*.cmd' -o -name '\.*.d' | xargs $(RM) $(Q)rm -f $(OUTPUT)fixdep $(OUTPUT)fixdep-in.o: FORCE -- 2.7.4
[PATCH v2] perf: Fix clean error
When make perf with -O, it gets error when make clean with below log: $ make -C tools/perf O= # OK $ make -C tools/perf O= clean # Got below error find: cannot delete ‘/builtin-script.o’: No such file or directory find: cannot delete ‘/.subcmd-config.o.cmd’: No such file or directory ... Makefile:38: recipe for target 'clean' failed make[2]: *** [clean] Error 1 make[1]: *** [fixdep-clean] Error 2 Makefile:90: recipe for target 'clean' failed make: *** [clean] Error 2 It happens because both fixdep-clean and libsubcmd-clean will delete files by `find`, where libsubcmd-clean uses `| xargs $(RM)` and fixdep-clean uses `-delete`. When a file is find by fixdep-clean, and tries to delete it, it's found that the file does not exist because it is deleted by libsubcmd-clean. This commit changes the delete method of fixdep-clean to use `| xargs $(RM)` as well, where RM is defined as `rm -f` so it does not return error when file does not exist. Signed-off-by: Lei YU --- v2: Fix missing "make clean" in commit message --- tools/build/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/build/Makefile b/tools/build/Makefile index 5edf65e..ae38db2 100644 --- a/tools/build/Makefile +++ b/tools/build/Makefile @@ -18,6 +18,7 @@ $(call allow-override,LD,$(CROSS_COMPILE)ld) HOSTCC ?= gcc HOSTLD ?= ld HOSTAR ?= ar +RM = rm -f export HOSTCC HOSTLD HOSTAR @@ -36,7 +37,7 @@ all: $(OUTPUT)fixdep clean: $(call QUIET_CLEAN, fixdep) - $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' -delete + $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -o -name '\.*.cmd' -o -name '\.*.d' | xargs $(RM) $(Q)rm -f $(OUTPUT)fixdep $(OUTPUT)fixdep-in.o: FORCE -- 2.7.4
Re: [PATCH] arm64: dts: ls208xa: add second duart
On Thu, Aug 30, 2018 at 11:00:38AM +0200, Kurt Kanzenbach wrote: > The NXP LS208xA SoCs have two dual uarts. Thus, add the second one. > > Signed-off-by: Kurt Kanzenbach Applied, thanks.
Re: [PATCH] arm64: dts: ls208xa: add second duart
On Thu, Aug 30, 2018 at 11:00:38AM +0200, Kurt Kanzenbach wrote: > The NXP LS208xA SoCs have two dual uarts. Thus, add the second one. > > Signed-off-by: Kurt Kanzenbach Applied, thanks.
Re: Access to non-RAM pages
On Sun, Sep 2, 2018 at 7:25 PM Benjamin Herrenschmidt wrote: > Ah, my bad reading, I was looking at read_word_at_a_time() instead of > load_unaligned_zeropad(). I'm not familiar enough with the dentry qstr > stuff, I assume this is safe ? The dentry qstr should always be 8-byte aligned because it's a kernel name allocation. So it's the path component in the actual pathname string that can be unaligned (ct/tcount in dentry_string_cmp). The comment actually does talk about it, although the comment also claims that the cs read would use load_unaligned_zeropad(), which it no longer does (now it only does the read_word_at_a_time). And read_word_at_a_time() is purely a KASAN thing. The thing can't fault, but it *can* read uninitialized data past the end of the string, making KASAN unhappy. So that's actually a different issue, where KASAN does byte-level validity testing, and doing word-at-a-time accesses obviously violates that for strings. Linus
Re: Access to non-RAM pages
On Sun, Sep 2, 2018 at 7:25 PM Benjamin Herrenschmidt wrote: > Ah, my bad reading, I was looking at read_word_at_a_time() instead of > load_unaligned_zeropad(). I'm not familiar enough with the dentry qstr > stuff, I assume this is safe ? The dentry qstr should always be 8-byte aligned because it's a kernel name allocation. So it's the path component in the actual pathname string that can be unaligned (ct/tcount in dentry_string_cmp). The comment actually does talk about it, although the comment also claims that the cs read would use load_unaligned_zeropad(), which it no longer does (now it only does the read_word_at_a_time). And read_word_at_a_time() is purely a KASAN thing. The thing can't fault, but it *can* read uninitialized data past the end of the string, making KASAN unhappy. So that's actually a different issue, where KASAN does byte-level validity testing, and doing word-at-a-time accesses obviously violates that for strings. Linus
Re: [PATCH] arm64: dts: ls208xa: add second duart
On Sun, Sep 2, 2018 at 9:34 PM Shawn Guo wrote:
>
> It looks good to me. @Leo, are you okay with it?
It looks fine.
Acked-by: Li Yang
>
> Shawn
>
> On Thu, Aug 30, 2018 at 11:00:38AM +0200, Kurt Kanzenbach wrote:
> > The NXP LS208xA SoCs have two dual uarts. Thus, add the second one.
> >
> > Signed-off-by: Kurt Kanzenbach
> > ---
> > arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > index 8cb78dd99672..547a86ec7cd2 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > @@ -22,6 +22,8 @@
> > crypto =
> > serial0 =
> > serial1 =
> > + serial2 =
> > + serial3 =
> > };
> >
> > cpu: cpus {
> > @@ -221,6 +223,20 @@
> > interrupts = <0 32 0x4>; /* Level high type */
> > };
> >
> > + serial2: serial@21d0500 {
> > + compatible = "fsl,ns16550", "ns16550a";
> > + reg = <0x0 0x21d0500 0x0 0x100>;
> > + clocks = < 4 3>;
> > + interrupts = <0 33 0x4>; /* Level high type */
> > + };
> > +
> > + serial3: serial@21d0600 {
> > + compatible = "fsl,ns16550", "ns16550a";
> > + reg = <0x0 0x21d0600 0x0 0x100>;
> > + clocks = < 4 3>;
> > + interrupts = <0 33 0x4>; /* Level high type */
> > + };
> > +
> > cluster1_core0_watchdog: wdt@c00 {
> > compatible = "arm,sp805-wdt", "arm,primecell";
> > reg = <0x0 0xc00 0x0 0x1000>;
> > --
> > 2.11.0
> >
Re: [PATCH] arm64: dts: ls208xa: add second duart
On Sun, Sep 2, 2018 at 9:34 PM Shawn Guo wrote:
>
> It looks good to me. @Leo, are you okay with it?
It looks fine.
Acked-by: Li Yang
>
> Shawn
>
> On Thu, Aug 30, 2018 at 11:00:38AM +0200, Kurt Kanzenbach wrote:
> > The NXP LS208xA SoCs have two dual uarts. Thus, add the second one.
> >
> > Signed-off-by: Kurt Kanzenbach
> > ---
> > arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > index 8cb78dd99672..547a86ec7cd2 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > @@ -22,6 +22,8 @@
> > crypto =
> > serial0 =
> > serial1 =
> > + serial2 =
> > + serial3 =
> > };
> >
> > cpu: cpus {
> > @@ -221,6 +223,20 @@
> > interrupts = <0 32 0x4>; /* Level high type */
> > };
> >
> > + serial2: serial@21d0500 {
> > + compatible = "fsl,ns16550", "ns16550a";
> > + reg = <0x0 0x21d0500 0x0 0x100>;
> > + clocks = < 4 3>;
> > + interrupts = <0 33 0x4>; /* Level high type */
> > + };
> > +
> > + serial3: serial@21d0600 {
> > + compatible = "fsl,ns16550", "ns16550a";
> > + reg = <0x0 0x21d0600 0x0 0x100>;
> > + clocks = < 4 3>;
> > + interrupts = <0 33 0x4>; /* Level high type */
> > + };
> > +
> > cluster1_core0_watchdog: wdt@c00 {
> > compatible = "arm,sp805-wdt", "arm,primecell";
> > reg = <0x0 0xc00 0x0 0x1000>;
> > --
> > 2.11.0
> >
Re: [PATCH] ACPI / LPSS: Ensure LPIOEP is always set on resume
Hi, William,
On 六, 2018-09-01 at 12:59 -0500, William Lieurance wrote:
> For some number of systems with lpss_quirks enabled, on boot the
> system
> goes through an acpi_lpss_resume() without a corresponding
> acpi_lpss_suspend() having been called.
I read the code but didn't find out why this could happen, but if it is
true, please check if the below patch helps
>From 27fda1ab0d800966b0ec1c444fe356812bd2f04e Mon Sep 17 00:00:00 2001
From: Zhang Rui
Date: Mon, 3 Sep 2018 10:00:07 +0800
Subject: [PATCH] ACPI / LPSS: Force lpss quirks on boot
Commit 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume
from hibernation") bypasses lpss quirks for S3 and S4, by setting a flag
for S3/S4 in acpi_lpss_suspend(), and check that flag in
acpi_lpss_resume().
But this overlooks the boot case where acpi_lpss_resume() may get called
without a corresponding acpi_lpss_suspend() having been called.
Thus force setting the flag during boot.
Fixes: 12864ff8545f (ACPI / LPSS: Avoid PM quirks on suspend and resume from
hibernation)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200989
Signed-off-by: Zhang Rui
---
drivers/acpi/acpi_lpss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 9706613..bf64cfa 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -879,7 +879,7 @@ static void acpi_lpss_dismiss(struct device *dev)
#define LPSS_GPIODEF0_DMA_LLP BIT(13)
static DEFINE_MUTEX(lpss_iosf_mutex);
-static bool lpss_iosf_d3_entered;
+static bool lpss_iosf_d3_entered = true;
static void lpss_iosf_enter_d3_state(void)
{
--
2.7.4
Re: [PATCH] ACPI / LPSS: Ensure LPIOEP is always set on resume
Hi, William,
On 六, 2018-09-01 at 12:59 -0500, William Lieurance wrote:
> For some number of systems with lpss_quirks enabled, on boot the
> system
> goes through an acpi_lpss_resume() without a corresponding
> acpi_lpss_suspend() having been called.
I read the code but didn't find out why this could happen, but if it is
true, please check if the below patch helps
>From 27fda1ab0d800966b0ec1c444fe356812bd2f04e Mon Sep 17 00:00:00 2001
From: Zhang Rui
Date: Mon, 3 Sep 2018 10:00:07 +0800
Subject: [PATCH] ACPI / LPSS: Force lpss quirks on boot
Commit 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume
from hibernation") bypasses lpss quirks for S3 and S4, by setting a flag
for S3/S4 in acpi_lpss_suspend(), and check that flag in
acpi_lpss_resume().
But this overlooks the boot case where acpi_lpss_resume() may get called
without a corresponding acpi_lpss_suspend() having been called.
Thus force setting the flag during boot.
Fixes: 12864ff8545f (ACPI / LPSS: Avoid PM quirks on suspend and resume from
hibernation)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200989
Signed-off-by: Zhang Rui
---
drivers/acpi/acpi_lpss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 9706613..bf64cfa 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -879,7 +879,7 @@ static void acpi_lpss_dismiss(struct device *dev)
#define LPSS_GPIODEF0_DMA_LLP BIT(13)
static DEFINE_MUTEX(lpss_iosf_mutex);
-static bool lpss_iosf_d3_entered;
+static bool lpss_iosf_d3_entered = true;
static void lpss_iosf_enter_d3_state(void)
{
--
2.7.4
[PATCH] sound: soc: fix soc-core.c kernel-doc warning
From: Randy Dunlap Fix kernel-doc warning: ../sound/soc/soc-core.c:2918: warning: Excess function parameter 'legacy_dai_naming' description in 'snd_soc_register_dais' Signed-off-by: Randy Dunlap Cc: Liam Girdwood Cc: Mark Brown --- sound/soc/soc-core.c |2 -- 1 file changed, 2 deletions(-) --- lnx-419-rc2.orig/sound/soc/soc-core.c +++ lnx-419-rc2/sound/soc/soc-core.c @@ -2910,8 +2910,6 @@ static struct snd_soc_dai *soc_add_dai(s * @component: The component the DAIs are registered for * @dai_drv: DAI driver to use for the DAIs * @count: Number of DAIs - * @legacy_dai_naming: Use the legacy naming scheme and let the DAI inherit the - * parent's name. */ static int snd_soc_register_dais(struct snd_soc_component *component, struct snd_soc_dai_driver *dai_drv, size_t count)
[PATCH] sound: soc: fix soc-core.c kernel-doc warning
From: Randy Dunlap Fix kernel-doc warning: ../sound/soc/soc-core.c:2918: warning: Excess function parameter 'legacy_dai_naming' description in 'snd_soc_register_dais' Signed-off-by: Randy Dunlap Cc: Liam Girdwood Cc: Mark Brown --- sound/soc/soc-core.c |2 -- 1 file changed, 2 deletions(-) --- lnx-419-rc2.orig/sound/soc/soc-core.c +++ lnx-419-rc2/sound/soc/soc-core.c @@ -2910,8 +2910,6 @@ static struct snd_soc_dai *soc_add_dai(s * @component: The component the DAIs are registered for * @dai_drv: DAI driver to use for the DAIs * @count: Number of DAIs - * @legacy_dai_naming: Use the legacy naming scheme and let the DAI inherit the - * parent's name. */ static int snd_soc_register_dais(struct snd_soc_component *component, struct snd_soc_dai_driver *dai_drv, size_t count)
Re: [PATCH] regulator: fix kernel-doc parameter warning
Sorry about missing the Cc's. Would you like me to resend it? On 09/02/2018 07:33 PM, Randy Dunlap wrote: > From: Randy Dunlap > > Fix kernel-doc warning: > > ../drivers/regulator/core.c:4479: warning: Excess function parameter 'state' > description in 'regulator_suspend' > > Signed-off-by: Randy Dunlap > Cc: Liam Girdwood > Cc: Mark Brown > --- > drivers/regulator/core.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- lnx-419-rc2.orig/drivers/regulator/core.c > +++ lnx-419-rc2/drivers/regulator/core.c > @@ -4470,7 +4470,7 @@ static int _regulator_suspend(struct dev > > /** > * regulator_suspend - prepare regulators for system wide suspend > - * @state: system suspend state > + * @dev: `` device`` pointer that is passed to _regulator_suspend() > * > * Configure each regulator with it's suspend operating parameters for state. > */ > -- ~Randy
Re: [PATCH] regulator: fix kernel-doc parameter warning
Sorry about missing the Cc's. Would you like me to resend it? On 09/02/2018 07:33 PM, Randy Dunlap wrote: > From: Randy Dunlap > > Fix kernel-doc warning: > > ../drivers/regulator/core.c:4479: warning: Excess function parameter 'state' > description in 'regulator_suspend' > > Signed-off-by: Randy Dunlap > Cc: Liam Girdwood > Cc: Mark Brown > --- > drivers/regulator/core.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- lnx-419-rc2.orig/drivers/regulator/core.c > +++ lnx-419-rc2/drivers/regulator/core.c > @@ -4470,7 +4470,7 @@ static int _regulator_suspend(struct dev > > /** > * regulator_suspend - prepare regulators for system wide suspend > - * @state: system suspend state > + * @dev: `` device`` pointer that is passed to _regulator_suspend() > * > * Configure each regulator with it's suspend operating parameters for state. > */ > -- ~Randy
[PATCH] regulator: fix kernel-doc parameter warning
From: Randy Dunlap Fix kernel-doc warning: ../drivers/regulator/core.c:4479: warning: Excess function parameter 'state' description in 'regulator_suspend' Signed-off-by: Randy Dunlap Cc: Liam Girdwood Cc: Mark Brown --- drivers/regulator/core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-419-rc2.orig/drivers/regulator/core.c +++ lnx-419-rc2/drivers/regulator/core.c @@ -4470,7 +4470,7 @@ static int _regulator_suspend(struct dev /** * regulator_suspend - prepare regulators for system wide suspend - * @state: system suspend state + * @dev: `` device`` pointer that is passed to _regulator_suspend() * * Configure each regulator with it's suspend operating parameters for state. */
[PATCH] regulator: fix kernel-doc parameter warning
From: Randy Dunlap Fix kernel-doc warning: ../drivers/regulator/core.c:4479: warning: Excess function parameter 'state' description in 'regulator_suspend' Signed-off-by: Randy Dunlap Cc: Liam Girdwood Cc: Mark Brown --- drivers/regulator/core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-419-rc2.orig/drivers/regulator/core.c +++ lnx-419-rc2/drivers/regulator/core.c @@ -4470,7 +4470,7 @@ static int _regulator_suspend(struct dev /** * regulator_suspend - prepare regulators for system wide suspend - * @state: system suspend state + * @dev: `` device`` pointer that is passed to _regulator_suspend() * * Configure each regulator with it's suspend operating parameters for state. */
Re: [PATCH] arm64: dts: ls208xa: add second duart
It looks good to me. @Leo, are you okay with it?
Shawn
On Thu, Aug 30, 2018 at 11:00:38AM +0200, Kurt Kanzenbach wrote:
> The NXP LS208xA SoCs have two dual uarts. Thus, add the second one.
>
> Signed-off-by: Kurt Kanzenbach
> ---
> arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> index 8cb78dd99672..547a86ec7cd2 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> @@ -22,6 +22,8 @@
> crypto =
> serial0 =
> serial1 =
> + serial2 =
> + serial3 =
> };
>
> cpu: cpus {
> @@ -221,6 +223,20 @@
> interrupts = <0 32 0x4>; /* Level high type */
> };
>
> + serial2: serial@21d0500 {
> + compatible = "fsl,ns16550", "ns16550a";
> + reg = <0x0 0x21d0500 0x0 0x100>;
> + clocks = < 4 3>;
> + interrupts = <0 33 0x4>; /* Level high type */
> + };
> +
> + serial3: serial@21d0600 {
> + compatible = "fsl,ns16550", "ns16550a";
> + reg = <0x0 0x21d0600 0x0 0x100>;
> + clocks = < 4 3>;
> + interrupts = <0 33 0x4>; /* Level high type */
> + };
> +
> cluster1_core0_watchdog: wdt@c00 {
> compatible = "arm,sp805-wdt", "arm,primecell";
> reg = <0x0 0xc00 0x0 0x1000>;
> --
> 2.11.0
>
Re: [PATCH] arm64: dts: ls208xa: add second duart
It looks good to me. @Leo, are you okay with it?
Shawn
On Thu, Aug 30, 2018 at 11:00:38AM +0200, Kurt Kanzenbach wrote:
> The NXP LS208xA SoCs have two dual uarts. Thus, add the second one.
>
> Signed-off-by: Kurt Kanzenbach
> ---
> arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> index 8cb78dd99672..547a86ec7cd2 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> @@ -22,6 +22,8 @@
> crypto =
> serial0 =
> serial1 =
> + serial2 =
> + serial3 =
> };
>
> cpu: cpus {
> @@ -221,6 +223,20 @@
> interrupts = <0 32 0x4>; /* Level high type */
> };
>
> + serial2: serial@21d0500 {
> + compatible = "fsl,ns16550", "ns16550a";
> + reg = <0x0 0x21d0500 0x0 0x100>;
> + clocks = < 4 3>;
> + interrupts = <0 33 0x4>; /* Level high type */
> + };
> +
> + serial3: serial@21d0600 {
> + compatible = "fsl,ns16550", "ns16550a";
> + reg = <0x0 0x21d0600 0x0 0x100>;
> + clocks = < 4 3>;
> + interrupts = <0 33 0x4>; /* Level high type */
> + };
> +
> cluster1_core0_watchdog: wdt@c00 {
> compatible = "arm,sp805-wdt", "arm,primecell";
> reg = <0x0 0xc00 0x0 0x1000>;
> --
> 2.11.0
>
[PATCH] pci: fix pci.c kernel-doc parameter warning
From: Randy Dunlap Fix kernel-doc warning: ../drivers/pci/pci.c:218: warning: Excess function parameter 'p' description in 'pci_dev_str_match_path' Signed-off-by: Randy Dunlap Cc: Bjorn Helgaas Cc: linux-...@vger.kernel.org --- drivers/pci/pci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-419-rc2.orig/drivers/pci/pci.c +++ lnx-419-rc2/drivers/pci/pci.c @@ -196,7 +196,7 @@ EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar); /** * pci_dev_str_match_path - test if a path string matches a device * @dev:the PCI device to test - * @p: string to match the device against + * @path: string to match the device against * @endptr: pointer to the string after the match * * Test if a string (typically from a kernel parameter) formatted as a
[PATCH] pci: fix pci.c kernel-doc parameter warning
From: Randy Dunlap Fix kernel-doc warning: ../drivers/pci/pci.c:218: warning: Excess function parameter 'p' description in 'pci_dev_str_match_path' Signed-off-by: Randy Dunlap Cc: Bjorn Helgaas Cc: linux-...@vger.kernel.org --- drivers/pci/pci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-419-rc2.orig/drivers/pci/pci.c +++ lnx-419-rc2/drivers/pci/pci.c @@ -196,7 +196,7 @@ EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar); /** * pci_dev_str_match_path - test if a path string matches a device * @dev:the PCI device to test - * @p: string to match the device against + * @path: string to match the device against * @endptr: pointer to the string after the match * * Test if a string (typically from a kernel parameter) formatted as a
[PATCH] x86: fix kernel-doc atomic.h warnings
From: Randy Dunlap
Fix kernel-doc warnings in arch/x86/include/asm/atomic.h that are
caused by having a #define macro between the kernel-doc notation
and the function name. Fixed by moving the #define macro to after
the function implementation.
Make the same change for atomic64_{32,64}.h for consistency even
though there were no kernel-doc warnings found in these header files,
but there would be if they were used in generation of documentation.
Fixes these kernel-doc warnings:
../arch/x86/include/asm/atomic.h:84: warning: Excess function parameter 'i'
description in 'arch_atomic_sub_and_test'
../arch/x86/include/asm/atomic.h:84: warning: Excess function parameter 'v'
description in 'arch_atomic_sub_and_test'
../arch/x86/include/asm/atomic.h:96: warning: Excess function parameter 'v'
description in 'arch_atomic_inc'
../arch/x86/include/asm/atomic.h:109: warning: Excess function parameter 'v'
description in 'arch_atomic_dec'
../arch/x86/include/asm/atomic.h:124: warning: Excess function parameter 'v'
description in 'arch_atomic_dec_and_test'
../arch/x86/include/asm/atomic.h:138: warning: Excess function parameter 'v'
description in 'arch_atomic_inc_and_test'
../arch/x86/include/asm/atomic.h:153: warning: Excess function parameter 'i'
description in 'arch_atomic_add_negative'
../arch/x86/include/asm/atomic.h:153: warning: Excess function parameter 'v'
description in 'arch_atomic_add_negative'
Fixes: 18cc1814d4e7 ("atomics/treewide: Make test ops optional")
Signed-off-by: Randy Dunlap
Cc: Mark Rutland
---
arch/x86/include/asm/atomic.h | 12 ++--
arch/x86/include/asm/atomic64_32.h |8
arch/x86/include/asm/atomic64_64.h | 12 ++--
3 files changed, 16 insertions(+), 16 deletions(-)
--- lnx-419-rc2.orig/arch/x86/include/asm/atomic.h
+++ lnx-419-rc2/arch/x86/include/asm/atomic.h
@@ -80,11 +80,11 @@ static __always_inline void arch_atomic_
* true if the result is zero, or false for all
* other cases.
*/
-#define arch_atomic_sub_and_test arch_atomic_sub_and_test
static __always_inline bool arch_atomic_sub_and_test(int i, atomic_t *v)
{
GEN_BINARY_RMWcc(LOCK_PREFIX "subl", v->counter, "er", i, "%0", e);
}
+#define arch_atomic_sub_and_test arch_atomic_sub_and_test
/**
* arch_atomic_inc - increment atomic variable
@@ -92,12 +92,12 @@ static __always_inline bool arch_atomic_
*
* Atomically increments @v by 1.
*/
-#define arch_atomic_inc arch_atomic_inc
static __always_inline void arch_atomic_inc(atomic_t *v)
{
asm volatile(LOCK_PREFIX "incl %0"
: "+m" (v->counter));
}
+#define arch_atomic_inc arch_atomic_inc
/**
* arch_atomic_dec - decrement atomic variable
@@ -105,12 +105,12 @@ static __always_inline void arch_atomic_
*
* Atomically decrements @v by 1.
*/
-#define arch_atomic_dec arch_atomic_dec
static __always_inline void arch_atomic_dec(atomic_t *v)
{
asm volatile(LOCK_PREFIX "decl %0"
: "+m" (v->counter));
}
+#define arch_atomic_dec arch_atomic_dec
/**
* arch_atomic_dec_and_test - decrement and test
@@ -120,11 +120,11 @@ static __always_inline void arch_atomic_
* returns true if the result is 0, or false for all other
* cases.
*/
-#define arch_atomic_dec_and_test arch_atomic_dec_and_test
static __always_inline bool arch_atomic_dec_and_test(atomic_t *v)
{
GEN_UNARY_RMWcc(LOCK_PREFIX "decl", v->counter, "%0", e);
}
+#define arch_atomic_dec_and_test arch_atomic_dec_and_test
/**
* arch_atomic_inc_and_test - increment and test
@@ -134,11 +134,11 @@ static __always_inline bool arch_atomic_
* and returns true if the result is zero, or false for all
* other cases.
*/
-#define arch_atomic_inc_and_test arch_atomic_inc_and_test
static __always_inline bool arch_atomic_inc_and_test(atomic_t *v)
{
GEN_UNARY_RMWcc(LOCK_PREFIX "incl", v->counter, "%0", e);
}
+#define arch_atomic_inc_and_test arch_atomic_inc_and_test
/**
* arch_atomic_add_negative - add and test if negative
@@ -149,11 +149,11 @@ static __always_inline bool arch_atomic_
* if the result is negative, or false when
* result is greater than or equal to zero.
*/
-#define arch_atomic_add_negative arch_atomic_add_negative
static __always_inline bool arch_atomic_add_negative(int i, atomic_t *v)
{
GEN_BINARY_RMWcc(LOCK_PREFIX "addl", v->counter, "er", i, "%0", s);
}
+#define arch_atomic_add_negative arch_atomic_add_negative
/**
* arch_atomic_add_return - add integer and return
--- lnx-419-rc2.orig/arch/x86/include/asm/atomic64_32.h
+++ lnx-419-rc2/arch/x86/include/asm/atomic64_32.h
@@ -205,12 +205,12 @@ static inline long long arch_atomic64_su
*
* Atomically increments @v by 1.
*/
-#define arch_atomic64_inc arch_atomic64_inc
static inline void arch_atomic64_inc(atomic64_t *v)
{
__alternative_atomic64(inc, inc_return, /* no output */,
"S" (v) : "memory", "eax", "ecx", "edx");
}
+#define
[PATCH] x86: fix kernel-doc atomic.h warnings
From: Randy Dunlap
Fix kernel-doc warnings in arch/x86/include/asm/atomic.h that are
caused by having a #define macro between the kernel-doc notation
and the function name. Fixed by moving the #define macro to after
the function implementation.
Make the same change for atomic64_{32,64}.h for consistency even
though there were no kernel-doc warnings found in these header files,
but there would be if they were used in generation of documentation.
Fixes these kernel-doc warnings:
../arch/x86/include/asm/atomic.h:84: warning: Excess function parameter 'i'
description in 'arch_atomic_sub_and_test'
../arch/x86/include/asm/atomic.h:84: warning: Excess function parameter 'v'
description in 'arch_atomic_sub_and_test'
../arch/x86/include/asm/atomic.h:96: warning: Excess function parameter 'v'
description in 'arch_atomic_inc'
../arch/x86/include/asm/atomic.h:109: warning: Excess function parameter 'v'
description in 'arch_atomic_dec'
../arch/x86/include/asm/atomic.h:124: warning: Excess function parameter 'v'
description in 'arch_atomic_dec_and_test'
../arch/x86/include/asm/atomic.h:138: warning: Excess function parameter 'v'
description in 'arch_atomic_inc_and_test'
../arch/x86/include/asm/atomic.h:153: warning: Excess function parameter 'i'
description in 'arch_atomic_add_negative'
../arch/x86/include/asm/atomic.h:153: warning: Excess function parameter 'v'
description in 'arch_atomic_add_negative'
Fixes: 18cc1814d4e7 ("atomics/treewide: Make test ops optional")
Signed-off-by: Randy Dunlap
Cc: Mark Rutland
---
arch/x86/include/asm/atomic.h | 12 ++--
arch/x86/include/asm/atomic64_32.h |8
arch/x86/include/asm/atomic64_64.h | 12 ++--
3 files changed, 16 insertions(+), 16 deletions(-)
--- lnx-419-rc2.orig/arch/x86/include/asm/atomic.h
+++ lnx-419-rc2/arch/x86/include/asm/atomic.h
@@ -80,11 +80,11 @@ static __always_inline void arch_atomic_
* true if the result is zero, or false for all
* other cases.
*/
-#define arch_atomic_sub_and_test arch_atomic_sub_and_test
static __always_inline bool arch_atomic_sub_and_test(int i, atomic_t *v)
{
GEN_BINARY_RMWcc(LOCK_PREFIX "subl", v->counter, "er", i, "%0", e);
}
+#define arch_atomic_sub_and_test arch_atomic_sub_and_test
/**
* arch_atomic_inc - increment atomic variable
@@ -92,12 +92,12 @@ static __always_inline bool arch_atomic_
*
* Atomically increments @v by 1.
*/
-#define arch_atomic_inc arch_atomic_inc
static __always_inline void arch_atomic_inc(atomic_t *v)
{
asm volatile(LOCK_PREFIX "incl %0"
: "+m" (v->counter));
}
+#define arch_atomic_inc arch_atomic_inc
/**
* arch_atomic_dec - decrement atomic variable
@@ -105,12 +105,12 @@ static __always_inline void arch_atomic_
*
* Atomically decrements @v by 1.
*/
-#define arch_atomic_dec arch_atomic_dec
static __always_inline void arch_atomic_dec(atomic_t *v)
{
asm volatile(LOCK_PREFIX "decl %0"
: "+m" (v->counter));
}
+#define arch_atomic_dec arch_atomic_dec
/**
* arch_atomic_dec_and_test - decrement and test
@@ -120,11 +120,11 @@ static __always_inline void arch_atomic_
* returns true if the result is 0, or false for all other
* cases.
*/
-#define arch_atomic_dec_and_test arch_atomic_dec_and_test
static __always_inline bool arch_atomic_dec_and_test(atomic_t *v)
{
GEN_UNARY_RMWcc(LOCK_PREFIX "decl", v->counter, "%0", e);
}
+#define arch_atomic_dec_and_test arch_atomic_dec_and_test
/**
* arch_atomic_inc_and_test - increment and test
@@ -134,11 +134,11 @@ static __always_inline bool arch_atomic_
* and returns true if the result is zero, or false for all
* other cases.
*/
-#define arch_atomic_inc_and_test arch_atomic_inc_and_test
static __always_inline bool arch_atomic_inc_and_test(atomic_t *v)
{
GEN_UNARY_RMWcc(LOCK_PREFIX "incl", v->counter, "%0", e);
}
+#define arch_atomic_inc_and_test arch_atomic_inc_and_test
/**
* arch_atomic_add_negative - add and test if negative
@@ -149,11 +149,11 @@ static __always_inline bool arch_atomic_
* if the result is negative, or false when
* result is greater than or equal to zero.
*/
-#define arch_atomic_add_negative arch_atomic_add_negative
static __always_inline bool arch_atomic_add_negative(int i, atomic_t *v)
{
GEN_BINARY_RMWcc(LOCK_PREFIX "addl", v->counter, "er", i, "%0", s);
}
+#define arch_atomic_add_negative arch_atomic_add_negative
/**
* arch_atomic_add_return - add integer and return
--- lnx-419-rc2.orig/arch/x86/include/asm/atomic64_32.h
+++ lnx-419-rc2/arch/x86/include/asm/atomic64_32.h
@@ -205,12 +205,12 @@ static inline long long arch_atomic64_su
*
* Atomically increments @v by 1.
*/
-#define arch_atomic64_inc arch_atomic64_inc
static inline void arch_atomic64_inc(atomic64_t *v)
{
__alternative_atomic64(inc, inc_return, /* no output */,
"S" (v) : "memory", "eax", "ecx", "edx");
}
+#define
Re: [PATCH] ARM: dts: imx6sx-sdb: enable gpio buttons as wakeup source
On Thu, Aug 30, 2018 at 02:59:39PM +0800, Anson Huang wrote: > This patch enables i.MX6SX SDB board's below GPIO buttons > as wakeup sources: > > SW4(FUNC1): KEY_VOLUMEUP > SW5(FUNC2): KEY_VOLUMEDOWN > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH] ARM: dts: imx6sx-sdb: enable gpio buttons as wakeup source
On Thu, Aug 30, 2018 at 02:59:39PM +0800, Anson Huang wrote: > This patch enables i.MX6SX SDB board's below GPIO buttons > as wakeup sources: > > SW4(FUNC1): KEY_VOLUMEUP > SW5(FUNC2): KEY_VOLUMEDOWN > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH] ARM: dts: imx6ull: update iomux header
Add Sébastien for a cross check. Shawn On Thu, Aug 30, 2018 at 01:20:05PM +0800, Anson Huang wrote: > Update i.MX6ULL iomux header according to latest reference > manual Rev.1, 11/2017. > > Signed-off-by: Anson Huang > --- > arch/arm/boot/dts/imx6ull-pinfunc.h | 21 +++-- > 1 file changed, 19 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h > b/arch/arm/boot/dts/imx6ull-pinfunc.h > index 3c12a6f..a282a31 100644 > --- a/arch/arm/boot/dts/imx6ull-pinfunc.h > +++ b/arch/arm/boot/dts/imx6ull-pinfunc.h > @@ -27,10 +27,25 @@ > #define MX6UL_PAD_CSI_DATA02__UART5_DCE_RTS 0x01EC > 0x0478 0x0640 0x8 0x7 > > /* signals for i.MX6ULL only */ > +#define MX6ULL_PAD_UART1_TX_DATA__UART5_DCE_TX0x0084 > 0x0310 0x 0x9 0x0 > #define MX6ULL_PAD_UART1_TX_DATA__UART5_DTE_RX0x0084 > 0x0310 0x0644 0x9 0x4 > #define MX6ULL_PAD_UART1_RX_DATA__UART5_DCE_RX0x0088 > 0x0314 0x0644 0x9 0x5 > -#define MX6ULL_PAD_UART1_CTS_B__UART5_DCE_RTS 0x008C > 0x0318 0x0640 0x9 0x3 > -#define MX6ULL_PAD_UART1_RTS_B__UART5_DTE_RTS 0x0090 > 0x031C 0x0640 0x9 0x4 > +#define MX6ULL_PAD_UART1_RX_DATA__UART5_DTE_TX0x0088 > 0x0314 0x 0x9 0x0 > +#define MX6ULL_PAD_UART1_CTS_B__UART5_DCE_CTS 0x008C > 0x0318 0x 0x9 0x0 > +#define MX6ULL_PAD_UART1_CTS_B__UART5_DTE_RTS 0x008C > 0x0318 0x0640 0x9 0x3 > +#define MX6ULL_PAD_UART1_RTS_B__UART5_DCE_RTS 0x0090 > 0x031C 0x0640 0x9 0x4 > +#define MX6ULL_PAD_UART1_RTS_B__UART5_DTE_CTS 0x0090 > 0x031C 0x 0x9 0x0 > +#define MX6ULL_PAD_UART4_RX_DATA__EPDC_PWRCTRL01 0x00B8 > 0x0344 0x 0x9 0x0 > +#define MX6ULL_PAD_UART5_TX_DATA__EPDC_PWRCTRL02 0x00BC > 0x0348 0x 0x9 0x0 > +#define MX6ULL_PAD_UART5_RX_DATA__EPDC_PWRCTRL03 0x00C0 > 0x034C 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_RX_DATA0__EPDC_SDCE040x00C4 > 0x0350 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_RX_DATA1__EPDC_SDCE050x00C8 > 0x0354 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_RX_EN__EPDC_SDCE06 0x00CC > 0x0358 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_TX_DATA0__EPDC_SDCE070x00D0 > 0x035C 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_TX_DATA1__EPDC_SDCE080x00D4 > 0x0360 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_TX_EN__EPDC_SDCE09 0x00D8 > 0x0364 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_TX_CLK__EPDC_SDOED 0x00DC > 0x0368 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_RX_ER__EPDC_SDOEZ0x00E0 > 0x036C 0x 0x9 0x0 > #define MX6ULL_PAD_ENET2_RX_DATA0__EPDC_SDDO080x00E4 > 0x0370 0x 0x9 0x0 > #define MX6ULL_PAD_ENET2_RX_DATA1__EPDC_SDDO090x00E8 > 0x0374 0x 0x9 0x0 > #define MX6ULL_PAD_ENET2_RX_EN__EPDC_SDDO10 0x00EC > 0x0378 0x 0x9 0x0 > @@ -57,6 +72,8 @@ > #define MX6ULL_PAD_LCD_DATA16__EPDC_GDCLK 0x0158 > 0x03E4 0x 0x9 0x0 > #define MX6ULL_PAD_LCD_DATA17__EPDC_GDSP 0x015C > 0x03E8 0x 0x9 0x0 > #define MX6ULL_PAD_LCD_DATA21__EPDC_SDCE1 0x016C > 0x03F8 0x 0x9 0x0 > +#define MX6ULL_PAD_LCD_DATA22__EPDC_SDCE020x0170 > 0x03FC 0x 0x9 0x0 > +#define MX6ULL_PAD_LCD_DATA23__EPDC_SDCE030x0174 > 0x0400 0x 0x9 0x0 > #define MX6ULL_PAD_CSI_MCLK__ESAI_TX3_RX2 0x01D4 > 0x0460 0x 0x9 0x0 > #define MX6ULL_PAD_CSI_PIXCLK__ESAI_TX2_RX3 0x01D8 > 0x0464 0x 0x9 0x0 > #define MX6ULL_PAD_CSI_VSYNC__ESAI_TX4_RX10x01DC > 0x0468 0x 0x9 0x0 > -- > 2.7.4 >
Re: [PATCH] ARM: dts: imx6ull: update iomux header
Add Sébastien for a cross check. Shawn On Thu, Aug 30, 2018 at 01:20:05PM +0800, Anson Huang wrote: > Update i.MX6ULL iomux header according to latest reference > manual Rev.1, 11/2017. > > Signed-off-by: Anson Huang > --- > arch/arm/boot/dts/imx6ull-pinfunc.h | 21 +++-- > 1 file changed, 19 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h > b/arch/arm/boot/dts/imx6ull-pinfunc.h > index 3c12a6f..a282a31 100644 > --- a/arch/arm/boot/dts/imx6ull-pinfunc.h > +++ b/arch/arm/boot/dts/imx6ull-pinfunc.h > @@ -27,10 +27,25 @@ > #define MX6UL_PAD_CSI_DATA02__UART5_DCE_RTS 0x01EC > 0x0478 0x0640 0x8 0x7 > > /* signals for i.MX6ULL only */ > +#define MX6ULL_PAD_UART1_TX_DATA__UART5_DCE_TX0x0084 > 0x0310 0x 0x9 0x0 > #define MX6ULL_PAD_UART1_TX_DATA__UART5_DTE_RX0x0084 > 0x0310 0x0644 0x9 0x4 > #define MX6ULL_PAD_UART1_RX_DATA__UART5_DCE_RX0x0088 > 0x0314 0x0644 0x9 0x5 > -#define MX6ULL_PAD_UART1_CTS_B__UART5_DCE_RTS 0x008C > 0x0318 0x0640 0x9 0x3 > -#define MX6ULL_PAD_UART1_RTS_B__UART5_DTE_RTS 0x0090 > 0x031C 0x0640 0x9 0x4 > +#define MX6ULL_PAD_UART1_RX_DATA__UART5_DTE_TX0x0088 > 0x0314 0x 0x9 0x0 > +#define MX6ULL_PAD_UART1_CTS_B__UART5_DCE_CTS 0x008C > 0x0318 0x 0x9 0x0 > +#define MX6ULL_PAD_UART1_CTS_B__UART5_DTE_RTS 0x008C > 0x0318 0x0640 0x9 0x3 > +#define MX6ULL_PAD_UART1_RTS_B__UART5_DCE_RTS 0x0090 > 0x031C 0x0640 0x9 0x4 > +#define MX6ULL_PAD_UART1_RTS_B__UART5_DTE_CTS 0x0090 > 0x031C 0x 0x9 0x0 > +#define MX6ULL_PAD_UART4_RX_DATA__EPDC_PWRCTRL01 0x00B8 > 0x0344 0x 0x9 0x0 > +#define MX6ULL_PAD_UART5_TX_DATA__EPDC_PWRCTRL02 0x00BC > 0x0348 0x 0x9 0x0 > +#define MX6ULL_PAD_UART5_RX_DATA__EPDC_PWRCTRL03 0x00C0 > 0x034C 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_RX_DATA0__EPDC_SDCE040x00C4 > 0x0350 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_RX_DATA1__EPDC_SDCE050x00C8 > 0x0354 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_RX_EN__EPDC_SDCE06 0x00CC > 0x0358 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_TX_DATA0__EPDC_SDCE070x00D0 > 0x035C 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_TX_DATA1__EPDC_SDCE080x00D4 > 0x0360 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_TX_EN__EPDC_SDCE09 0x00D8 > 0x0364 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_TX_CLK__EPDC_SDOED 0x00DC > 0x0368 0x 0x9 0x0 > +#define MX6ULL_PAD_ENET1_RX_ER__EPDC_SDOEZ0x00E0 > 0x036C 0x 0x9 0x0 > #define MX6ULL_PAD_ENET2_RX_DATA0__EPDC_SDDO080x00E4 > 0x0370 0x 0x9 0x0 > #define MX6ULL_PAD_ENET2_RX_DATA1__EPDC_SDDO090x00E8 > 0x0374 0x 0x9 0x0 > #define MX6ULL_PAD_ENET2_RX_EN__EPDC_SDDO10 0x00EC > 0x0378 0x 0x9 0x0 > @@ -57,6 +72,8 @@ > #define MX6ULL_PAD_LCD_DATA16__EPDC_GDCLK 0x0158 > 0x03E4 0x 0x9 0x0 > #define MX6ULL_PAD_LCD_DATA17__EPDC_GDSP 0x015C > 0x03E8 0x 0x9 0x0 > #define MX6ULL_PAD_LCD_DATA21__EPDC_SDCE1 0x016C > 0x03F8 0x 0x9 0x0 > +#define MX6ULL_PAD_LCD_DATA22__EPDC_SDCE020x0170 > 0x03FC 0x 0x9 0x0 > +#define MX6ULL_PAD_LCD_DATA23__EPDC_SDCE030x0174 > 0x0400 0x 0x9 0x0 > #define MX6ULL_PAD_CSI_MCLK__ESAI_TX3_RX2 0x01D4 > 0x0460 0x 0x9 0x0 > #define MX6ULL_PAD_CSI_PIXCLK__ESAI_TX2_RX3 0x01D8 > 0x0464 0x 0x9 0x0 > #define MX6ULL_PAD_CSI_VSYNC__ESAI_TX4_RX10x01DC > 0x0468 0x 0x9 0x0 > -- > 2.7.4 >
Re: [PATCH AUTOSEL 4.18 068/131] PCI: mobiveil: Add missing ../pci.h include
Acked-by: Subrahmanya Lingappa
Thanks.
On Sun, Sep 2, 2018 at 6:34 PM Sasha Levin
wrote:
>
> From: Lorenzo Pieralisi
>
> [ Upstream commit d3743012230f8dab30d47caba1f2ee9e382385e7 ]
>
> PCI mobiveil host controller driver currently fails to compile
> with the following error:
>
> drivers/pci/controller/pcie-mobiveil.c: In function
> 'mobiveil_pcie_probe':
> drivers/pci/controller/pcie-mobiveil.c:788:8: error: implicit
> declaration of function 'devm_of_pci_get_host_bridge_resources'; did you
> mean 'pci_get_host_bridge_device'?
> [-Werror=implicit-function-declaration]
> ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> ^
> pci_get_host_bridge_device
>
> Add the missing include file to pull in the required function declaration.
>
> Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP
> driver")
> Signed-off-by: Lorenzo Pieralisi
> Cc: Bjorn Helgaas
> Cc: Subrahmanya Lingappa
> Signed-off-by: Sasha Levin
> ---
> drivers/pci/controller/pcie-mobiveil.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index cf0aa7cee5b0..2c81be37b010 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -23,6 +23,8 @@
> #include
> #include
>
> +#include "../pci.h"
> +
> /* register offsets and bit positions */
>
> /*
> --
> 2.17.1
Re: [PATCH AUTOSEL 4.18 068/131] PCI: mobiveil: Add missing ../pci.h include
Acked-by: Subrahmanya Lingappa
Thanks.
On Sun, Sep 2, 2018 at 6:34 PM Sasha Levin
wrote:
>
> From: Lorenzo Pieralisi
>
> [ Upstream commit d3743012230f8dab30d47caba1f2ee9e382385e7 ]
>
> PCI mobiveil host controller driver currently fails to compile
> with the following error:
>
> drivers/pci/controller/pcie-mobiveil.c: In function
> 'mobiveil_pcie_probe':
> drivers/pci/controller/pcie-mobiveil.c:788:8: error: implicit
> declaration of function 'devm_of_pci_get_host_bridge_resources'; did you
> mean 'pci_get_host_bridge_device'?
> [-Werror=implicit-function-declaration]
> ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> ^
> pci_get_host_bridge_device
>
> Add the missing include file to pull in the required function declaration.
>
> Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP
> driver")
> Signed-off-by: Lorenzo Pieralisi
> Cc: Bjorn Helgaas
> Cc: Subrahmanya Lingappa
> Signed-off-by: Sasha Levin
> ---
> drivers/pci/controller/pcie-mobiveil.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index cf0aa7cee5b0..2c81be37b010 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -23,6 +23,8 @@
> #include
> #include
>
> +#include "../pci.h"
> +
> /* register offsets and bit positions */
>
> /*
> --
> 2.17.1
Re: [PATCH AUTOSEL 4.18 069/131] PCI: mobiveil: Fix struct mobiveil_pcie.pcie_reg_base address type
Acked-by: Subrahmanya Lingappa
Thanks.
On Sun, Sep 2, 2018 at 6:34 PM Sasha Levin
wrote:
>
> From: Lorenzo Pieralisi
>
> [ Upstream commit af3f606e0bbb6d811c50b7b90fe324b07fb7cab8 ]
>
> The field pcie_reg_base in struct mobiveil_pcie represents a physical
> address so it should be of phys_addr_t type rather than void __iomem*;
> this results in the following compilation warnings:
>
> drivers/pci/controller/pcie-mobiveil.c: In function
> 'mobiveil_pcie_parse_dt':
> drivers/pci/controller/pcie-mobiveil.c:326:22: warning: assignment makes
> pointer from integer without a cast [-Wint-conversion]
> pcie->pcie_reg_base = res->start;
> ^
> drivers/pci/controller/pcie-mobiveil.c: In function
> 'mobiveil_pcie_enable_msi':
> drivers/pci/controller/pcie-mobiveil.c:485:25: warning: initialization
> makes integer from pointer without a cast [-Wint-conversion]
> phys_addr_t msg_addr = pcie->pcie_reg_base;
> ^~~~
> drivers/pci/controller/pcie-mobiveil.c: In function
> 'mobiveil_compose_msi_msg':
> drivers/pci/controller/pcie-mobiveil.c:640:21: warning: initialization
> makes integer from pointer without a cast [-Wint-conversion]
> phys_addr_t addr = pcie->pcie_reg_base + (data->hwirq * sizeof(int));
>
> Fix the type and with it the compilation warnings.
>
> Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP
> driver")
> Signed-off-by: Lorenzo Pieralisi
> Cc: Bjorn Helgaas
> Cc: Subrahmanya Lingappa
> Signed-off-by: Sasha Levin
> ---
> drivers/pci/controller/pcie-mobiveil.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index 2c81be37b010..a939e8d31735 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -132,7 +132,7 @@ struct mobiveil_pcie {
> void __iomem *config_axi_slave_base;/* endpoint config base */
> void __iomem *csr_axi_slave_base; /* root port config base */
> void __iomem *apb_csr_base; /* MSI register base */
> - void __iomem *pcie_reg_base;/* Physical PCIe Controller Base */
> + phys_addr_t pcie_reg_base; /* Physical PCIe Controller Base */
> struct irq_domain *intx_domain;
> raw_spinlock_t intx_mask_lock;
> int irq;
> --
> 2.17.1
Re: [PATCH AUTOSEL 4.18 069/131] PCI: mobiveil: Fix struct mobiveil_pcie.pcie_reg_base address type
Acked-by: Subrahmanya Lingappa
Thanks.
On Sun, Sep 2, 2018 at 6:34 PM Sasha Levin
wrote:
>
> From: Lorenzo Pieralisi
>
> [ Upstream commit af3f606e0bbb6d811c50b7b90fe324b07fb7cab8 ]
>
> The field pcie_reg_base in struct mobiveil_pcie represents a physical
> address so it should be of phys_addr_t type rather than void __iomem*;
> this results in the following compilation warnings:
>
> drivers/pci/controller/pcie-mobiveil.c: In function
> 'mobiveil_pcie_parse_dt':
> drivers/pci/controller/pcie-mobiveil.c:326:22: warning: assignment makes
> pointer from integer without a cast [-Wint-conversion]
> pcie->pcie_reg_base = res->start;
> ^
> drivers/pci/controller/pcie-mobiveil.c: In function
> 'mobiveil_pcie_enable_msi':
> drivers/pci/controller/pcie-mobiveil.c:485:25: warning: initialization
> makes integer from pointer without a cast [-Wint-conversion]
> phys_addr_t msg_addr = pcie->pcie_reg_base;
> ^~~~
> drivers/pci/controller/pcie-mobiveil.c: In function
> 'mobiveil_compose_msi_msg':
> drivers/pci/controller/pcie-mobiveil.c:640:21: warning: initialization
> makes integer from pointer without a cast [-Wint-conversion]
> phys_addr_t addr = pcie->pcie_reg_base + (data->hwirq * sizeof(int));
>
> Fix the type and with it the compilation warnings.
>
> Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP
> driver")
> Signed-off-by: Lorenzo Pieralisi
> Cc: Bjorn Helgaas
> Cc: Subrahmanya Lingappa
> Signed-off-by: Sasha Levin
> ---
> drivers/pci/controller/pcie-mobiveil.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index 2c81be37b010..a939e8d31735 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -132,7 +132,7 @@ struct mobiveil_pcie {
> void __iomem *config_axi_slave_base;/* endpoint config base */
> void __iomem *csr_axi_slave_base; /* root port config base */
> void __iomem *apb_csr_base; /* MSI register base */
> - void __iomem *pcie_reg_base;/* Physical PCIe Controller Base */
> + phys_addr_t pcie_reg_base; /* Physical PCIe Controller Base */
> struct irq_domain *intx_domain;
> raw_spinlock_t intx_mask_lock;
> int irq;
> --
> 2.17.1
Re: [PATCH v2 1/2] iio: adc: sc27xx: Add raw data support
Hi Jonathan, On 2 September 2018 at 16:51, Jonathan Cameron wrote: > On Wed, 29 Aug 2018 14:04:04 +0800 > Baolin Wang wrote: > >> The headset device will use channel 20 of ADC controller to detect events, >> but it needs the raw ADC data to do conversion according to its own formula. >> >> Thus we should configure the channel mask separately and configure channel >> 20 as IIO_CHAN_INFO_RAW, as well as adding raw data read support. >> >> Signed-off-by: Baolin Wang > I'm still a little unclear on whether there is fundamentally something > different > about this channel or whether this is just a policy decision for particular > (possibly all) board. For now we'll go with this change, but if anyone > screams > we will have to then go the nasty route of supporting both processed and raw > for channel 20. Until now, channel 20 is always used for the headset on the SC27xx series PMICs. Yes, this is a policy decision, but for all the SC27xx series PMICs. > > Applied to the togreg branch of iio.git and pushed out as testing for the > autobuilders to play with it. Thanks. -- Baolin Wang Best Regards
Re: [PATCH v2 1/2] iio: adc: sc27xx: Add raw data support
Hi Jonathan, On 2 September 2018 at 16:51, Jonathan Cameron wrote: > On Wed, 29 Aug 2018 14:04:04 +0800 > Baolin Wang wrote: > >> The headset device will use channel 20 of ADC controller to detect events, >> but it needs the raw ADC data to do conversion according to its own formula. >> >> Thus we should configure the channel mask separately and configure channel >> 20 as IIO_CHAN_INFO_RAW, as well as adding raw data read support. >> >> Signed-off-by: Baolin Wang > I'm still a little unclear on whether there is fundamentally something > different > about this channel or whether this is just a policy decision for particular > (possibly all) board. For now we'll go with this change, but if anyone > screams > we will have to then go the nasty route of supporting both processed and raw > for channel 20. Until now, channel 20 is always used for the headset on the SC27xx series PMICs. Yes, this is a policy decision, but for all the SC27xx series PMICs. > > Applied to the togreg branch of iio.git and pushed out as testing for the > autobuilders to play with it. Thanks. -- Baolin Wang Best Regards
Re: [PATCH] bus: imx-weim: drop unnecessary DT node name NULL check
On Wed, Aug 29, 2018 at 03:02:58PM -0500, Rob Herring wrote: > Checking the child node names is pointless as the DT node name can > never be NULL, so remove it. > > Cc: Shawn Guo > Signed-off-by: Rob Herring Applied, thanks.
Re: [PATCH] bus: imx-weim: drop unnecessary DT node name NULL check
On Wed, Aug 29, 2018 at 03:02:58PM -0500, Rob Herring wrote: > Checking the child node names is pointless as the DT node name can > never be NULL, so remove it. > > Cc: Shawn Guo > Signed-off-by: Rob Herring Applied, thanks.
Re: [PATCH v2] fs: Convert return type int to vm_fault_t
Hi Souptick, On Thu, 30 Aug 2018 16:33:52 -0700, Andrew Morton wrote: > On Thu, 30 Aug 2018 22:55:47 +0530 Souptick Joarder wrote: > >> Return type for fault handlers in ext4 and nilfs are >> changed to use vm_fault_t. >> >> Return type of block_page_mkwrite() is changed from >> int to vm_fault_t. The function signature of >> block_page_mkwrite() is changed to add one new parameter >> int *err. This will provide a way for caller functions >> to get error value along with return value and use it >> further. >> >> Return type of block_page_mkwrite_return() is also changed >> to use new vm_fault_t type. >> --- a/fs/nilfs2/file.c >> +++ b/fs/nilfs2/file.c >> @@ -51,13 +51,14 @@ int nilfs_sync_file(struct file *file, loff_t start, >> loff_t end, int datasync) >> return err; >> } >> >> -static int nilfs_page_mkwrite(struct vm_fault *vmf) >> +static vm_fault_t nilfs_page_mkwrite(struct vm_fault *vmf) > > nilfs_page_mkwrite() already has return type vm_fault_t in Linus's > kernel, due to the now-merged > fs-nilfs2-adding-new-return-type-vm_fault_t.patch. Looks like a simple > fix. In the first patch in this thread, this return type change was excluded correctly for nilfs_page_mkwrite() though the changelog was inaccurate in that sense. Please confirm your base point of the revised patch. Regards, Ryusuke Konishi > > I'm beginning to feel vm_fault_t exhaustion. Please remind me what > benefit we're going to get out of all this churn? > >> >> ... >>
Re: [PATCH v2] fs: Convert return type int to vm_fault_t
Hi Souptick, On Thu, 30 Aug 2018 16:33:52 -0700, Andrew Morton wrote: > On Thu, 30 Aug 2018 22:55:47 +0530 Souptick Joarder wrote: > >> Return type for fault handlers in ext4 and nilfs are >> changed to use vm_fault_t. >> >> Return type of block_page_mkwrite() is changed from >> int to vm_fault_t. The function signature of >> block_page_mkwrite() is changed to add one new parameter >> int *err. This will provide a way for caller functions >> to get error value along with return value and use it >> further. >> >> Return type of block_page_mkwrite_return() is also changed >> to use new vm_fault_t type. >> --- a/fs/nilfs2/file.c >> +++ b/fs/nilfs2/file.c >> @@ -51,13 +51,14 @@ int nilfs_sync_file(struct file *file, loff_t start, >> loff_t end, int datasync) >> return err; >> } >> >> -static int nilfs_page_mkwrite(struct vm_fault *vmf) >> +static vm_fault_t nilfs_page_mkwrite(struct vm_fault *vmf) > > nilfs_page_mkwrite() already has return type vm_fault_t in Linus's > kernel, due to the now-merged > fs-nilfs2-adding-new-return-type-vm_fault_t.patch. Looks like a simple > fix. In the first patch in this thread, this return type change was excluded correctly for nilfs_page_mkwrite() though the changelog was inaccurate in that sense. Please confirm your base point of the revised patch. Regards, Ryusuke Konishi > > I'm beginning to feel vm_fault_t exhaustion. Please remind me what > benefit we're going to get out of all this churn? > >> >> ... >>
[PATCH v3] membarrier_test: work in progress
Shuah,
This is a draft only. I will remove summary from the top, run checkers,
etc. Im thinking in replacing membarrier_test entirely with this code
(compatible to existing one). Right now, this code:
- allows each test to succeed, fail or be skipped independently
- allows each test to be tested even when not supported (force option)
- considers false negatives and false positives on every case
- can be extended easily
Right now, just to show as an example, it gives us:
TAP version 13
ok 1 sys_membarrier(): cmd_query succeeded.
ok 2 sys_membarrier(): bad_cmd failed as expected.
ok 3 sys_membarrier(): cmd_with_flags_set failed as expected.
ok 4 sys_membarrier(): cmd_global succeeded.
Pass 4 Fail 0 Xfail 0 Xpass 0 Skip 0 Error 0
1..4
Are you okay with such move ? Only big TODO here is adding all covered
tests in the test array (easy move), testing all combinations with all
supported kernel versions (lab already ready) and suggesting it to you,
replacing membarrier_test.c.
PS: This is pretty close to how a LTP test would be, using their new
API, but, since it addresses your concerns and seems like a
simple/clean, code, I decided to suggest it as a replacement here (and
it also fixes the issue with this test and LTS kernels).
---
tools/testing/selftests/membarrier/Makefile | 2 +-
.../selftests/membarrier/membarrier_test2.c | 180 ++
2 files changed, 181 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/membarrier/membarrier_test2.c
diff --git a/tools/testing/selftests/membarrier/Makefile
b/tools/testing/selftests/membarrier/Makefile
index 02845532b059..3d44d4cd3a9d 100644
--- a/tools/testing/selftests/membarrier/Makefile
+++ b/tools/testing/selftests/membarrier/Makefile
@@ -1,6 +1,6 @@
CFLAGS += -g -I../../../../usr/include/
-TEST_GEN_PROGS := membarrier_test
+TEST_GEN_PROGS := membarrier_test membarrier_test2
include ../lib.mk
diff --git a/tools/testing/selftests/membarrier/membarrier_test2.c
b/tools/testing/selftests/membarrier/membarrier_test2.c
new file mode 100644
index ..8fa1be6156fb
--- /dev/null
+++ b/tools/testing/selftests/membarrier/membarrier_test2.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+
+#include "../kselftest.h"
+/*
+ MEMBARRIER_CMD_QUERY
+ returns membarrier_cmd with supported features
+ MEMBARRIER_CMD_GLOBAL
+ returns 0
+ EINVAL = if nohz_full is enabled
+ MEMBARRIER_CMD_GLOBAL_EXPEDITED
+ returns 0
+ MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED
+ returns 0
+ MEMBARRIER_CMD_PRIVATE_EXPEDITED
+ returns 0
+ EINVAL = if CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE is not enabled
+ EPERM = if process did not register for PRIVATE_EXPEDITED
+ MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED
+ returns 0
+ EINVAL = if CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE is not enabled
+ MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE
+ returns 0
+ EINVAL = if CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE is not enabled
+ EPERM = if process did not register for PRIVATE_EXPEDITED
+ MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE
+ returns 0
+ EINVAL = if CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE is not enabled
+*/
+
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+struct memb_tests {
+ char testname[80];
+ int command;
+ int flags;
+ int exp_ret;
+ int exp_errno;
+ int supported;
+ int force;
+};
+
+struct memb_tests mbt[] = {
+ {
+.testname = "bad_cmd\0",
+.command = -1,
+.exp_ret = -1,
+.exp_errno = EINVAL,
+.supported = 1,
+},
+ {
+.testname = "cmd_with_flags_set\0",
+.command = MEMBARRIER_CMD_QUERY,
+.flags = 1,
+.exp_ret = -1,
+.exp_errno = EINVAL,
+.supported = 1,
+},
+ {
+.testname = "cmd_global\0",
+.command = MEMBARRIER_CMD_GLOBAL,
+.flags = 0,
+.exp_ret = 0,
+},
+};
+
+static void info_passed_ok(struct memb_tests test)
+{
+ ksft_test_result_pass("sys_membarrier(): %s succeeded.\n",
+ test.testname);
+}
+
+static void info_passed_unexpectedly(struct memb_tests test)
+{
+ ksft_test_result_fail("sys_membarrier(): %s passed unexpectedly. "
+ "ret = %d with errno %d were expected.\n",
+ test.testname, test.exp_ret, test.exp_errno);
+}
+
+static void info_failed_ok(struct memb_tests test)
+{
+ ksft_test_result_pass("sys_membarrier(): %s failed as expected.\n",
+ test.testname);
+}
+
+static void info_failed_not_ok(struct memb_tests test, int gotret, int goterr)
+{
+
[PATCH v3] membarrier_test: work in progress
Shuah,
This is a draft only. I will remove summary from the top, run checkers,
etc. Im thinking in replacing membarrier_test entirely with this code
(compatible to existing one). Right now, this code:
- allows each test to succeed, fail or be skipped independently
- allows each test to be tested even when not supported (force option)
- considers false negatives and false positives on every case
- can be extended easily
Right now, just to show as an example, it gives us:
TAP version 13
ok 1 sys_membarrier(): cmd_query succeeded.
ok 2 sys_membarrier(): bad_cmd failed as expected.
ok 3 sys_membarrier(): cmd_with_flags_set failed as expected.
ok 4 sys_membarrier(): cmd_global succeeded.
Pass 4 Fail 0 Xfail 0 Xpass 0 Skip 0 Error 0
1..4
Are you okay with such move ? Only big TODO here is adding all covered
tests in the test array (easy move), testing all combinations with all
supported kernel versions (lab already ready) and suggesting it to you,
replacing membarrier_test.c.
PS: This is pretty close to how a LTP test would be, using their new
API, but, since it addresses your concerns and seems like a
simple/clean, code, I decided to suggest it as a replacement here (and
it also fixes the issue with this test and LTS kernels).
---
tools/testing/selftests/membarrier/Makefile | 2 +-
.../selftests/membarrier/membarrier_test2.c | 180 ++
2 files changed, 181 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/membarrier/membarrier_test2.c
diff --git a/tools/testing/selftests/membarrier/Makefile
b/tools/testing/selftests/membarrier/Makefile
index 02845532b059..3d44d4cd3a9d 100644
--- a/tools/testing/selftests/membarrier/Makefile
+++ b/tools/testing/selftests/membarrier/Makefile
@@ -1,6 +1,6 @@
CFLAGS += -g -I../../../../usr/include/
-TEST_GEN_PROGS := membarrier_test
+TEST_GEN_PROGS := membarrier_test membarrier_test2
include ../lib.mk
diff --git a/tools/testing/selftests/membarrier/membarrier_test2.c
b/tools/testing/selftests/membarrier/membarrier_test2.c
new file mode 100644
index ..8fa1be6156fb
--- /dev/null
+++ b/tools/testing/selftests/membarrier/membarrier_test2.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+
+#include "../kselftest.h"
+/*
+ MEMBARRIER_CMD_QUERY
+ returns membarrier_cmd with supported features
+ MEMBARRIER_CMD_GLOBAL
+ returns 0
+ EINVAL = if nohz_full is enabled
+ MEMBARRIER_CMD_GLOBAL_EXPEDITED
+ returns 0
+ MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED
+ returns 0
+ MEMBARRIER_CMD_PRIVATE_EXPEDITED
+ returns 0
+ EINVAL = if CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE is not enabled
+ EPERM = if process did not register for PRIVATE_EXPEDITED
+ MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED
+ returns 0
+ EINVAL = if CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE is not enabled
+ MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE
+ returns 0
+ EINVAL = if CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE is not enabled
+ EPERM = if process did not register for PRIVATE_EXPEDITED
+ MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE
+ returns 0
+ EINVAL = if CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE is not enabled
+*/
+
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+struct memb_tests {
+ char testname[80];
+ int command;
+ int flags;
+ int exp_ret;
+ int exp_errno;
+ int supported;
+ int force;
+};
+
+struct memb_tests mbt[] = {
+ {
+.testname = "bad_cmd\0",
+.command = -1,
+.exp_ret = -1,
+.exp_errno = EINVAL,
+.supported = 1,
+},
+ {
+.testname = "cmd_with_flags_set\0",
+.command = MEMBARRIER_CMD_QUERY,
+.flags = 1,
+.exp_ret = -1,
+.exp_errno = EINVAL,
+.supported = 1,
+},
+ {
+.testname = "cmd_global\0",
+.command = MEMBARRIER_CMD_GLOBAL,
+.flags = 0,
+.exp_ret = 0,
+},
+};
+
+static void info_passed_ok(struct memb_tests test)
+{
+ ksft_test_result_pass("sys_membarrier(): %s succeeded.\n",
+ test.testname);
+}
+
+static void info_passed_unexpectedly(struct memb_tests test)
+{
+ ksft_test_result_fail("sys_membarrier(): %s passed unexpectedly. "
+ "ret = %d with errno %d were expected.\n",
+ test.testname, test.exp_ret, test.exp_errno);
+}
+
+static void info_failed_ok(struct memb_tests test)
+{
+ ksft_test_result_pass("sys_membarrier(): %s failed as expected.\n",
+ test.testname);
+}
+
+static void info_failed_not_ok(struct memb_tests test, int gotret, int goterr)
+{
+
Re: Access to non-RAM pages
On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt wrote: > > Still, I can potentially see an issue with DEBUG_PAGEALLOC An unmapped page isn't a problem. That's what the whole load_unaligned_zeropad() is about: it's ok to take a fault on the part that crosses a page, and we'll just fill the value with zeroes (that's the "zeropad" part). So as long as it's rare (and it is), it's all fine. That said, I think we turn off for DEBUG_PAGEALLOC simply because it's not rare _enough_. And vmalloc() should actually be safe too, simply because I think we strive for a guard page between vmalloc areas. So only a *mapped* page after the page that matters, and only if it's something you can't read without side effects. Which basically doesn't happen on x86 in reality. BIOSes just don't put MMIO right after the last page of RAM. I think this is why it only triggered on Xen, due to some crazy "Xen reacts badly" case where we do the speculation into a balloon address. So _practically_ this is just a Xen bug, nothing more. But since in _theory_ you could have MMIO abut regular RAM directly, it's worth maybe making sure it's purely theory. Linus
Re: Access to non-RAM pages
On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt wrote: > > Still, I can potentially see an issue with DEBUG_PAGEALLOC An unmapped page isn't a problem. That's what the whole load_unaligned_zeropad() is about: it's ok to take a fault on the part that crosses a page, and we'll just fill the value with zeroes (that's the "zeropad" part). So as long as it's rare (and it is), it's all fine. That said, I think we turn off for DEBUG_PAGEALLOC simply because it's not rare _enough_. And vmalloc() should actually be safe too, simply because I think we strive for a guard page between vmalloc areas. So only a *mapped* page after the page that matters, and only if it's something you can't read without side effects. Which basically doesn't happen on x86 in reality. BIOSes just don't put MMIO right after the last page of RAM. I think this is why it only triggered on Xen, due to some crazy "Xen reacts badly" case where we do the speculation into a balloon address. So _practically_ this is just a Xen bug, nothing more. But since in _theory_ you could have MMIO abut regular RAM directly, it's worth maybe making sure it's purely theory. Linus
linux-next: build warning after merge of the staging tree
Hi Greg,
After merging the staging tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
WARNING: drivers/staging/rtl8192u/r8192u_usb: 'dot11d_init' exported twice.
Previous export was in drivers/staging/rtl8192e/rtllib.ko
Introduced by commit
c01f06b7506f ("staging:rtl8192u: Rename Dot11d_Init - Style")
--
Cheers,
Stephen Rothwell
pgpRSaiDWtPlB.pgp
Description: OpenPGP digital signature
Re: Access to non-RAM pages
On Sat, 2018-09-01 at 11:06 -0700, Linus Torvalds wrote:
> [ Adding a few new people the the cc.
>
> The issue is the worry about software-speculative accesses (ie
> things like CONFIG_DCACHE_WORD_ACCESS - not talking about the hw
> speculation now) accessing past RAM into possibly contiguous IO ]
>
> On Sat, Sep 1, 2018 at 10:27 AM Linus Torvalds
> wrote:
> >
> > If you have a machine with RAM that touches IO, you need to disable
> > the last page, exactly the same way we disable and marked reserved the
> > first page at zero.
So I missed the departure of that train ... stupid question, with
CONFIG_DCACHE_WORD_ACCESS, if that can be unaligned (I assume it can),
what prevents it from crossing into a non-mapped page (not even IO) and
causing an oops ? Looking at a random user in fs/dcache.c its not a
uaccess-style read with recovery Or am I missing somethign obvious
here ?
IE, should we "reserve" the last page of any memory region (maybe mark
it read-only) to avoid this along with avoiding leakage into IO space ?
> > I thought we already did that.
>
> We don't seem to do that.
>
> And it's not just the last page, it's _any_ last page in a region that
> bumps up to IO. That's actually much more common in the low 4G area on
> PC's, I suspect, although the reserved BIOS ranges always tend to be
> there.
What makes IO more "wrong" than oopsing due to the page not being
mapped ?
> I suspect it should be trivial to do - maybe in
> e820__memblock_setup()? That's where we already trim partial pages
> etc.
>
> In fact, I think this might be done as an extension of commit
> 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into
> memblock.reserved"), except making sure that non-RAM regions mark one
> page _previous_ as reserved too.
>
> I assume memory hotplug might have the same issue, and checking
> whether ARM64 and powerpc perhaps might have already done something
> like this (or might need to add it).
>
> We discussed long ago the case of user space mapping IO in user space,
> and decided we didn't care. But the kernel should probably explicitly
> make sure we don't either, even if I can't recall having ever seen a
> machine that actually maps IO contiguously to RAM. The layout always
> tends to end up having holes anyway.
Can't we put the safety in generic memblock ? IE, don't hand out an
allocation that contain the last page of a "block" and handle that last
page in the memblock->buddy transition rather than in arch specific
code ?
Cheers,
Ben.
linux-next: build warning after merge of the staging tree
Hi Greg,
After merging the staging tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
WARNING: drivers/staging/rtl8192u/r8192u_usb: 'dot11d_init' exported twice.
Previous export was in drivers/staging/rtl8192e/rtllib.ko
Introduced by commit
c01f06b7506f ("staging:rtl8192u: Rename Dot11d_Init - Style")
--
Cheers,
Stephen Rothwell
pgpRSaiDWtPlB.pgp
Description: OpenPGP digital signature
Re: Access to non-RAM pages
On Sat, 2018-09-01 at 11:06 -0700, Linus Torvalds wrote:
> [ Adding a few new people the the cc.
>
> The issue is the worry about software-speculative accesses (ie
> things like CONFIG_DCACHE_WORD_ACCESS - not talking about the hw
> speculation now) accessing past RAM into possibly contiguous IO ]
>
> On Sat, Sep 1, 2018 at 10:27 AM Linus Torvalds
> wrote:
> >
> > If you have a machine with RAM that touches IO, you need to disable
> > the last page, exactly the same way we disable and marked reserved the
> > first page at zero.
So I missed the departure of that train ... stupid question, with
CONFIG_DCACHE_WORD_ACCESS, if that can be unaligned (I assume it can),
what prevents it from crossing into a non-mapped page (not even IO) and
causing an oops ? Looking at a random user in fs/dcache.c its not a
uaccess-style read with recovery Or am I missing somethign obvious
here ?
IE, should we "reserve" the last page of any memory region (maybe mark
it read-only) to avoid this along with avoiding leakage into IO space ?
> > I thought we already did that.
>
> We don't seem to do that.
>
> And it's not just the last page, it's _any_ last page in a region that
> bumps up to IO. That's actually much more common in the low 4G area on
> PC's, I suspect, although the reserved BIOS ranges always tend to be
> there.
What makes IO more "wrong" than oopsing due to the page not being
mapped ?
> I suspect it should be trivial to do - maybe in
> e820__memblock_setup()? That's where we already trim partial pages
> etc.
>
> In fact, I think this might be done as an extension of commit
> 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into
> memblock.reserved"), except making sure that non-RAM regions mark one
> page _previous_ as reserved too.
>
> I assume memory hotplug might have the same issue, and checking
> whether ARM64 and powerpc perhaps might have already done something
> like this (or might need to add it).
>
> We discussed long ago the case of user space mapping IO in user space,
> and decided we didn't care. But the kernel should probably explicitly
> make sure we don't either, even if I can't recall having ever seen a
> machine that actually maps IO contiguously to RAM. The layout always
> tends to end up having holes anyway.
Can't we put the safety in generic memblock ? IE, don't hand out an
allocation that contain the last page of a "block" and handle that last
page in the memblock->buddy transition rather than in arch specific
code ?
Cheers,
Ben.
Re: Access to non-RAM pages
On Sun, 2018-09-02 at 18:42 -0700, Linus Torvalds wrote: > On Sun, Sep 2, 2018 at 6:38 PM Linus Torvalds > wrote: > > It's not used for vmalloc stuff. It's just regular kmalloc(). > > Just to clarify .. that's true of the dcache stuff. > > The strscpy case actually explicitly limits things to page boundaries > and falls back to the byte-by-byte case after that. Ah ok, that makes sense. Still, I can potentially see an issue with DEBUG_PAGEALLOC Cheers, Ben.
Re: Access to non-RAM pages
On Sun, 2018-09-02 at 18:42 -0700, Linus Torvalds wrote: > On Sun, Sep 2, 2018 at 6:38 PM Linus Torvalds > wrote: > > It's not used for vmalloc stuff. It's just regular kmalloc(). > > Just to clarify .. that's true of the dcache stuff. > > The strscpy case actually explicitly limits things to page boundaries > and falls back to the byte-by-byte case after that. Ah ok, that makes sense. Still, I can potentially see an issue with DEBUG_PAGEALLOC Cheers, Ben.
Re: KMSAN: uninit-value in snd_midi_event_encode_byte
syzbot has found a reproducer for the following crash on: HEAD commit:28f0ca98eadf kmsan: don't instrument do_syscall_64() and _.. git tree: https://github.com/google/kmsan.git/master console output: https://syzkaller.appspot.com/x/log.txt?x=10556c9240 kernel config: https://syzkaller.appspot.com/x/.config?x=3431f03869413153 dashboard link: https://syzkaller.appspot.com/bug?extid=194dffdb8b22fc5d207a compiler: clang version 8.0.0 (trunk 339414) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=123a520a40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16068dc140 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+194dffdb8b22fc5d2...@syzkaller.appspotmail.com == BUG: KMSAN: uninit-value in snd_midi_event_encode_byte+0x569/0xff0 sound/core/seq/seq_midi_event.c:195 CPU: 1 PID: 1659 Comm: kworker/1:1H Not tainted 4.19.0-rc1+ #40 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events_highpri snd_vmidi_output_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x14b/0x190 lib/dump_stack.c:113 kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956 __msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645 snd_midi_event_encode_byte+0x569/0xff0 sound/core/seq/seq_midi_event.c:195 snd_vmidi_output_work+0x34e/0x5b0 sound/core/seq/seq_virmidi.c:161 process_one_work+0x1605/0x1f40 kernel/workqueue.c:2153 worker_thread+0x11a2/0x2590 kernel/workqueue.c:2296 kthread+0x465/0x4a0 kernel/kthread.c:247 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:416 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline] kmsan_save_stack mm/kmsan/kmsan.c:271 [inline] kmsan_internal_chain_origin+0x128/0x210 mm/kmsan/kmsan.c:573 __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:482 __snd_rawmidi_transmit_peek sound/core/rawmidi.c:1103 [inline] snd_rawmidi_transmit+0xa75/0xbf0 sound/core/rawmidi.c:1228 snd_vmidi_output_work+0x2ac/0x5b0 sound/core/seq/seq_virmidi.c:159 process_one_work+0x1605/0x1f40 kernel/workqueue.c:2153 worker_thread+0x11a2/0x2590 kernel/workqueue.c:2296 kthread+0x465/0x4a0 kernel/kthread.c:247 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:416 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline] kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:181 kmsan_kmalloc+0x98/0x100 mm/kmsan/kmsan_hooks.c:91 __kmalloc_node+0x7bf/0x11c0 mm/slub.c:3828 kmalloc_node include/linux/slab.h:555 [inline] kvmalloc_node+0x19d/0x3e0 mm/util.c:423 kvmalloc include/linux/mm.h:577 [inline] snd_rawmidi_runtime_create sound/core/rawmidi.c:132 [inline] open_substream+0x3c8/0xaa0 sound/core/rawmidi.c:276 rawmidi_open_priv+0x347/0x1000 sound/core/rawmidi.c:327 snd_rawmidi_open+0x7d4/0x1120 sound/core/rawmidi.c:424 soundcore_open+0x9be/0xa60 sound/sound_core.c:597 chrdev_open+0xc26/0xdb0 fs/char_dev.c:417 do_dentry_open+0xce6/0x1740 fs/open.c:771 vfs_open+0xaf/0xe0 fs/open.c:880 do_last fs/namei.c:3418 [inline] path_openat+0x1799/0x6870 fs/namei.c:3534 do_filp_open+0x259/0x610 fs/namei.c:3564 do_sys_open+0x630/0x940 fs/open.c:1063 __do_sys_open fs/open.c:1081 [inline] __se_sys_open+0xad/0xc0 fs/open.c:1076 __x64_sys_open+0x4a/0x70 fs/open.c:1076 do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 ==
Re: KMSAN: uninit-value in snd_midi_event_encode_byte
syzbot has found a reproducer for the following crash on: HEAD commit:28f0ca98eadf kmsan: don't instrument do_syscall_64() and _.. git tree: https://github.com/google/kmsan.git/master console output: https://syzkaller.appspot.com/x/log.txt?x=10556c9240 kernel config: https://syzkaller.appspot.com/x/.config?x=3431f03869413153 dashboard link: https://syzkaller.appspot.com/bug?extid=194dffdb8b22fc5d207a compiler: clang version 8.0.0 (trunk 339414) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=123a520a40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16068dc140 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+194dffdb8b22fc5d2...@syzkaller.appspotmail.com == BUG: KMSAN: uninit-value in snd_midi_event_encode_byte+0x569/0xff0 sound/core/seq/seq_midi_event.c:195 CPU: 1 PID: 1659 Comm: kworker/1:1H Not tainted 4.19.0-rc1+ #40 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events_highpri snd_vmidi_output_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x14b/0x190 lib/dump_stack.c:113 kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956 __msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645 snd_midi_event_encode_byte+0x569/0xff0 sound/core/seq/seq_midi_event.c:195 snd_vmidi_output_work+0x34e/0x5b0 sound/core/seq/seq_virmidi.c:161 process_one_work+0x1605/0x1f40 kernel/workqueue.c:2153 worker_thread+0x11a2/0x2590 kernel/workqueue.c:2296 kthread+0x465/0x4a0 kernel/kthread.c:247 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:416 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline] kmsan_save_stack mm/kmsan/kmsan.c:271 [inline] kmsan_internal_chain_origin+0x128/0x210 mm/kmsan/kmsan.c:573 __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:482 __snd_rawmidi_transmit_peek sound/core/rawmidi.c:1103 [inline] snd_rawmidi_transmit+0xa75/0xbf0 sound/core/rawmidi.c:1228 snd_vmidi_output_work+0x2ac/0x5b0 sound/core/seq/seq_virmidi.c:159 process_one_work+0x1605/0x1f40 kernel/workqueue.c:2153 worker_thread+0x11a2/0x2590 kernel/workqueue.c:2296 kthread+0x465/0x4a0 kernel/kthread.c:247 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:416 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline] kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:181 kmsan_kmalloc+0x98/0x100 mm/kmsan/kmsan_hooks.c:91 __kmalloc_node+0x7bf/0x11c0 mm/slub.c:3828 kmalloc_node include/linux/slab.h:555 [inline] kvmalloc_node+0x19d/0x3e0 mm/util.c:423 kvmalloc include/linux/mm.h:577 [inline] snd_rawmidi_runtime_create sound/core/rawmidi.c:132 [inline] open_substream+0x3c8/0xaa0 sound/core/rawmidi.c:276 rawmidi_open_priv+0x347/0x1000 sound/core/rawmidi.c:327 snd_rawmidi_open+0x7d4/0x1120 sound/core/rawmidi.c:424 soundcore_open+0x9be/0xa60 sound/sound_core.c:597 chrdev_open+0xc26/0xdb0 fs/char_dev.c:417 do_dentry_open+0xce6/0x1740 fs/open.c:771 vfs_open+0xaf/0xe0 fs/open.c:880 do_last fs/namei.c:3418 [inline] path_openat+0x1799/0x6870 fs/namei.c:3534 do_filp_open+0x259/0x610 fs/namei.c:3564 do_sys_open+0x630/0x940 fs/open.c:1063 __do_sys_open fs/open.c:1081 [inline] __se_sys_open+0xad/0xc0 fs/open.c:1076 __x64_sys_open+0x4a/0x70 fs/open.c:1076 do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 ==
Re: Peer bridge fixup issue under multiple pci domain
Bjorn Helgaas 于2018年8月28日周二 下午7:35写道： > > [+cc EDAC folks, LKML] > > On Sat, Aug 25, 2018 at 10:58:57PM +0800, Zihan Yang wrote: > > Hi all, > > > > I'm trying to use multiple pci domain in qemu q35, but I find there > > might be some issues in peer bridge fixup. > > > > In short, pcibios_fixup_peer_bridges function assumes only one pci > > domain (0) by default. This is OK when as qemu by default uses only > > one pci domain too. However, if I add another host bridge which is > > put into pci domain 1 by using _SEG, and a pcie_pci_bridge is attached > > to the bus 1 under this new pci domain 1 rather than domain 0, the > > kernel will recognize the bus 01 differently. > > > > More specifically, pcibios_fixup_peer_bridges only reads all the buses > > under domain 0 but it can read the pci bus 01 in pci domain 1 and treat > > it as a peer bus of :00. The consequence is this 01 bus is recognized > > as :01, but it should have been recognized as 0001:01. > > > > The host bus 0001:00 can be recognized so I guess pcibios_fixup_peer_bridges > > needs updating to take care of multiple domains? Or is it just an bios > > issue? > > I'm not quite sure and I'm open to any suggestions. > > Is there something that actually does not work, or is this just a > concern that the code looks wrong? Sorry for the late reply, currently it is just a concern because the qemu part is still ongoing and I'm not quite sure about the root cause. But my disussion with qemu developers indicate my issue might originates from incorrect AML, which includes _SEG, _BBN and _CRS as you state below. I will try to locate the real cause recently. > pcibios_fixup_peer_bridges() is ancient history from before x86 used > the ACPI namespace to discover host bridges. It blindly probes for > devices on buses 0-255, but as you say, only in domain 0. > > Using multiple PCI domains really requires ACPI support so we know > what the other domains are (_SEG) and how to access their config space > (MCFG). When we do have ACPI support in the platform and the kernel, > drivers/acpi/pci_root.c discovers all the host bridges in all domains > via PNP0A03 or PNP0A08 devices in the ACPI namespace, and in most > cases pcibios_fixup_peer_bridges() will do nothing. > > However, there *are* systems where the firmware does not expose all > host bridges and in those cases, pcibios_fixup_peer_bridges() can be a > problem. For example, Intel processors often have management devices > on bus 7f or ff. If the ACPI namespace doesn't have a host bridge to > those buses, pci_root.c won't find them, but > pcibios_fixup_peer_bridges() *will*. Thanks for clarifying, does it only affect bus 7f/ff, or does it affect other busses as well? If only management devices are affected, then I think it is not the cause of my issue. But thanks a lot for your detailed reply. > This leads to several problems. Here's a dmesg sample from [1] > (found by googling for 'dmesg log "PCI: discovered peer bus ff"'): > > ACPI: PCI Root Bridge [PCI0] (domain [bus 00-ff]) > PCI: Discovered peer bus fe > pci_bus :fe: root bus resource [io 0x-0x] > pci_bus :fe: root bus resource [mem 0x-0xff] > pci :fe:03.0: [8086:2d98] type 00 class 0x06 > PCI: Discovered peer bus ff > pci_bus :ff: root bus resource [io 0x-0x] > pci_bus :ff: root bus resource [mem 0x-0xff] > pci :ff:03.0: [8086:2d98] type 00 class 0x06 > EDAC MC1: Giving out device to module i7core_edac.c controller i7 core #1: > DEV :fe:03.0 (INTERRUPT) > EDAC PCI0: Giving out device to module i7core_edac controller EDAC PCI > controller: DEV :fe:03.0 (POLLED) > EDAC MC0: Giving out device to module i7core_edac.c controller i7 core #0: > DEV :ff:03.0 (INTERRUPT) > EDAC PCI1: Giving out device to module i7core_edac controller EDAC PCI > controller: DEV :ff:03.0 (POLLED) > > Some of the problems are: > > - Firmware may have omitted the host bridges to [bus fe] and > [bus ff] from the ACPI namespace because *it* is using those > management devices, so EDAC blindly using them is a potential > conflict. > > - pcibios_fixup_peer_bridges() only scans domain 0, so if this > system had multiple domains, EDAC would only work on things in > domain 0, ignoring other domains. > > - The PCI core can't do bus number assignment correctly for devices > behind bridge PCI0. The firmware told us [bus 00-ff] was > available, so the core may assign bus number fe to some deep > switch hierarchy. But bus fe conflicts with the devices on the > "peer bus fe". This part is a firmware bug: it should have told > us that PCI0 leads to [bus 00-fd], not [bus 00-ff]. > > - The PCI core can't do resource assignment correctly for devices on > [bus fe] and [bus ff]. It has no information about what MMIO and > I/O port are routed to those buses, so it assumes *all* memory and >
Re: Peer bridge fixup issue under multiple pci domain
Bjorn Helgaas 于2018年8月28日周二 下午7:35写道： > > [+cc EDAC folks, LKML] > > On Sat, Aug 25, 2018 at 10:58:57PM +0800, Zihan Yang wrote: > > Hi all, > > > > I'm trying to use multiple pci domain in qemu q35, but I find there > > might be some issues in peer bridge fixup. > > > > In short, pcibios_fixup_peer_bridges function assumes only one pci > > domain (0) by default. This is OK when as qemu by default uses only > > one pci domain too. However, if I add another host bridge which is > > put into pci domain 1 by using _SEG, and a pcie_pci_bridge is attached > > to the bus 1 under this new pci domain 1 rather than domain 0, the > > kernel will recognize the bus 01 differently. > > > > More specifically, pcibios_fixup_peer_bridges only reads all the buses > > under domain 0 but it can read the pci bus 01 in pci domain 1 and treat > > it as a peer bus of :00. The consequence is this 01 bus is recognized > > as :01, but it should have been recognized as 0001:01. > > > > The host bus 0001:00 can be recognized so I guess pcibios_fixup_peer_bridges > > needs updating to take care of multiple domains? Or is it just an bios > > issue? > > I'm not quite sure and I'm open to any suggestions. > > Is there something that actually does not work, or is this just a > concern that the code looks wrong? Sorry for the late reply, currently it is just a concern because the qemu part is still ongoing and I'm not quite sure about the root cause. But my disussion with qemu developers indicate my issue might originates from incorrect AML, which includes _SEG, _BBN and _CRS as you state below. I will try to locate the real cause recently. > pcibios_fixup_peer_bridges() is ancient history from before x86 used > the ACPI namespace to discover host bridges. It blindly probes for > devices on buses 0-255, but as you say, only in domain 0. > > Using multiple PCI domains really requires ACPI support so we know > what the other domains are (_SEG) and how to access their config space > (MCFG). When we do have ACPI support in the platform and the kernel, > drivers/acpi/pci_root.c discovers all the host bridges in all domains > via PNP0A03 or PNP0A08 devices in the ACPI namespace, and in most > cases pcibios_fixup_peer_bridges() will do nothing. > > However, there *are* systems where the firmware does not expose all > host bridges and in those cases, pcibios_fixup_peer_bridges() can be a > problem. For example, Intel processors often have management devices > on bus 7f or ff. If the ACPI namespace doesn't have a host bridge to > those buses, pci_root.c won't find them, but > pcibios_fixup_peer_bridges() *will*. Thanks for clarifying, does it only affect bus 7f/ff, or does it affect other busses as well? If only management devices are affected, then I think it is not the cause of my issue. But thanks a lot for your detailed reply. > This leads to several problems. Here's a dmesg sample from [1] > (found by googling for 'dmesg log "PCI: discovered peer bus ff"'): > > ACPI: PCI Root Bridge [PCI0] (domain [bus 00-ff]) > PCI: Discovered peer bus fe > pci_bus :fe: root bus resource [io 0x-0x] > pci_bus :fe: root bus resource [mem 0x-0xff] > pci :fe:03.0: [8086:2d98] type 00 class 0x06 > PCI: Discovered peer bus ff > pci_bus :ff: root bus resource [io 0x-0x] > pci_bus :ff: root bus resource [mem 0x-0xff] > pci :ff:03.0: [8086:2d98] type 00 class 0x06 > EDAC MC1: Giving out device to module i7core_edac.c controller i7 core #1: > DEV :fe:03.0 (INTERRUPT) > EDAC PCI0: Giving out device to module i7core_edac controller EDAC PCI > controller: DEV :fe:03.0 (POLLED) > EDAC MC0: Giving out device to module i7core_edac.c controller i7 core #0: > DEV :ff:03.0 (INTERRUPT) > EDAC PCI1: Giving out device to module i7core_edac controller EDAC PCI > controller: DEV :ff:03.0 (POLLED) > > Some of the problems are: > > - Firmware may have omitted the host bridges to [bus fe] and > [bus ff] from the ACPI namespace because *it* is using those > management devices, so EDAC blindly using them is a potential > conflict. > > - pcibios_fixup_peer_bridges() only scans domain 0, so if this > system had multiple domains, EDAC would only work on things in > domain 0, ignoring other domains. > > - The PCI core can't do bus number assignment correctly for devices > behind bridge PCI0. The firmware told us [bus 00-ff] was > available, so the core may assign bus number fe to some deep > switch hierarchy. But bus fe conflicts with the devices on the > "peer bus fe". This part is a firmware bug: it should have told > us that PCI0 leads to [bus 00-fd], not [bus 00-ff]. > > - The PCI core can't do resource assignment correctly for devices on > [bus fe] and [bus ff]. It has no information about what MMIO and > I/O port are routed to those buses, so it assumes *all* memory and >
RE: [PATCH 1/2] ARM: dts: imx7s: enable cpuidle driver
Anson Huang
Best Regards!
> -Original Message-
> From: Shawn Guo
> Sent: Monday, September 3, 2018 9:16 AM
> To: Anson Huang
> Cc: s.ha...@pengutronix.de; ker...@pengutronix.de; Fabio Estevam
> ; robh...@kernel.org; mark.rutl...@arm.com;
> li...@armlinux.org.uk; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; dl-linux-imx
>
> Subject: Re: [PATCH 1/2] ARM: dts: imx7s: enable cpuidle driver
>
> On Wed, Aug 29, 2018 at 01:00:46PM +0800, Anson Huang wrote:
> > Enable cpuidle for i.MX7S/D using generic ARM cpuidle driver, below 2
> > idle states enabled:
> >
> > 1. ARM WFI;
> > 2. SoC WAIT mode.
> >
> > Signed-off-by: Anson Huang
> > ---
> > arch/arm/boot/dts/imx7d.dtsi | 1 +
> > arch/arm/boot/dts/imx7s.dtsi | 14 ++
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx7d.dtsi
> > b/arch/arm/boot/dts/imx7d.dtsi index 7cbc2ff..4d0d0f6 100644
> > --- a/arch/arm/boot/dts/imx7d.dtsi
> > +++ b/arch/arm/boot/dts/imx7d.dtsi
> > @@ -20,6 +20,7 @@
> > reg = <1>;
> > clock-frequency = <99600>;
> > operating-points-v2 = <_opp_table>;
> > + cpu-idle-states = <_SLEEP>;
> > };
> > };
> >
> > diff --git a/arch/arm/boot/dts/imx7s.dtsi
> > b/arch/arm/boot/dts/imx7s.dtsi index 93884ce..cf5570b 100644
> > --- a/arch/arm/boot/dts/imx7s.dtsi
> > +++ b/arch/arm/boot/dts/imx7s.dtsi
> > @@ -54,6 +54,19 @@
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > + idle-states {
> > + entry-method = "psci";
> > +
> > + CPU_SLEEP: WAIT {
>
> I understand uppercase is allowed, but we conventionally use lowercase for
> label and node name. Can we do something like below?
>
> cpu_sleep_wait: cpu-sleep-wait {
> ...
> }
Sure, please review V2 patch, thanks!
Anson
>
> Shawn
>
> > + compatible = "arm,idle-state";
> > + arm,psci-suspend-param = <0x001>;
> > + local-timer-stop;
> > + entry-latency-us = <100>;
> > + exit-latency-us = <50>;
> > + min-residency-us = <1000>;
> > + };
> > + };
> > +
> > cpu0: cpu@0 {
> > compatible = "arm,cortex-a7";
> > device_type = "cpu";
> > @@ -61,6 +74,7 @@
> > clock-frequency = <79200>;
> > clock-latency = <61036>; /* two CLK32 periods */
> > clocks = < IMX7D_CLK_ARM>;
> > + cpu-idle-states = <_SLEEP>;
> > };
> > };
> >
> > --
> > 2.7.4
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> >
> s.infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kerneldata=02%7C
> >
> 01%7CAnson.Huang%40nxp.com%7C8ce1cddcac05444edc1408d6113b0a76%7
> C686ea1
> >
> d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636715342610651079sda
> ta=x9l%
> >
> 2FrkV8Uo8CtSa0jJsBZ%2FXt2DE3ZRQ5TWXm5%2Fbwvag%3Dreserved=
> 0
RE: [PATCH 1/2] ARM: dts: imx7s: enable cpuidle driver
Anson Huang
Best Regards!
> -Original Message-
> From: Shawn Guo
> Sent: Monday, September 3, 2018 9:16 AM
> To: Anson Huang
> Cc: s.ha...@pengutronix.de; ker...@pengutronix.de; Fabio Estevam
> ; robh...@kernel.org; mark.rutl...@arm.com;
> li...@armlinux.org.uk; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; dl-linux-imx
>
> Subject: Re: [PATCH 1/2] ARM: dts: imx7s: enable cpuidle driver
>
> On Wed, Aug 29, 2018 at 01:00:46PM +0800, Anson Huang wrote:
> > Enable cpuidle for i.MX7S/D using generic ARM cpuidle driver, below 2
> > idle states enabled:
> >
> > 1. ARM WFI;
> > 2. SoC WAIT mode.
> >
> > Signed-off-by: Anson Huang
> > ---
> > arch/arm/boot/dts/imx7d.dtsi | 1 +
> > arch/arm/boot/dts/imx7s.dtsi | 14 ++
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx7d.dtsi
> > b/arch/arm/boot/dts/imx7d.dtsi index 7cbc2ff..4d0d0f6 100644
> > --- a/arch/arm/boot/dts/imx7d.dtsi
> > +++ b/arch/arm/boot/dts/imx7d.dtsi
> > @@ -20,6 +20,7 @@
> > reg = <1>;
> > clock-frequency = <99600>;
> > operating-points-v2 = <_opp_table>;
> > + cpu-idle-states = <_SLEEP>;
> > };
> > };
> >
> > diff --git a/arch/arm/boot/dts/imx7s.dtsi
> > b/arch/arm/boot/dts/imx7s.dtsi index 93884ce..cf5570b 100644
> > --- a/arch/arm/boot/dts/imx7s.dtsi
> > +++ b/arch/arm/boot/dts/imx7s.dtsi
> > @@ -54,6 +54,19 @@
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > + idle-states {
> > + entry-method = "psci";
> > +
> > + CPU_SLEEP: WAIT {
>
> I understand uppercase is allowed, but we conventionally use lowercase for
> label and node name. Can we do something like below?
>
> cpu_sleep_wait: cpu-sleep-wait {
> ...
> }
Sure, please review V2 patch, thanks!
Anson
>
> Shawn
>
> > + compatible = "arm,idle-state";
> > + arm,psci-suspend-param = <0x001>;
> > + local-timer-stop;
> > + entry-latency-us = <100>;
> > + exit-latency-us = <50>;
> > + min-residency-us = <1000>;
> > + };
> > + };
> > +
> > cpu0: cpu@0 {
> > compatible = "arm,cortex-a7";
> > device_type = "cpu";
> > @@ -61,6 +74,7 @@
> > clock-frequency = <79200>;
> > clock-latency = <61036>; /* two CLK32 periods */
> > clocks = < IMX7D_CLK_ARM>;
> > + cpu-idle-states = <_SLEEP>;
> > };
> > };
> >
> > --
> > 2.7.4
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> >
> s.infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kerneldata=02%7C
> >
> 01%7CAnson.Huang%40nxp.com%7C8ce1cddcac05444edc1408d6113b0a76%7
> C686ea1
> >
> d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636715342610651079sda
> ta=x9l%
> >
> 2FrkV8Uo8CtSa0jJsBZ%2FXt2DE3ZRQ5TWXm5%2Fbwvag%3Dreserved=
> 0
[PATCH V2] ARM: dts: imx7s: enable cpuidle driver
Enable cpuidle for i.MX7S/D using generic ARM cpuidle
driver, below 2 idle states enabled:
1. ARM WFI;
2. SoC WAIT mode.
Signed-off-by: Anson Huang
---
changes since V1:
replace uppercase with lowercase.
arch/arm/boot/dts/imx7d.dtsi | 1 +
arch/arm/boot/dts/imx7s.dtsi | 14 ++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 7cbc2ff..53eb371 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -20,6 +20,7 @@
reg = <1>;
clock-frequency = <99600>;
operating-points-v2 = <_opp_table>;
+ cpu-idle-states = <_sleep_wait>;
};
};
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 93884ce..d3f6488 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -54,6 +54,19 @@
#address-cells = <1>;
#size-cells = <0>;
+ idle-states {
+ entry-method = "psci";
+
+ cpu_sleep_wait: cpu-sleep-wait {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x001>;
+ local-timer-stop;
+ entry-latency-us = <100>;
+ exit-latency-us = <50>;
+ min-residency-us = <1000>;
+ };
+ };
+
cpu0: cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
@@ -61,6 +74,7 @@
clock-frequency = <79200>;
clock-latency = <61036>; /* two CLK32 periods */
clocks = < IMX7D_CLK_ARM>;
+ cpu-idle-states = <_sleep_wait>;
};
};
--
2.7.4
[PATCH V2] ARM: dts: imx7s: enable cpuidle driver
Enable cpuidle for i.MX7S/D using generic ARM cpuidle
driver, below 2 idle states enabled:
1. ARM WFI;
2. SoC WAIT mode.
Signed-off-by: Anson Huang
---
changes since V1:
replace uppercase with lowercase.
arch/arm/boot/dts/imx7d.dtsi | 1 +
arch/arm/boot/dts/imx7s.dtsi | 14 ++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 7cbc2ff..53eb371 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -20,6 +20,7 @@
reg = <1>;
clock-frequency = <99600>;
operating-points-v2 = <_opp_table>;
+ cpu-idle-states = <_sleep_wait>;
};
};
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 93884ce..d3f6488 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -54,6 +54,19 @@
#address-cells = <1>;
#size-cells = <0>;
+ idle-states {
+ entry-method = "psci";
+
+ cpu_sleep_wait: cpu-sleep-wait {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x001>;
+ local-timer-stop;
+ entry-latency-us = <100>;
+ exit-latency-us = <50>;
+ min-residency-us = <1000>;
+ };
+ };
+
cpu0: cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
@@ -61,6 +74,7 @@
clock-frequency = <79200>;
clock-latency = <61036>; /* two CLK32 periods */
clocks = < IMX7D_CLK_ARM>;
+ cpu-idle-states = <_sleep_wait>;
};
};
--
2.7.4
Re: Access to non-RAM pages
On Mon, 2018-09-03 at 10:48 +1000, Benjamin Herrenschmidt wrote: > On Sat, 2018-09-01 at 11:06 -0700, Linus Torvalds wrote: > > [ Adding a few new people the the cc. > > > > The issue is the worry about software-speculative accesses (ie > > things like CONFIG_DCACHE_WORD_ACCESS - not talking about the hw > > speculation now) accessing past RAM into possibly contiguous IO ] > > > > On Sat, Sep 1, 2018 at 10:27 AM Linus Torvalds > > wrote: > > > > > > If you have a machine with RAM that touches IO, you need to disable > > > the last page, exactly the same way we disable and marked reserved the > > > first page at zero. > > So I missed the departure of that train ... stupid question, with > CONFIG_DCACHE_WORD_ACCESS, if that can be unaligned (I assume it can), > what prevents it from crossing into a non-mapped page (not even IO) and > causing an oops ? Looking at a random user in fs/dcache.c its not a > uaccess-style read with recovery Or am I missing somethign obvious > here ? Also, if we cross page boundaries with those guys then we have a bigger problem no ? we could fall off a vmalloc page into the nether or into an ioremap mapping no ? Cheers, Ben.
Re: Access to non-RAM pages
On Mon, 2018-09-03 at 10:48 +1000, Benjamin Herrenschmidt wrote: > On Sat, 2018-09-01 at 11:06 -0700, Linus Torvalds wrote: > > [ Adding a few new people the the cc. > > > > The issue is the worry about software-speculative accesses (ie > > things like CONFIG_DCACHE_WORD_ACCESS - not talking about the hw > > speculation now) accessing past RAM into possibly contiguous IO ] > > > > On Sat, Sep 1, 2018 at 10:27 AM Linus Torvalds > > wrote: > > > > > > If you have a machine with RAM that touches IO, you need to disable > > > the last page, exactly the same way we disable and marked reserved the > > > first page at zero. > > So I missed the departure of that train ... stupid question, with > CONFIG_DCACHE_WORD_ACCESS, if that can be unaligned (I assume it can), > what prevents it from crossing into a non-mapped page (not even IO) and > causing an oops ? Looking at a random user in fs/dcache.c its not a > uaccess-style read with recovery Or am I missing somethign obvious > here ? Also, if we cross page boundaries with those guys then we have a bigger problem no ? we could fall off a vmalloc page into the nether or into an ioremap mapping no ? Cheers, Ben.
Re: Access to non-RAM pages
On Sun, 2018-09-02 at 18:38 -0700, Linus Torvalds wrote: > On Sun, Sep 2, 2018 at 6:32 PM Benjamin Herrenschmidt > wrote: > > > > Also, if we cross page boundaries with those guys then we have a bigger > > problem no ? we could fall off a vmalloc page into the nether or into > > an ioremap mapping no ? > > It's not used for vmalloc stuff. It's just regular kmalloc(). > > So it can cross pages, and it can fall off the end of memory, but it > can't do random stuff. Actually what about DEBUG_PAGEALLOC ? Can't we fall off a page and fault that way too ? Cheers, Ben.
Re: Access to non-RAM pages
On Sun, 2018-09-02 at 18:38 -0700, Linus Torvalds wrote: > On Sun, Sep 2, 2018 at 6:32 PM Benjamin Herrenschmidt > wrote: > > > > Also, if we cross page boundaries with those guys then we have a bigger > > problem no ? we could fall off a vmalloc page into the nether or into > > an ioremap mapping no ? > > It's not used for vmalloc stuff. It's just regular kmalloc(). > > So it can cross pages, and it can fall off the end of memory, but it > can't do random stuff. Actually what about DEBUG_PAGEALLOC ? Can't we fall off a page and fault that way too ? Cheers, Ben.
Re: Access to non-RAM pages
On Sun, 2018-09-02 at 18:38 -0700, Linus Torvalds wrote: > On Sun, Sep 2, 2018 at 6:32 PM Benjamin Herrenschmidt > wrote: > > > > Also, if we cross page boundaries with those guys then we have a bigger > > problem no ? we could fall off a vmalloc page into the nether or into > > an ioremap mapping no ? > > It's not used for vmalloc stuff. It's just regular kmalloc(). > > So it can cross pages, and it can fall off the end of memory, but it > can't do random stuff. Ok, it might be worth adding a DEBUG_VM based (or similar) warning in case somebody ever thinks of passing a vmalloc pointer to it... As for falling out of the end of memory, yes it could be a real problem though I don't see why IO is any different than just hitting a non- mapped area in that regard. So we should probably keep an unused (readonly if possible) zero page at the end. Cheers, Ben.
Re: Access to non-RAM pages
On Sun, 2018-09-02 at 18:38 -0700, Linus Torvalds wrote: > On Sun, Sep 2, 2018 at 6:32 PM Benjamin Herrenschmidt > wrote: > > > > Also, if we cross page boundaries with those guys then we have a bigger > > problem no ? we could fall off a vmalloc page into the nether or into > > an ioremap mapping no ? > > It's not used for vmalloc stuff. It's just regular kmalloc(). > > So it can cross pages, and it can fall off the end of memory, but it > can't do random stuff. Ok, it might be worth adding a DEBUG_VM based (or similar) warning in case somebody ever thinks of passing a vmalloc pointer to it... As for falling out of the end of memory, yes it could be a real problem though I don't see why IO is any different than just hitting a non- mapped area in that regard. So we should probably keep an unused (readonly if possible) zero page at the end. Cheers, Ben.
Re: Access to non-RAM pages
On Sun, Sep 2, 2018 at 6:38 PM Linus Torvalds wrote: > It's not used for vmalloc stuff. It's just regular kmalloc(). Just to clarify .. that's true of the dcache stuff. The strscpy case actually explicitly limits things to page boundaries and falls back to the byte-by-byte case after that. Linus
Re: Access to non-RAM pages
On Sun, Sep 2, 2018 at 6:38 PM Linus Torvalds wrote: > It's not used for vmalloc stuff. It's just regular kmalloc(). Just to clarify .. that's true of the dcache stuff. The strscpy case actually explicitly limits things to page boundaries and falls back to the byte-by-byte case after that. Linus
