Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
at 10:50 PM, Greg Kroah-Hartman wrote:
> On Thu, Jun 14, 2018 at 05:41:01AM +, Nadav Amit wrote:
>> at 10:23 PM, Greg Kroah-Hartman wrote:
>>
>>> On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
When balloon batching is not supported by the hypervisor, the guest
frame number (GFN) must fit in 32-bit. However, due to a bug, this check
was mistakenly ignored. In practice, when total RAM is greater than
16TB, the balloon does not work currently, making this bug unlikely to
happen.
Fixes: ef0f8f112984 ("VMware balloon: partially inline
vmballoon_reserve_page.")
Cc: sta...@vger.kernel.org
>>>
>>> Again, no blank line between these things.
>>>
>>> Also, please break this up into two different patch series. One for
>>> 4.18-final and one for 4.19-rc1. You should always split up bugfixes
>>> from new features/cleanups as that is what I have to do when sending
>>> them to Linus.
>>
>> I have only sent what I thought is appropriate for 4.18 (cleanup/features
>> will be sent separately):
>>
>> * 5 bug fixes (1-5/7)
>> * 1 update the maintainer list (7/7)
>> * 1 update to the comment to prevent checkpatch from complaining (6/7)
>>
>> If you think any patch is unsuitable to 4.18 - please say which.
>
> How do I know which patch goes to which branch? Please make it so
> obvious I can not get it wrong. Remember, I get 1000 emails a day, you
> don't want me to have to make a judgement call about anything, as I will
> mess it up :)
I appreciate your time, and understand you even need to read students’
dissertations. ;-)
I will write it clearly in the cover-letter in the next version, and move
the license changes to 4.19.
Thanks,
Nadav
Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
at 10:50 PM, Greg Kroah-Hartman wrote:
> On Thu, Jun 14, 2018 at 05:41:01AM +, Nadav Amit wrote:
>> at 10:23 PM, Greg Kroah-Hartman wrote:
>>
>>> On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
When balloon batching is not supported by the hypervisor, the guest
frame number (GFN) must fit in 32-bit. However, due to a bug, this check
was mistakenly ignored. In practice, when total RAM is greater than
16TB, the balloon does not work currently, making this bug unlikely to
happen.
Fixes: ef0f8f112984 ("VMware balloon: partially inline
vmballoon_reserve_page.")
Cc: sta...@vger.kernel.org
>>>
>>> Again, no blank line between these things.
>>>
>>> Also, please break this up into two different patch series. One for
>>> 4.18-final and one for 4.19-rc1. You should always split up bugfixes
>>> from new features/cleanups as that is what I have to do when sending
>>> them to Linus.
>>
>> I have only sent what I thought is appropriate for 4.18 (cleanup/features
>> will be sent separately):
>>
>> * 5 bug fixes (1-5/7)
>> * 1 update the maintainer list (7/7)
>> * 1 update to the comment to prevent checkpatch from complaining (6/7)
>>
>> If you think any patch is unsuitable to 4.18 - please say which.
>
> How do I know which patch goes to which branch? Please make it so
> obvious I can not get it wrong. Remember, I get 1000 emails a day, you
> don't want me to have to make a judgement call about anything, as I will
> mess it up :)
I appreciate your time, and understand you even need to read students’
dissertations. ;-)
I will write it clearly in the cover-letter in the next version, and move
the license changes to 4.19.
Thanks,
Nadav
Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
On Thu, Jun 14, 2018 at 05:41:01AM +, Nadav Amit wrote:
> at 10:23 PM, Greg Kroah-Hartman wrote:
>
> > On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
> >> When balloon batching is not supported by the hypervisor, the guest
> >> frame number (GFN) must fit in 32-bit. However, due to a bug, this check
> >> was mistakenly ignored. In practice, when total RAM is greater than
> >> 16TB, the balloon does not work currently, making this bug unlikely to
> >> happen.
> >>
> >> Fixes: ef0f8f112984 ("VMware balloon: partially inline
> >> vmballoon_reserve_page.")
> >>
> >> Cc: sta...@vger.kernel.org
> >
> > Again, no blank line between these things.
> >
> > Also, please break this up into two different patch series. One for
> > 4.18-final and one for 4.19-rc1. You should always split up bugfixes
> > from new features/cleanups as that is what I have to do when sending
> > them to Linus.
>
> I have only sent what I thought is appropriate for 4.18 (cleanup/features
> will be sent separately):
>
> * 5 bug fixes (1-5/7)
> * 1 update the maintainer list (7/7)
> * 1 update to the comment to prevent checkpatch from complaining (6/7)
>
> If you think any patch is unsuitable to 4.18 - please say which.
How do I know which patch goes to which branch? Please make it so
obvious I can not get it wrong. Remember, I get 1000 emails a day, you
don't want me to have to make a judgement call about anything, as I will
mess it up :)
thanks,
greg k-h
Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
On Thu, Jun 14, 2018 at 05:41:01AM +, Nadav Amit wrote:
> at 10:23 PM, Greg Kroah-Hartman wrote:
>
> > On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
> >> When balloon batching is not supported by the hypervisor, the guest
> >> frame number (GFN) must fit in 32-bit. However, due to a bug, this check
> >> was mistakenly ignored. In practice, when total RAM is greater than
> >> 16TB, the balloon does not work currently, making this bug unlikely to
> >> happen.
> >>
> >> Fixes: ef0f8f112984 ("VMware balloon: partially inline
> >> vmballoon_reserve_page.")
> >>
> >> Cc: sta...@vger.kernel.org
> >
> > Again, no blank line between these things.
> >
> > Also, please break this up into two different patch series. One for
> > 4.18-final and one for 4.19-rc1. You should always split up bugfixes
> > from new features/cleanups as that is what I have to do when sending
> > them to Linus.
>
> I have only sent what I thought is appropriate for 4.18 (cleanup/features
> will be sent separately):
>
> * 5 bug fixes (1-5/7)
> * 1 update the maintainer list (7/7)
> * 1 update to the comment to prevent checkpatch from complaining (6/7)
>
> If you think any patch is unsuitable to 4.18 - please say which.
How do I know which patch goes to which branch? Please make it so
obvious I can not get it wrong. Remember, I get 1000 emails a day, you
don't want me to have to make a judgement call about anything, as I will
mess it up :)
thanks,
greg k-h
Re: [PATCH v2 6/7] vmw_balloon: update copyright message
On Thu, Jun 14, 2018 at 05:33:46AM +, Nadav Amit wrote:
> at 10:24 PM, Greg Kroah-Hartman wrote:
>
> > On Wed, Jun 13, 2018 at 06:54:11AM -0700, Nadav Amit wrote:
> >> Removing the paragraph about writing to the Free Software Foundation's
> >> mailing address from the sample GPL notice according to checkpatch
> >> request.
> >>
> >> In addition, updating the year and adding a license tag.
> >>
> >> Reviewed-by: Xavier Deguillard
> >> Signed-off-by: Nadav Amit
> >> ---
> >> drivers/misc/vmw_balloon.c | 7 ++-
> >> 1 file changed, 2 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
> >> index 400a1ccefc8e..b982059ce7b7 100644
> >> --- a/drivers/misc/vmw_balloon.c
> >> +++ b/drivers/misc/vmw_balloon.c
> >> @@ -1,7 +1,8 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> /*
> >> * VMware Balloon driver.
> >> *
> >> - * Copyright (C) 2000-2014, VMware, Inc. All Rights Reserved.
> >> + * Copyright (C) 2000-2018, VMware, Inc. All Rights Reserved.
> >> *
> >> * This program is free software; you can redistribute it and/or modify it
> >> * under the terms of the GNU General Public License as published by the
> >> @@ -13,10 +14,6 @@
> >> * NON INFRINGEMENT. See the GNU General Public License for more
> >> * details.
> >
> > You still have a lot of boiler-plate text in here that can be removed.
> > Please do so.
>
> I will remove the maintainers, since it is really unsuitable.
>
> But what else do you want me to remove? This is a standard GPL license. If I
> am required to remove the GPL license, I will have to run checks to ensure
> it is appropriate.
Yes, all of the license text should be removed. Right now we have 700+
differnt wordings of "This file is released under the GPL" in the kernel
tree, and we need to clean that up. Look at all of the other SPDX
cleanups we have done already to get an idea of what is needed here.
As one example, look at 0c3b34a569f8 ("USB: typec: Remove remaining
redundant license text") which can be done after the correct SPDX line
is in the file. That's the end-goal for all kernel files.
thanks,
greg k-h
Re: [PATCH v2 6/7] vmw_balloon: update copyright message
On Thu, Jun 14, 2018 at 05:33:46AM +, Nadav Amit wrote:
> at 10:24 PM, Greg Kroah-Hartman wrote:
>
> > On Wed, Jun 13, 2018 at 06:54:11AM -0700, Nadav Amit wrote:
> >> Removing the paragraph about writing to the Free Software Foundation's
> >> mailing address from the sample GPL notice according to checkpatch
> >> request.
> >>
> >> In addition, updating the year and adding a license tag.
> >>
> >> Reviewed-by: Xavier Deguillard
> >> Signed-off-by: Nadav Amit
> >> ---
> >> drivers/misc/vmw_balloon.c | 7 ++-
> >> 1 file changed, 2 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
> >> index 400a1ccefc8e..b982059ce7b7 100644
> >> --- a/drivers/misc/vmw_balloon.c
> >> +++ b/drivers/misc/vmw_balloon.c
> >> @@ -1,7 +1,8 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> /*
> >> * VMware Balloon driver.
> >> *
> >> - * Copyright (C) 2000-2014, VMware, Inc. All Rights Reserved.
> >> + * Copyright (C) 2000-2018, VMware, Inc. All Rights Reserved.
> >> *
> >> * This program is free software; you can redistribute it and/or modify it
> >> * under the terms of the GNU General Public License as published by the
> >> @@ -13,10 +14,6 @@
> >> * NON INFRINGEMENT. See the GNU General Public License for more
> >> * details.
> >
> > You still have a lot of boiler-plate text in here that can be removed.
> > Please do so.
>
> I will remove the maintainers, since it is really unsuitable.
>
> But what else do you want me to remove? This is a standard GPL license. If I
> am required to remove the GPL license, I will have to run checks to ensure
> it is appropriate.
Yes, all of the license text should be removed. Right now we have 700+
differnt wordings of "This file is released under the GPL" in the kernel
tree, and we need to clean that up. Look at all of the other SPDX
cleanups we have done already to get an idea of what is needed here.
As one example, look at 0c3b34a569f8 ("USB: typec: Remove remaining
redundant license text") which can be done after the correct SPDX line
is in the file. That's the end-goal for all kernel files.
thanks,
greg k-h
Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
at 10:23 PM, Greg Kroah-Hartman wrote:
> On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
>> When balloon batching is not supported by the hypervisor, the guest
>> frame number (GFN) must fit in 32-bit. However, due to a bug, this check
>> was mistakenly ignored. In practice, when total RAM is greater than
>> 16TB, the balloon does not work currently, making this bug unlikely to
>> happen.
>>
>> Fixes: ef0f8f112984 ("VMware balloon: partially inline
>> vmballoon_reserve_page.")
>>
>> Cc: sta...@vger.kernel.org
>
> Again, no blank line between these things.
>
> Also, please break this up into two different patch series. One for
> 4.18-final and one for 4.19-rc1. You should always split up bugfixes
> from new features/cleanups as that is what I have to do when sending
> them to Linus.
I have only sent what I thought is appropriate for 4.18 (cleanup/features
will be sent separately):
* 5 bug fixes (1-5/7)
* 1 update the maintainer list (7/7)
* 1 update to the comment to prevent checkpatch from complaining (6/7)
If you think any patch is unsuitable to 4.18 - please say which.
Thanks,
Nadav
Re: [PATCH] Staging: octeon-usb: octeon-hcd.c: Remove boiler plate and add SPDX
On Wed, Jun 13, 2018 at 05:28:25PM -0400, Javier Martinez wrote: > Removed massive boiler plate text at top of the file and instead > replaced it with a simple SPDX license identifier. > > Signed-off-by: Javier Martinez > --- > drivers/staging/octeon-usb/octeon-hcd.c | 47 ++--- > 1 file changed, 2 insertions(+), 45 deletions(-) > > diff --git a/drivers/staging/octeon-usb/octeon-hcd.c > b/drivers/staging/octeon-usb/octeon-hcd.c > index cded30f145aa..df61e8321140 100644 > --- a/drivers/staging/octeon-usb/octeon-hcd.c > +++ b/drivers/staging/octeon-usb/octeon-hcd.c > @@ -1,48 +1,5 @@ > -/* > - * This file is subject to the terms and conditions of the GNU General Public > - * License. See the file "COPYING" in the main directory of this archive > - * for more details. > - * > - * Copyright (C) 2008 Cavium Networks > - * > - * Some parts of the code were originally released under BSD license: > - * > - * Copyright (c) 2003-2010 Cavium Networks (supp...@cavium.com). All rights > - * reserved. > - * > - * Redistribution and use in source and binary forms, with or without > - * modification, are permitted provided that the following conditions are > - * met: > - * > - * * Redistributions of source code must retain the above copyright > - * notice, this list of conditions and the following disclaimer. > - * > - * * Redistributions in binary form must reproduce the above > - * copyright notice, this list of conditions and the following > - * disclaimer in the documentation and/or other materials provided > - * with the distribution. > - * > - * * Neither the name of Cavium Networks nor the names of > - * its contributors may be used to endorse or promote products > - * derived from this software without specific prior written > - * permission. > - * > - * This Software, including technical data, may be subject to U.S. export > - * control laws, including the U.S. Export Administration Act and its > associated > - * regulations, and may be subject to export or import regulations in other > - * countries. > - * > - * TO THE MAXIMUM EXTENT PERMITTED BY LAW, THE SOFTWARE IS PROVIDED "AS IS" > - * AND WITH ALL FAULTS AND CAVIUM NETWORKS MAKES NO PROMISES, > REPRESENTATIONS OR > - * WARRANTIES, EITHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, WITH > RESPECT TO > - * THE SOFTWARE, INCLUDING ITS CONDITION, ITS CONFORMITY TO ANY > REPRESENTATION > - * OR DESCRIPTION, OR THE EXISTENCE OF ANY LATENT OR PATENT DEFECTS, AND > CAVIUM > - * SPECIFICALLY DISCLAIMS ALL IMPLIED (IF ANY) WARRANTIES OF TITLE, > - * MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE, LACK > OF > - * VIRUSES, ACCURACY OR COMPLETENESS, QUIET ENJOYMENT, QUIET POSSESSION OR > - * CORRESPONDENCE TO DESCRIPTION. THE ENTIRE RISK ARISING OUT OF USE OR > - * PERFORMANCE OF THE SOFTWARE LIES WITH YOU. > - */ > +// SPDX-License-Identifier: GNU GPL That is not a valid identifier, please read the documentation for how to do this properly. Also, and more importantly, you picked the wrong one. Do NOT mess with license texts if you don't know what you are doing... greg k-h
Re: [PATCH] gpio: uniphier: set legitimate irq trigger type in .to_irq hook
2018-06-14 14:27 GMT+09:00 Masahiro Yamada :
> If a GPIO chip is a part of a hierarchy IRQ domain, there is no
> way to specify the trigger type when gpio(d)_to_irq() allocates an
> interrupt on-the-fly.
>
> Currently, uniphier_gpio_to_irq() sets IRQ_TYPE_NONE, but it causes
> an error in the .alloc() hook of the parent domain.
> (drivers/irq/irq-uniphier-aidet.c)
>
> Even if we change irq-uniphier-aidet.c to accept the NONE type,
> GIC complains about it since commit 83a86fbb5b56 ("irqchip/gic:
> Loudly complain about the use of IRQ_TYPE_NONE").
>
> Instead, use IRQ_TYPE_LEVEL_HIGH as a temporary value when an irq
> is allocated. irq_set_irq_type() will override it when the irq is
> really requested.
>
> Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver")
> Reported-by: Katsuhiro Suzuki
> Signed-off-by: Masahiro Yamada
> Tested-by: Katsuhiro Suzuki
> ---
BTW, gpio-xgene-sb.c is also suspicious.
https://github.com/torvalds/linux/blob/v4.17/drivers/gpio/gpio-xgene-sb.c#L136
I do not have that hardware, but GIC will complain about NONE type
if gpio(d)_to_irq() is used.
Commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of
IRQ_TYPE_NONE")
only mentions DT cases.
It is unclear how to take care of GPIO-originated IRQs.
> drivers/gpio/gpio-uniphier.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
> index d3cf950..58faeb1 100644
> --- a/drivers/gpio/gpio-uniphier.c
> +++ b/drivers/gpio/gpio-uniphier.c
> @@ -181,7 +181,11 @@ static int uniphier_gpio_to_irq(struct gpio_chip *chip,
> unsigned int offset)
> fwspec.fwnode = of_node_to_fwnode(chip->parent->of_node);
> fwspec.param_count = 2;
> fwspec.param[0] = offset - UNIPHIER_GPIO_IRQ_OFFSET;
> - fwspec.param[1] = IRQ_TYPE_NONE;
> + /*
> +* IRQ_TYPE_NONE is rejected by the parent irq domain. Set LEVEL_HIGH
> +* temporarily. Anyway, ->irq_set_type() will override it later.
> +*/
> + fwspec.param[1] = IRQ_TYPE_LEVEL_HIGH;
>
> return irq_create_fwspec_mapping();
> }
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
at 10:23 PM, Greg Kroah-Hartman wrote:
> On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
>> When balloon batching is not supported by the hypervisor, the guest
>> frame number (GFN) must fit in 32-bit. However, due to a bug, this check
>> was mistakenly ignored. In practice, when total RAM is greater than
>> 16TB, the balloon does not work currently, making this bug unlikely to
>> happen.
>>
>> Fixes: ef0f8f112984 ("VMware balloon: partially inline
>> vmballoon_reserve_page.")
>>
>> Cc: sta...@vger.kernel.org
>
> Again, no blank line between these things.
>
> Also, please break this up into two different patch series. One for
> 4.18-final and one for 4.19-rc1. You should always split up bugfixes
> from new features/cleanups as that is what I have to do when sending
> them to Linus.
I have only sent what I thought is appropriate for 4.18 (cleanup/features
will be sent separately):
* 5 bug fixes (1-5/7)
* 1 update the maintainer list (7/7)
* 1 update to the comment to prevent checkpatch from complaining (6/7)
If you think any patch is unsuitable to 4.18 - please say which.
Thanks,
Nadav
Re: [PATCH] Staging: octeon-usb: octeon-hcd.c: Remove boiler plate and add SPDX
On Wed, Jun 13, 2018 at 05:28:25PM -0400, Javier Martinez wrote: > Removed massive boiler plate text at top of the file and instead > replaced it with a simple SPDX license identifier. > > Signed-off-by: Javier Martinez > --- > drivers/staging/octeon-usb/octeon-hcd.c | 47 ++--- > 1 file changed, 2 insertions(+), 45 deletions(-) > > diff --git a/drivers/staging/octeon-usb/octeon-hcd.c > b/drivers/staging/octeon-usb/octeon-hcd.c > index cded30f145aa..df61e8321140 100644 > --- a/drivers/staging/octeon-usb/octeon-hcd.c > +++ b/drivers/staging/octeon-usb/octeon-hcd.c > @@ -1,48 +1,5 @@ > -/* > - * This file is subject to the terms and conditions of the GNU General Public > - * License. See the file "COPYING" in the main directory of this archive > - * for more details. > - * > - * Copyright (C) 2008 Cavium Networks > - * > - * Some parts of the code were originally released under BSD license: > - * > - * Copyright (c) 2003-2010 Cavium Networks (supp...@cavium.com). All rights > - * reserved. > - * > - * Redistribution and use in source and binary forms, with or without > - * modification, are permitted provided that the following conditions are > - * met: > - * > - * * Redistributions of source code must retain the above copyright > - * notice, this list of conditions and the following disclaimer. > - * > - * * Redistributions in binary form must reproduce the above > - * copyright notice, this list of conditions and the following > - * disclaimer in the documentation and/or other materials provided > - * with the distribution. > - * > - * * Neither the name of Cavium Networks nor the names of > - * its contributors may be used to endorse or promote products > - * derived from this software without specific prior written > - * permission. > - * > - * This Software, including technical data, may be subject to U.S. export > - * control laws, including the U.S. Export Administration Act and its > associated > - * regulations, and may be subject to export or import regulations in other > - * countries. > - * > - * TO THE MAXIMUM EXTENT PERMITTED BY LAW, THE SOFTWARE IS PROVIDED "AS IS" > - * AND WITH ALL FAULTS AND CAVIUM NETWORKS MAKES NO PROMISES, > REPRESENTATIONS OR > - * WARRANTIES, EITHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, WITH > RESPECT TO > - * THE SOFTWARE, INCLUDING ITS CONDITION, ITS CONFORMITY TO ANY > REPRESENTATION > - * OR DESCRIPTION, OR THE EXISTENCE OF ANY LATENT OR PATENT DEFECTS, AND > CAVIUM > - * SPECIFICALLY DISCLAIMS ALL IMPLIED (IF ANY) WARRANTIES OF TITLE, > - * MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE, LACK > OF > - * VIRUSES, ACCURACY OR COMPLETENESS, QUIET ENJOYMENT, QUIET POSSESSION OR > - * CORRESPONDENCE TO DESCRIPTION. THE ENTIRE RISK ARISING OUT OF USE OR > - * PERFORMANCE OF THE SOFTWARE LIES WITH YOU. > - */ > +// SPDX-License-Identifier: GNU GPL That is not a valid identifier, please read the documentation for how to do this properly. Also, and more importantly, you picked the wrong one. Do NOT mess with license texts if you don't know what you are doing... greg k-h
Re: [PATCH] gpio: uniphier: set legitimate irq trigger type in .to_irq hook
2018-06-14 14:27 GMT+09:00 Masahiro Yamada :
> If a GPIO chip is a part of a hierarchy IRQ domain, there is no
> way to specify the trigger type when gpio(d)_to_irq() allocates an
> interrupt on-the-fly.
>
> Currently, uniphier_gpio_to_irq() sets IRQ_TYPE_NONE, but it causes
> an error in the .alloc() hook of the parent domain.
> (drivers/irq/irq-uniphier-aidet.c)
>
> Even if we change irq-uniphier-aidet.c to accept the NONE type,
> GIC complains about it since commit 83a86fbb5b56 ("irqchip/gic:
> Loudly complain about the use of IRQ_TYPE_NONE").
>
> Instead, use IRQ_TYPE_LEVEL_HIGH as a temporary value when an irq
> is allocated. irq_set_irq_type() will override it when the irq is
> really requested.
>
> Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver")
> Reported-by: Katsuhiro Suzuki
> Signed-off-by: Masahiro Yamada
> Tested-by: Katsuhiro Suzuki
> ---
BTW, gpio-xgene-sb.c is also suspicious.
https://github.com/torvalds/linux/blob/v4.17/drivers/gpio/gpio-xgene-sb.c#L136
I do not have that hardware, but GIC will complain about NONE type
if gpio(d)_to_irq() is used.
Commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of
IRQ_TYPE_NONE")
only mentions DT cases.
It is unclear how to take care of GPIO-originated IRQs.
> drivers/gpio/gpio-uniphier.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
> index d3cf950..58faeb1 100644
> --- a/drivers/gpio/gpio-uniphier.c
> +++ b/drivers/gpio/gpio-uniphier.c
> @@ -181,7 +181,11 @@ static int uniphier_gpio_to_irq(struct gpio_chip *chip,
> unsigned int offset)
> fwspec.fwnode = of_node_to_fwnode(chip->parent->of_node);
> fwspec.param_count = 2;
> fwspec.param[0] = offset - UNIPHIER_GPIO_IRQ_OFFSET;
> - fwspec.param[1] = IRQ_TYPE_NONE;
> + /*
> +* IRQ_TYPE_NONE is rejected by the parent irq domain. Set LEVEL_HIGH
> +* temporarily. Anyway, ->irq_set_type() will override it later.
> +*/
> + fwspec.param[1] = IRQ_TYPE_LEVEL_HIGH;
>
> return irq_create_fwspec_mapping();
> }
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
Re: [PATCH] selftests: vm: return Kselftest Skip code for skipped tests
On Wed, Jun 13, 2018 at 09:35:57PM -0600, Shuah Khan (Samsung OSG) wrote:
> When vm test is skipped because of unmet dependencies and/or unsupported
> configuration, it exits with error which is treated as a fail by the
> Kselftest framework. This leads to false negative result even when the
> test could not be run.
>
> Change it to return kselftest skip code when a test gets skipped to
> clearly report that the test could not be run.
>
> Kselftest framework SKIP code is 4 and the framework prints appropriate
> messages to indicate that the test is skipped.
>
> Signed-off-by: Shuah Khan (Samsung OSG)
For the userfaultfd test
Acked-by: Mike Rapoport
> ---
> tools/testing/selftests/vm/compaction_test.c | 4 +++-
> tools/testing/selftests/vm/mlock2-tests.c| 12 +++-
> tools/testing/selftests/vm/run_vmtests | 5 -
> tools/testing/selftests/vm/userfaultfd.c | 4 +++-
> 4 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/tools/testing/selftests/vm/compaction_test.c
> b/tools/testing/selftests/vm/compaction_test.c
> index 1097f04e4d80..bcec71250873 100644
> --- a/tools/testing/selftests/vm/compaction_test.c
> +++ b/tools/testing/selftests/vm/compaction_test.c
> @@ -16,6 +16,8 @@
> #include
> #include
>
> +#include "../kselftest.h"
> +
> #define MAP_SIZE 1048576
>
> struct map_list {
> @@ -169,7 +171,7 @@ int main(int argc, char **argv)
> printf("Either the sysctl compact_unevictable_allowed is not\n"
> "set to 1 or couldn't read the proc file.\n"
> "Skipping the test\n");
> - return 0;
> + return KSFT_SKIP;
> }
>
> lim.rlim_cur = RLIM_INFINITY;
> diff --git a/tools/testing/selftests/vm/mlock2-tests.c
> b/tools/testing/selftests/vm/mlock2-tests.c
> index 4997b9222cfa..637b6d0ac0d0 100644
> --- a/tools/testing/selftests/vm/mlock2-tests.c
> +++ b/tools/testing/selftests/vm/mlock2-tests.c
> @@ -9,6 +9,8 @@
> #include
> #include "mlock2.h"
>
> +#include "../kselftest.h"
> +
> struct vm_boundaries {
> unsigned long start;
> unsigned long end;
> @@ -303,7 +305,7 @@ static int test_mlock_lock()
> if (mlock2_(map, 2 * page_size, 0)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock2(0)");
> goto unmap;
> @@ -412,7 +414,7 @@ static int test_mlock_onfault()
> if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock2(MLOCK_ONFAULT)");
> goto unmap;
> @@ -425,7 +427,7 @@ static int test_mlock_onfault()
> if (munlock(map, 2 * page_size)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("munlock()");
> goto unmap;
> @@ -457,7 +459,7 @@ static int test_lock_onfault_of_present()
> if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock2(MLOCK_ONFAULT)");
> goto unmap;
> @@ -583,7 +585,7 @@ static int test_vma_management(bool call_mlock)
> if (call_mlock && mlock2_(map, 3 * page_size, MLOCK_ONFAULT)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock(ONFAULT)\n");
> goto out;
> diff --git a/tools/testing/selftests/vm/run_vmtests
> b/tools/testing/selftests/vm/run_vmtests
> index 22d564673830..88cbe5575f0c 100755
> --- a/tools/testing/selftests/vm/run_vmtests
> +++ b/tools/testing/selftests/vm/run_vmtests
> @@ -2,6 +2,9 @@
> # SPDX-License-Identifier: GPL-2.0
> #please run as root
>
> +# Kselftest framework requirement - SKIP code is 4.
> +ksft_skip=4
> +
> mnt=./huge
> exitcode=0
>
> @@ -36,7 +39,7 @@ if [ -n "$freepgs" ] && [ -n "$hpgsize_KB" ]; then
> echo $(( $lackpgs + $nr_hugepgs )) > /proc/sys/vm/nr_hugepages
> if [ $? -ne 0 ]; then
> echo "Please run this test as root"
> - exit 1
> + exit $ksft_skip
> fi
> while read name size unit; do
> if [ "$name" = "HugePages_Free:" ];
Re: [PATCH] selftests: vm: return Kselftest Skip code for skipped tests
On Wed, Jun 13, 2018 at 09:35:57PM -0600, Shuah Khan (Samsung OSG) wrote:
> When vm test is skipped because of unmet dependencies and/or unsupported
> configuration, it exits with error which is treated as a fail by the
> Kselftest framework. This leads to false negative result even when the
> test could not be run.
>
> Change it to return kselftest skip code when a test gets skipped to
> clearly report that the test could not be run.
>
> Kselftest framework SKIP code is 4 and the framework prints appropriate
> messages to indicate that the test is skipped.
>
> Signed-off-by: Shuah Khan (Samsung OSG)
For the userfaultfd test
Acked-by: Mike Rapoport
> ---
> tools/testing/selftests/vm/compaction_test.c | 4 +++-
> tools/testing/selftests/vm/mlock2-tests.c| 12 +++-
> tools/testing/selftests/vm/run_vmtests | 5 -
> tools/testing/selftests/vm/userfaultfd.c | 4 +++-
> 4 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/tools/testing/selftests/vm/compaction_test.c
> b/tools/testing/selftests/vm/compaction_test.c
> index 1097f04e4d80..bcec71250873 100644
> --- a/tools/testing/selftests/vm/compaction_test.c
> +++ b/tools/testing/selftests/vm/compaction_test.c
> @@ -16,6 +16,8 @@
> #include
> #include
>
> +#include "../kselftest.h"
> +
> #define MAP_SIZE 1048576
>
> struct map_list {
> @@ -169,7 +171,7 @@ int main(int argc, char **argv)
> printf("Either the sysctl compact_unevictable_allowed is not\n"
> "set to 1 or couldn't read the proc file.\n"
> "Skipping the test\n");
> - return 0;
> + return KSFT_SKIP;
> }
>
> lim.rlim_cur = RLIM_INFINITY;
> diff --git a/tools/testing/selftests/vm/mlock2-tests.c
> b/tools/testing/selftests/vm/mlock2-tests.c
> index 4997b9222cfa..637b6d0ac0d0 100644
> --- a/tools/testing/selftests/vm/mlock2-tests.c
> +++ b/tools/testing/selftests/vm/mlock2-tests.c
> @@ -9,6 +9,8 @@
> #include
> #include "mlock2.h"
>
> +#include "../kselftest.h"
> +
> struct vm_boundaries {
> unsigned long start;
> unsigned long end;
> @@ -303,7 +305,7 @@ static int test_mlock_lock()
> if (mlock2_(map, 2 * page_size, 0)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock2(0)");
> goto unmap;
> @@ -412,7 +414,7 @@ static int test_mlock_onfault()
> if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock2(MLOCK_ONFAULT)");
> goto unmap;
> @@ -425,7 +427,7 @@ static int test_mlock_onfault()
> if (munlock(map, 2 * page_size)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("munlock()");
> goto unmap;
> @@ -457,7 +459,7 @@ static int test_lock_onfault_of_present()
> if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock2(MLOCK_ONFAULT)");
> goto unmap;
> @@ -583,7 +585,7 @@ static int test_vma_management(bool call_mlock)
> if (call_mlock && mlock2_(map, 3 * page_size, MLOCK_ONFAULT)) {
> if (errno == ENOSYS) {
> printf("Cannot call new mlock family, skipping test\n");
> - _exit(0);
> + _exit(KSFT_SKIP);
> }
> perror("mlock(ONFAULT)\n");
> goto out;
> diff --git a/tools/testing/selftests/vm/run_vmtests
> b/tools/testing/selftests/vm/run_vmtests
> index 22d564673830..88cbe5575f0c 100755
> --- a/tools/testing/selftests/vm/run_vmtests
> +++ b/tools/testing/selftests/vm/run_vmtests
> @@ -2,6 +2,9 @@
> # SPDX-License-Identifier: GPL-2.0
> #please run as root
>
> +# Kselftest framework requirement - SKIP code is 4.
> +ksft_skip=4
> +
> mnt=./huge
> exitcode=0
>
> @@ -36,7 +39,7 @@ if [ -n "$freepgs" ] && [ -n "$hpgsize_KB" ]; then
> echo $(( $lackpgs + $nr_hugepgs )) > /proc/sys/vm/nr_hugepages
> if [ $? -ne 0 ]; then
> echo "Please run this test as root"
> - exit 1
> + exit $ksft_skip
> fi
> while read name size unit; do
> if [ "$name" = "HugePages_Free:" ];
RE: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values from DT
Ping for RFC
> -Original Message-
> From: Manish Narani [mailto:manish.nar...@xilinx.com]
> Sent: Thursday, June 7, 2018 5:42 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; m...@kernel.org; stefan.krsmano...@aggios.com;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> m...@vger.kernel.org; devicet...@vger.kernel.org;
> adrian.hun...@intel.com; michal.si...@xilinx.com; ulf.hans...@linaro.org
> Cc: Manish Narani
> Subject: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values
> from DT
>
> This patch adds support for reading Tap Delay values from Device Tree and
> write them via eemi calls. The macros containing these tap delay values are
> removed from the driver.
>
> Signed-off-by: Manish Narani
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 131
> +
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-
> of-arasan.c
> index e3332a5..fc0fd01 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -36,6 +36,8 @@
>
> #define PHY_CLK_TOO_SLOW_HZ 40
>
> +#define MMC_BANK20x2
> +
> /*
> * On some SoCs the syscon area has a feature where the upper 16-bits of
> * each 32-bit register act as a write mask for the lower 16-bits. This
> allows
> @@ -90,6 +92,10 @@ struct sdhci_arasan_data {
> struct sdhci_host *host;
> struct clk *clk_ahb;
> struct phy *phy;
> + u32 mio_bank;
> + u32 device_id;
> + u32 itapdly[MMC_TIMING_MMC_HS400 + 1];
> + u32 otapdly[MMC_TIMING_MMC_HS400 + 1];
> boolis_phy_on;
>
> boolhas_cqe;
> @@ -160,11 +166,36 @@ static int sdhci_arasan_syscon_write(struct
> sdhci_host *host,
> return ret;
> }
>
> +/**
> + * arasan_zynqmp_set_tap_delay - Program the tap delays.
> + * @deviceid:Unique Id of device
> + * @itap_delay: Input Tap Delay
> + * @oitap_delay: Output Tap Delay
> + */
> +static void arasan_zynqmp_set_tap_delay(u8 deviceid, u8 itap_delay, u8
> +otap_delay) {
> + const struct zynqmp_eemi_ops *eemi_ops =
> zynqmp_pm_get_eemi_ops();
> + u32 node_id = (deviceid == 0) ? NODE_SD_0 : NODE_SD_1;
> +
> + if (!eemi_ops || !eemi_ops->ioctl)
> + return;
> +
> + if (itap_delay)
> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> + PM_TAPDELAY_INPUT, itap_delay, NULL);
> +
> + if (otap_delay)
> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> + PM_TAPDELAY_OUTPUT, otap_delay, NULL);
> }
> +
> static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int
> clock) {
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> bool ctrl_phy = false;
> + u8 itap_delay;
> + u8 otap_delay;
>
> if (!IS_ERR(sdhci_arasan->phy)) {
> if (!sdhci_arasan->is_phy_on && clock <=
> PHY_CLK_TOO_SLOW_HZ) { @@ -200,6 +231,16 @@ static void
> sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
> }
> }
>
> + if (host->version >= SDHCI_SPEC_300) {
> + if ((host->timing != MMC_TIMING_LEGACY) &&
> + (host->timing != MMC_TIMING_UHS_SDR12)) {
> + itap_delay = sdhci_arasan->itapdly[host->timing];
> + otap_delay = sdhci_arasan->otapdly[host->timing];
> + arasan_zynqmp_set_tap_delay(sdhci_arasan-
> >device_id,
> + itap_delay, otap_delay);
> + }
> + }
> +
> if (ctrl_phy && sdhci_arasan->is_phy_on) {
> phy_power_off(sdhci_arasan->phy);
> sdhci_arasan->is_phy_on = false;
> @@ -456,6 +497,7 @@ static const struct of_device_id
> sdhci_arasan_of_match[] = {
> { .compatible = "arasan,sdhci-8.9a" },
> { .compatible = "arasan,sdhci-5.1" },
> { .compatible = "arasan,sdhci-4.9a" },
> + { .compatible = "xlnx,zynqmp-8.9a" },
>
> { /* sentinel */ }
> };
> @@ -641,6 +683,74 @@ static void sdhci_arasan_unregister_sdclk(struct
> device *dev)
> of_clk_del_provider(dev->of_node);
> }
>
> +/**
> + * arasan_zynqmp_dt_parse_tap_delays - Read Tap Delay values from DT
> + *
> + * Called at initialization to parse the values of Tap Delays.
> + *
> + * @dev: Pointer to our struct device.
> + */
> +static void arasan_zynqmp_dt_parse_tap_delays(struct device *dev) {
> + struct platform_device *pdev = to_platform_device(dev);
> + struct sdhci_host *host = platform_get_drvdata(pdev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> +
Re: [PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
On Thu, Jun 14, 2018 at 05:16:18AM +, Naoya Horiguchi wrote:
> On Wed, Jun 13, 2018 at 11:07:00AM +0200, Michal Hocko wrote:
> > On Wed 13-06-18 05:41:08, Naoya Horiguchi wrote:
> > [...]
> > > From: Naoya Horiguchi
> > > Date: Wed, 13 Jun 2018 12:43:27 +0900
> > > Subject: [PATCH] mm: zero remaining unavailable struct pages
> > >
> > > There is a kernel panic that is triggered when reading /proc/kpageflags
> > > on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
> > >
> > > BUG: unable to handle kernel paging request at fffe
> > > PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
> > > Oops: [#1] SMP PTI
> > > CPU: 2 PID: 1728 Comm: page-types Not tainted
> > > 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
> > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > > 1.11.0-2.fc28 04/01/2014
> > > RIP: 0010:stable_page_flags+0x27/0x3c0
> > > Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89
> > > fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6
> > > c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
> > > RSP: 0018:bbd44111fde0 EFLAGS: 00010202
> > > RAX: fffe RBX: 7fffeff9 RCX:
> > > RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
> > > RBP: R08: 0001 R09: 0001
> > > R10: bbd44111fed8 R11: R12: ed1182fff5c0
> > > R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
> > > FS: 7efc4335a500() GS:93a5bfc0()
> > > knlGS:
> > > CS: 0010 DS: ES: CR0: 80050033
> > > CR2: fffe CR3: b2a58000 CR4: 001406e0
> > > Call Trace:
> > >kpageflags_read+0xc7/0x120
> > >proc_reg_read+0x3c/0x60
> > >__vfs_read+0x36/0x170
> > >vfs_read+0x89/0x130
> > >ksys_pread64+0x71/0x90
> > >do_syscall_64+0x5b/0x160
> > >entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > RIP: 0033:0x7efc42e75e23
> > > Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00
> > > 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0
> > > ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
> > >
> > > According to kernel bisection, this problem became visible due to commit
> > > f7f99100d8d9 which changes how struct pages are initialized.
> > >
> > > Memblock layout affects the pfn ranges covered by node/zone. Consider
> > > that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
> > > the default (no memmap= given) memblock layout is like below:
> > >
> > > MEMBLOCK configuration:
> > >memory size = 0x0001fff75c00 reserved size = 0x0300c000
> > >memory.cnt = 0x4
> > >memory[0x0] [0x1000-0x0009efff],
> > > 0x0009e000 bytes on node 0 flags: 0x0
> > >memory[0x1] [0x0010-0xbffd6fff],
> > > 0xbfed7000 bytes on node 0 flags: 0x0
> > >memory[0x2] [0x0001-0x00013fff],
> > > 0x4000 bytes on node 0 flags: 0x0
> > >memory[0x3] [0x00014000-0x00023fff],
> > > 0x0001 bytes on node 1 flags: 0x0
> > >...
> > >
> > > If you give memmap=1G!4G (so it just covers memory[0x2]),
> > > the range [0x1-0x13fff] is gone:
> > >
> > > MEMBLOCK configuration:
> > >memory size = 0x0001bff75c00 reserved size = 0x0300c000
> > >memory.cnt = 0x3
> > >memory[0x0] [0x1000-0x0009efff],
> > > 0x0009e000 bytes on node 0 flags: 0x0
> > >memory[0x1] [0x0010-0xbffd6fff],
> > > 0xbfed7000 bytes on node 0 flags: 0x0
> > >memory[0x2] [0x00014000-0x00023fff],
> > > 0x0001 bytes on node 1 flags: 0x0
> > >...
> > >
> > > This causes shrinking node 0's pfn range because it is calculated by
> > > the address range of memblock.memory. So some of struct pages in the
> > > gap range are left uninitialized.
> > >
> > > We have a function zero_resv_unavail() which does zeroing the struct
> > > pages outside memblock.memory, but currently it covers only the reserved
> > > unavailable range (i.e. memblock.memory && !memblock.reserved).
> > > This patch extends it to cover all unavailable range, which fixes
> > > the reported issue.
> >
> > Thanks for pin pointing this down Naoya! I am wondering why we cannot
> > simply mark the excluded ranges to be reserved instead.
>
> I tried your idea with the change below, and it also fixes the kernel panic.
>
> ---
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index d1f25c831447..2cef120535d4 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -1248,6 +1248,7 @@ void __init e820__memblock_setup(void)
> {
> int i;
> u64 end;
> + u64 addr = 0;
>
Re: [PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
On Thu, Jun 14, 2018 at 05:16:18AM +, Naoya Horiguchi wrote:
> On Wed, Jun 13, 2018 at 11:07:00AM +0200, Michal Hocko wrote:
> > On Wed 13-06-18 05:41:08, Naoya Horiguchi wrote:
> > [...]
> > > From: Naoya Horiguchi
> > > Date: Wed, 13 Jun 2018 12:43:27 +0900
> > > Subject: [PATCH] mm: zero remaining unavailable struct pages
> > >
> > > There is a kernel panic that is triggered when reading /proc/kpageflags
> > > on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
> > >
> > > BUG: unable to handle kernel paging request at fffe
> > > PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
> > > Oops: [#1] SMP PTI
> > > CPU: 2 PID: 1728 Comm: page-types Not tainted
> > > 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
> > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > > 1.11.0-2.fc28 04/01/2014
> > > RIP: 0010:stable_page_flags+0x27/0x3c0
> > > Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89
> > > fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6
> > > c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
> > > RSP: 0018:bbd44111fde0 EFLAGS: 00010202
> > > RAX: fffe RBX: 7fffeff9 RCX:
> > > RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
> > > RBP: R08: 0001 R09: 0001
> > > R10: bbd44111fed8 R11: R12: ed1182fff5c0
> > > R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
> > > FS: 7efc4335a500() GS:93a5bfc0()
> > > knlGS:
> > > CS: 0010 DS: ES: CR0: 80050033
> > > CR2: fffe CR3: b2a58000 CR4: 001406e0
> > > Call Trace:
> > >kpageflags_read+0xc7/0x120
> > >proc_reg_read+0x3c/0x60
> > >__vfs_read+0x36/0x170
> > >vfs_read+0x89/0x130
> > >ksys_pread64+0x71/0x90
> > >do_syscall_64+0x5b/0x160
> > >entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > RIP: 0033:0x7efc42e75e23
> > > Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00
> > > 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0
> > > ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
> > >
> > > According to kernel bisection, this problem became visible due to commit
> > > f7f99100d8d9 which changes how struct pages are initialized.
> > >
> > > Memblock layout affects the pfn ranges covered by node/zone. Consider
> > > that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
> > > the default (no memmap= given) memblock layout is like below:
> > >
> > > MEMBLOCK configuration:
> > >memory size = 0x0001fff75c00 reserved size = 0x0300c000
> > >memory.cnt = 0x4
> > >memory[0x0] [0x1000-0x0009efff],
> > > 0x0009e000 bytes on node 0 flags: 0x0
> > >memory[0x1] [0x0010-0xbffd6fff],
> > > 0xbfed7000 bytes on node 0 flags: 0x0
> > >memory[0x2] [0x0001-0x00013fff],
> > > 0x4000 bytes on node 0 flags: 0x0
> > >memory[0x3] [0x00014000-0x00023fff],
> > > 0x0001 bytes on node 1 flags: 0x0
> > >...
> > >
> > > If you give memmap=1G!4G (so it just covers memory[0x2]),
> > > the range [0x1-0x13fff] is gone:
> > >
> > > MEMBLOCK configuration:
> > >memory size = 0x0001bff75c00 reserved size = 0x0300c000
> > >memory.cnt = 0x3
> > >memory[0x0] [0x1000-0x0009efff],
> > > 0x0009e000 bytes on node 0 flags: 0x0
> > >memory[0x1] [0x0010-0xbffd6fff],
> > > 0xbfed7000 bytes on node 0 flags: 0x0
> > >memory[0x2] [0x00014000-0x00023fff],
> > > 0x0001 bytes on node 1 flags: 0x0
> > >...
> > >
> > > This causes shrinking node 0's pfn range because it is calculated by
> > > the address range of memblock.memory. So some of struct pages in the
> > > gap range are left uninitialized.
> > >
> > > We have a function zero_resv_unavail() which does zeroing the struct
> > > pages outside memblock.memory, but currently it covers only the reserved
> > > unavailable range (i.e. memblock.memory && !memblock.reserved).
> > > This patch extends it to cover all unavailable range, which fixes
> > > the reported issue.
> >
> > Thanks for pin pointing this down Naoya! I am wondering why we cannot
> > simply mark the excluded ranges to be reserved instead.
>
> I tried your idea with the change below, and it also fixes the kernel panic.
>
> ---
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index d1f25c831447..2cef120535d4 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -1248,6 +1248,7 @@ void __init e820__memblock_setup(void)
> {
> int i;
> u64 end;
> + u64 addr = 0;
>
RE: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values from DT
Ping for RFC
> -Original Message-
> From: Manish Narani [mailto:manish.nar...@xilinx.com]
> Sent: Thursday, June 7, 2018 5:42 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; m...@kernel.org; stefan.krsmano...@aggios.com;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> m...@vger.kernel.org; devicet...@vger.kernel.org;
> adrian.hun...@intel.com; michal.si...@xilinx.com; ulf.hans...@linaro.org
> Cc: Manish Narani
> Subject: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values
> from DT
>
> This patch adds support for reading Tap Delay values from Device Tree and
> write them via eemi calls. The macros containing these tap delay values are
> removed from the driver.
>
> Signed-off-by: Manish Narani
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 131
> +
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-
> of-arasan.c
> index e3332a5..fc0fd01 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -36,6 +36,8 @@
>
> #define PHY_CLK_TOO_SLOW_HZ 40
>
> +#define MMC_BANK20x2
> +
> /*
> * On some SoCs the syscon area has a feature where the upper 16-bits of
> * each 32-bit register act as a write mask for the lower 16-bits. This
> allows
> @@ -90,6 +92,10 @@ struct sdhci_arasan_data {
> struct sdhci_host *host;
> struct clk *clk_ahb;
> struct phy *phy;
> + u32 mio_bank;
> + u32 device_id;
> + u32 itapdly[MMC_TIMING_MMC_HS400 + 1];
> + u32 otapdly[MMC_TIMING_MMC_HS400 + 1];
> boolis_phy_on;
>
> boolhas_cqe;
> @@ -160,11 +166,36 @@ static int sdhci_arasan_syscon_write(struct
> sdhci_host *host,
> return ret;
> }
>
> +/**
> + * arasan_zynqmp_set_tap_delay - Program the tap delays.
> + * @deviceid:Unique Id of device
> + * @itap_delay: Input Tap Delay
> + * @oitap_delay: Output Tap Delay
> + */
> +static void arasan_zynqmp_set_tap_delay(u8 deviceid, u8 itap_delay, u8
> +otap_delay) {
> + const struct zynqmp_eemi_ops *eemi_ops =
> zynqmp_pm_get_eemi_ops();
> + u32 node_id = (deviceid == 0) ? NODE_SD_0 : NODE_SD_1;
> +
> + if (!eemi_ops || !eemi_ops->ioctl)
> + return;
> +
> + if (itap_delay)
> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> + PM_TAPDELAY_INPUT, itap_delay, NULL);
> +
> + if (otap_delay)
> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
> + PM_TAPDELAY_OUTPUT, otap_delay, NULL);
> }
> +
> static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int
> clock) {
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> bool ctrl_phy = false;
> + u8 itap_delay;
> + u8 otap_delay;
>
> if (!IS_ERR(sdhci_arasan->phy)) {
> if (!sdhci_arasan->is_phy_on && clock <=
> PHY_CLK_TOO_SLOW_HZ) { @@ -200,6 +231,16 @@ static void
> sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
> }
> }
>
> + if (host->version >= SDHCI_SPEC_300) {
> + if ((host->timing != MMC_TIMING_LEGACY) &&
> + (host->timing != MMC_TIMING_UHS_SDR12)) {
> + itap_delay = sdhci_arasan->itapdly[host->timing];
> + otap_delay = sdhci_arasan->otapdly[host->timing];
> + arasan_zynqmp_set_tap_delay(sdhci_arasan-
> >device_id,
> + itap_delay, otap_delay);
> + }
> + }
> +
> if (ctrl_phy && sdhci_arasan->is_phy_on) {
> phy_power_off(sdhci_arasan->phy);
> sdhci_arasan->is_phy_on = false;
> @@ -456,6 +497,7 @@ static const struct of_device_id
> sdhci_arasan_of_match[] = {
> { .compatible = "arasan,sdhci-8.9a" },
> { .compatible = "arasan,sdhci-5.1" },
> { .compatible = "arasan,sdhci-4.9a" },
> + { .compatible = "xlnx,zynqmp-8.9a" },
>
> { /* sentinel */ }
> };
> @@ -641,6 +683,74 @@ static void sdhci_arasan_unregister_sdclk(struct
> device *dev)
> of_clk_del_provider(dev->of_node);
> }
>
> +/**
> + * arasan_zynqmp_dt_parse_tap_delays - Read Tap Delay values from DT
> + *
> + * Called at initialization to parse the values of Tap Delays.
> + *
> + * @dev: Pointer to our struct device.
> + */
> +static void arasan_zynqmp_dt_parse_tap_delays(struct device *dev) {
> + struct platform_device *pdev = to_platform_device(dev);
> + struct sdhci_host *host = platform_get_drvdata(pdev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> +
[PATCH v4 4/7] dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct sdma_channel'
Since 'sdmac->vc.lock' and 'sdmac->desc' can be used as 'lock' and
'enabled' in 'struct sdma_channel sdmac', remove them.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 719bf9f..27b76eb 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -349,10 +349,8 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- spinlock_t lock;
enum dma_status status;
struct imx_dma_data data;
- boolenabled;
};
#define IMX_DMA_SG_LOOPBIT(0)
@@ -613,14 +611,7 @@ static int sdma_config_ownership(struct sdma_channel
*sdmac,
static void sdma_enable_channel(struct sdma_engine *sdma, int channel)
{
- unsigned long flags;
- struct sdma_channel *sdmac = >channel[channel];
-
writel(BIT(channel), sdma->regs + SDMA_H_START);
-
- spin_lock_irqsave(>lock, flags);
- sdmac->enabled = true;
- spin_unlock_irqrestore(>lock, flags);
}
/*
@@ -738,14 +729,6 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
struct sdma_buffer_descriptor *bd;
int error = 0;
enum dma_status old_status = sdmac->status;
- unsigned long flags;
-
- spin_lock_irqsave(>lock, flags);
- if (!sdmac->enabled) {
- spin_unlock_irqrestore(>lock, flags);
- return;
- }
- spin_unlock_irqrestore(>lock, flags);
/*
* loop mode. Iterate over descriptors, re-setup them and
@@ -1007,15 +990,10 @@ static int sdma_disable_channel(struct dma_chan *chan)
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
- unsigned long flags;
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
sdmac->status = DMA_ERROR;
- spin_lock_irqsave(>lock, flags);
- sdmac->enabled = false;
- spin_unlock_irqrestore(>lock, flags);
-
return 0;
}
@@ -1929,7 +1907,6 @@ static int sdma_probe(struct platform_device *pdev)
struct sdma_channel *sdmac = >channel[i];
sdmac->sdma = sdma;
- spin_lock_init(>lock);
sdmac->channel = i;
sdmac->vc.desc_free = sdma_desc_free;
--
2.7.4
[PATCH v4 4/7] dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct sdma_channel'
Since 'sdmac->vc.lock' and 'sdmac->desc' can be used as 'lock' and
'enabled' in 'struct sdma_channel sdmac', remove them.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 719bf9f..27b76eb 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -349,10 +349,8 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- spinlock_t lock;
enum dma_status status;
struct imx_dma_data data;
- boolenabled;
};
#define IMX_DMA_SG_LOOPBIT(0)
@@ -613,14 +611,7 @@ static int sdma_config_ownership(struct sdma_channel
*sdmac,
static void sdma_enable_channel(struct sdma_engine *sdma, int channel)
{
- unsigned long flags;
- struct sdma_channel *sdmac = >channel[channel];
-
writel(BIT(channel), sdma->regs + SDMA_H_START);
-
- spin_lock_irqsave(>lock, flags);
- sdmac->enabled = true;
- spin_unlock_irqrestore(>lock, flags);
}
/*
@@ -738,14 +729,6 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
struct sdma_buffer_descriptor *bd;
int error = 0;
enum dma_status old_status = sdmac->status;
- unsigned long flags;
-
- spin_lock_irqsave(>lock, flags);
- if (!sdmac->enabled) {
- spin_unlock_irqrestore(>lock, flags);
- return;
- }
- spin_unlock_irqrestore(>lock, flags);
/*
* loop mode. Iterate over descriptors, re-setup them and
@@ -1007,15 +990,10 @@ static int sdma_disable_channel(struct dma_chan *chan)
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
- unsigned long flags;
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
sdmac->status = DMA_ERROR;
- spin_lock_irqsave(>lock, flags);
- sdmac->enabled = false;
- spin_unlock_irqrestore(>lock, flags);
-
return 0;
}
@@ -1929,7 +1907,6 @@ static int sdma_probe(struct platform_device *pdev)
struct sdma_channel *sdmac = >channel[i];
sdmac->sdma = sdma;
- spin_lock_init(>lock);
sdmac->channel = i;
sdmac->vc.desc_free = sdma_desc_free;
--
2.7.4
[PATCH v4 3/7] dmaengine: imx-sdma: add virt-dma support
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Signed-off-by: Robin Gong
---
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 261 -
2 files changed, 170 insertions(+), 92 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6d61cd0..78715a2 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -257,6 +257,7 @@ config IMX_SDMA
tristate "i.MX SDMA support"
depends on ARCH_MXC
select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
help
Support the i.MX SDMA engine. This engine is integrated into
Freescale i.MX25/31/35/51/53/6 chips.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 556d087..719bf9f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -48,6 +48,7 @@
#include
#include "dmaengine.h"
+#include "virt-dma.h"
/* SDMA registers */
#define SDMA_H_C0PTR 0x000
@@ -308,6 +309,7 @@ struct sdma_engine;
* @bd pointer of alloced bd
*/
struct sdma_desc {
+ struct virt_dma_descvd;
unsigned intnum_bd;
dma_addr_t bd_phys;
unsigned intbuf_tail;
@@ -331,8 +333,8 @@ struct sdma_desc {
* @word_size peripheral access size
*/
struct sdma_channel {
+ struct virt_dma_chanvc;
struct sdma_desc*desc;
- struct sdma_desc_desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -347,11 +349,8 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- struct tasklet_struct tasklet;
struct imx_dma_data data;
boolenabled;
};
@@ -705,6 +704,35 @@ static void sdma_event_disable(struct sdma_channel *sdmac,
unsigned int event)
writel_relaxed(val, sdma->regs + chnenbl);
}
+static struct sdma_desc *to_sdma_desc(struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct sdma_desc, vd.tx);
+}
+
+static void sdma_start_desc(struct sdma_channel *sdmac)
+{
+ struct virt_dma_desc *vd = vchan_next_desc(>vc);
+ struct sdma_desc *desc;
+ struct sdma_engine *sdma = sdmac->sdma;
+ int channel = sdmac->channel;
+
+ if (!vd) {
+ sdmac->desc = NULL;
+ return;
+ }
+ sdmac->desc = desc = to_sdma_desc(>tx);
+ /*
+* Do not delete the node in desc_issued list in cyclic mode, otherwise
+* the desc alloced will never be freed in vchan_dma_desc_free_list
+*/
+ if (!(sdmac->flags & IMX_DMA_SG_LOOP))
+ list_del(>node);
+
+ sdma->channel_control[channel].base_bd_ptr = desc->bd_phys;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
+ sdma_enable_channel(sdma, sdmac->channel);
+}
+
static void sdma_update_channel_loop(struct sdma_channel *sdmac)
{
struct sdma_buffer_descriptor *bd;
@@ -723,7 +751,7 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* loop mode. Iterate over descriptors, re-setup them and
* call callback function.
*/
- while (1) {
+ while (sdmac->desc) {
struct sdma_desc *desc = sdmac->desc;
bd = >bd[desc->buf_tail];
@@ -754,15 +782,16 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* SDMA transaction status by the time the client tasklet is
* executed.
*/
-
- dmaengine_desc_get_callback_invoke(>txdesc, NULL);
+
[PATCH v4 3/7] dmaengine: imx-sdma: add virt-dma support
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Signed-off-by: Robin Gong
---
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 261 -
2 files changed, 170 insertions(+), 92 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6d61cd0..78715a2 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -257,6 +257,7 @@ config IMX_SDMA
tristate "i.MX SDMA support"
depends on ARCH_MXC
select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
help
Support the i.MX SDMA engine. This engine is integrated into
Freescale i.MX25/31/35/51/53/6 chips.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 556d087..719bf9f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -48,6 +48,7 @@
#include
#include "dmaengine.h"
+#include "virt-dma.h"
/* SDMA registers */
#define SDMA_H_C0PTR 0x000
@@ -308,6 +309,7 @@ struct sdma_engine;
* @bd pointer of alloced bd
*/
struct sdma_desc {
+ struct virt_dma_descvd;
unsigned intnum_bd;
dma_addr_t bd_phys;
unsigned intbuf_tail;
@@ -331,8 +333,8 @@ struct sdma_desc {
* @word_size peripheral access size
*/
struct sdma_channel {
+ struct virt_dma_chanvc;
struct sdma_desc*desc;
- struct sdma_desc_desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -347,11 +349,8 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- struct tasklet_struct tasklet;
struct imx_dma_data data;
boolenabled;
};
@@ -705,6 +704,35 @@ static void sdma_event_disable(struct sdma_channel *sdmac,
unsigned int event)
writel_relaxed(val, sdma->regs + chnenbl);
}
+static struct sdma_desc *to_sdma_desc(struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct sdma_desc, vd.tx);
+}
+
+static void sdma_start_desc(struct sdma_channel *sdmac)
+{
+ struct virt_dma_desc *vd = vchan_next_desc(>vc);
+ struct sdma_desc *desc;
+ struct sdma_engine *sdma = sdmac->sdma;
+ int channel = sdmac->channel;
+
+ if (!vd) {
+ sdmac->desc = NULL;
+ return;
+ }
+ sdmac->desc = desc = to_sdma_desc(>tx);
+ /*
+* Do not delete the node in desc_issued list in cyclic mode, otherwise
+* the desc alloced will never be freed in vchan_dma_desc_free_list
+*/
+ if (!(sdmac->flags & IMX_DMA_SG_LOOP))
+ list_del(>node);
+
+ sdma->channel_control[channel].base_bd_ptr = desc->bd_phys;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
+ sdma_enable_channel(sdma, sdmac->channel);
+}
+
static void sdma_update_channel_loop(struct sdma_channel *sdmac)
{
struct sdma_buffer_descriptor *bd;
@@ -723,7 +751,7 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* loop mode. Iterate over descriptors, re-setup them and
* call callback function.
*/
- while (1) {
+ while (sdmac->desc) {
struct sdma_desc *desc = sdmac->desc;
bd = >bd[desc->buf_tail];
@@ -754,15 +782,16 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* SDMA transaction status by the time the client tasklet is
* executed.
*/
-
- dmaengine_desc_get_callback_invoke(>txdesc, NULL);
+
[PATCH v4 6/7] dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
There are lot of codes overlap between prep_sg and prep_cyclic function.
Add sdma_transfer_init() function to elimated the code overlap.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 83 ++
1 file changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index f56226f..e0783a2 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1255,6 +1255,40 @@ static void sdma_free_chan_resources(struct dma_chan
*chan)
clk_disable(sdma->clk_ahb);
}
+static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
+ enum dma_transfer_direction direction, u32 bds)
+{
+ struct sdma_desc *desc;
+
+ desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ if (!desc)
+ goto err_out;
+
+ sdmac->status = DMA_IN_PROGRESS;
+ sdmac->direction = direction;
+ sdmac->flags = 0;
+
+ desc->chn_count = 0;
+ desc->chn_real_count = 0;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->sdmac = sdmac;
+ desc->num_bd = bds;
+
+ if (sdma_alloc_bd(desc))
+ goto err_desc_out;
+
+ if (sdma_load_context(sdmac))
+ goto err_desc_out;
+
+ return desc;
+
+err_desc_out:
+ kfree(desc);
+err_out:
+ return NULL;
+}
+
static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
@@ -1267,36 +1301,13 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
struct scatterlist *sg;
struct sdma_desc *desc;
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
- sdmac->status = DMA_IN_PROGRESS;
-
- sdmac->flags = 0;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, sg_len);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = sg_len;
- desc->chn_real_count = 0;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_out;
- }
-
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
- sdmac->direction = direction;
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
-
- desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = >bd[i];
int param;
@@ -1372,38 +1383,18 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
- int ret, i = 0, buf = 0;
+ int i = 0, buf = 0;
struct sdma_desc *desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
-
- sdmac->status = DMA_IN_PROGRESS;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, num_periods);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = num_periods;
- desc->chn_real_count = 0;
desc->period_len = period_len;
sdmac->flags |= IMX_DMA_SG_LOOP;
- sdmac->direction = direction;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_bd_out;
- }
-
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
--
2.7.4
[PATCH v4 6/7] dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
There are lot of codes overlap between prep_sg and prep_cyclic function.
Add sdma_transfer_init() function to elimated the code overlap.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 83 ++
1 file changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index f56226f..e0783a2 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1255,6 +1255,40 @@ static void sdma_free_chan_resources(struct dma_chan
*chan)
clk_disable(sdma->clk_ahb);
}
+static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
+ enum dma_transfer_direction direction, u32 bds)
+{
+ struct sdma_desc *desc;
+
+ desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ if (!desc)
+ goto err_out;
+
+ sdmac->status = DMA_IN_PROGRESS;
+ sdmac->direction = direction;
+ sdmac->flags = 0;
+
+ desc->chn_count = 0;
+ desc->chn_real_count = 0;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->sdmac = sdmac;
+ desc->num_bd = bds;
+
+ if (sdma_alloc_bd(desc))
+ goto err_desc_out;
+
+ if (sdma_load_context(sdmac))
+ goto err_desc_out;
+
+ return desc;
+
+err_desc_out:
+ kfree(desc);
+err_out:
+ return NULL;
+}
+
static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
@@ -1267,36 +1301,13 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
struct scatterlist *sg;
struct sdma_desc *desc;
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
- sdmac->status = DMA_IN_PROGRESS;
-
- sdmac->flags = 0;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, sg_len);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = sg_len;
- desc->chn_real_count = 0;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_out;
- }
-
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
- sdmac->direction = direction;
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
-
- desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = >bd[i];
int param;
@@ -1372,38 +1383,18 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
- int ret, i = 0, buf = 0;
+ int i = 0, buf = 0;
struct sdma_desc *desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
-
- sdmac->status = DMA_IN_PROGRESS;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, num_periods);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = num_periods;
- desc->chn_real_count = 0;
desc->period_len = period_len;
sdmac->flags |= IMX_DMA_SG_LOOP;
- sdmac->direction = direction;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_bd_out;
- }
-
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
--
2.7.4
[PATCH v4 0/7] add virt-dma support for imx-sdma
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Change from v3:
1. add two uart patches which impacted by this patchset.
2. unlock 'vc.lock' before cyclic dma callback and lock again after
it because some driver such as uart will call dmaengine_tx_status
which will acquire 'vc.lock' again and dead lock comes out.
3. remove 'Revert commit' stuff since that patch is not wrong and
combine two patch into one patch as Sascha's comment.
Change from v2:
1. include Sascha's patch to make the main patch easier to review.
Thanks Sacha.
2. remove useless 'desc'/'chan' in struct sdma_channe.
Change from v1:
1. split v1 patch into 5 patches.
2. remove some unnecessary condition check.
3. remove unnecessary 'pending' list.
Robin Gong (6):
tty: serial: imx: correct dma cookie status
dmaengine: imx-sdma: add virt-dma support
dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct
sdma_channel'
dmaengine: imx-sdma: remove the maximum limitation for bd numbers
dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
tty: serial: imx: split all dma setup operations out of 'port.lock'
protector
Sascha Hauer (1):
dmaengine: imx-sdma: factor out a struct sdma_desc from struct
sdma_channel
drivers/dma/Kconfig | 1 +
drivers/dma/imx-sdma.c | 394 +++
drivers/tty/serial/imx.c | 99 ++--
3 files changed, 282 insertions(+), 212 deletions(-)
--
2.7.4
[PATCH v4 2/7] dmaengine: imx-sdma: factor out a struct sdma_desc from struct sdma_channel
From: Sascha Hauer
This is a preparation step to make the adding of virt-dma easier.
We create a struct sdma_desc, move some fields from struct sdma_channel
there and add a pointer from the former to the latter. For now we
allocate the data statically in struct sdma_channel, but with
virt-dma support it will be dynamically allocated.
Signed-off-by: Sascha Hauer
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 137 ++---
1 file changed, 83 insertions(+), 54 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ccd03c3..556d087 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -296,6 +296,30 @@ struct sdma_context_data {
struct sdma_engine;
/**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail ID of the buffer that was processed
+ * @buf_ptail ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count the transfer count setuped
+ * @sdmac sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+ unsigned intnum_bd;
+ dma_addr_t bd_phys;
+ unsigned intbuf_tail;
+ unsigned intbuf_ptail;
+ unsigned intperiod_len;
+ unsigned intchn_real_count;
+ unsigned intchn_count;
+ struct sdma_channel *sdmac;
+ struct sdma_buffer_descriptor *bd;
+};
+
+/**
* struct sdma_channel - housekeeping for a SDMA channel
*
* @sdma pointer to the SDMA engine for this channel
@@ -305,11 +329,10 @@ struct sdma_engine;
* @event_id0 aka dma request line
* @event_id1 for channels that use 2 events
* @word_size peripheral access size
- * @buf_tail ID of the buffer that was processed
- * @buf_ptail ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
*/
struct sdma_channel {
+ struct sdma_desc*desc;
+ struct sdma_desc_desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -317,12 +340,6 @@ struct sdma_channel {
unsigned intevent_id0;
unsigned intevent_id1;
enum dma_slave_buswidth word_size;
- unsigned intbuf_tail;
- unsigned intbuf_ptail;
- unsigned intnum_bd;
- unsigned intperiod_len;
- struct sdma_buffer_descriptor *bd;
- dma_addr_t bd_phys;
unsigned intpc_from_device, pc_to_device;
unsigned intdevice_to_device;
unsigned long flags;
@@ -332,10 +349,8 @@ struct sdma_channel {
u32 shp_addr, per_addr;
struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor desc;
+ struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- unsigned intchn_count;
- unsigned intchn_real_count;
struct tasklet_struct tasklet;
struct imx_dma_data data;
boolenabled;
@@ -398,6 +413,8 @@ struct sdma_engine {
u32 spba_start_addr;
u32 spba_end_addr;
unsigned intirq;
+ dma_addr_t bd0_phys;
+ struct sdma_buffer_descriptor *bd0;
};
static struct sdma_driver_data sdma_imx31 = {
@@ -632,7 +649,7 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
u32 address)
{
- struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+ struct sdma_buffer_descriptor *bd0 = sdma->bd0;
void *buf_virt;
dma_addr_t buf_phys;
int ret;
@@ -707,7 +724,9 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* call callback function.
*/
while (1) {
- bd = >bd[sdmac->buf_tail];
+ struct sdma_desc *desc = sdmac->desc;
+
+ bd = >bd[desc->buf_tail];
if (bd->mode.status & BD_DONE)
break;
@@ -723,11 +742,11 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
[PATCH v4 1/7] tty: serial: imx: correct dma cookie status
Correct to check the right rx dma cookie status in spit of it
works because only one cookie is running in the current sdma.
But it will not once sdma driver support multi cookies
running based on virt-dma.
Signed-off-by: Robin Gong
---
drivers/tty/serial/imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index c2fc6be..b83bc2c 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1051,7 +1051,7 @@ static void imx_uart_dma_rx_callback(void *data)
unsigned int r_bytes;
unsigned int bd_size;
- status = dmaengine_tx_status(chan, (dma_cookie_t)0, );
+ status = dmaengine_tx_status(chan, sport->rx_cookie, );
if (status == DMA_ERROR) {
imx_uart_clear_rx_errors(sport);
--
2.7.4
[PATCH v4 5/7] dmaengine: imx-sdma: remove the maximum limitation for bd numbers
No this limitation now after virtual dma used since bd is allocated
dynamically instead of static.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 27b76eb..f56226f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -292,7 +292,6 @@ struct sdma_context_data {
u32 scratch7;
} __attribute__ ((packed));
-#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
struct sdma_engine;
@@ -1297,13 +1296,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
if (ret)
goto err_bd_out;
- if (sg_len > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, sg_len, NUM_BD);
- ret = -EINVAL;
- goto err_bd_out;
- }
-
desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = >bd[i];
@@ -1413,12 +1405,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
if (ret)
goto err_bd_out;
- if (num_periods > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, num_periods, NUM_BD);
- goto err_bd_out;
- }
-
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
channel, period_len, 0x);
--
2.7.4
[PATCH v4 7/7] tty: serial: imx: split all dma setup operations out of 'port.lock' protector
After sdma driver change to virt-dma, all bds will be allocated
dynamically with 'port.lock' acquired instead of statically allocated
before. That means the lock sequence is 'port.lock' -> 'fs_reclaim_acquire'
.But in case uart rx/tx dma callback coming after other kernel code which
have already acquired 'fs_reclaim_acquire' lock, which means the above lock
sequence reverted as 'fs_reclaim_acquire' -> 'port.lock'(acquired in uart
dma callback), thus, lockdep warning comes as beow. Actually don't need to
spinlock all DMA operations in UART driver with 'port.lock', because dma
driver can wipe off race condition by commone virt-dma lock . Split all dma
operations out of the code areas which protected by 'port.lock'.
[ 46.155406] =
[ 46.161503] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
[ 46.168122] 4.17.0-rc6-8-g7caafa3-dirty #48 Not tainted
[ 46.173696] -
[ 46.179795] mxc_uart_stress/419 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 46.186934] fa7c1440 (fs_reclaim){+.+.}, at:
fs_reclaim_acquire.part.3+0x0/0x48
[ 46.194270]
[ 46.194270] and this task is already holding:
[ 46.200106] 09a17fda (_lock_key){-.-.}, at: uart_write+0x84/0x190
[ 46.206658] which would create a new lock dependency:
[ 46.211710] (_lock_key){-.-.} -> (fs_reclaim){+.+.}
[ 46.217132]
[ 46.217132] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 46.225051] (_lock_key){-.-.}
[ 46.225062]
[ 46.225062] ... which became HARDIRQ-irq-safe at:
[ 46.234740] lock_acquire+0x70/0x90
[ 46.238326] _raw_spin_lock_irqsave+0x40/0x54
[ 46.242777] imx_uart_console_write+0x1bc/0x1e0
[ 46.247402] console_unlock+0x320/0x5f0
[ 46.251329] vprintk_emit+0x22c/0x3fc
[ 46.255082] vprintk_default+0x28/0x30
[ 46.258923] vprintk_func+0x78/0xcc
[ 46.262503] printk+0x34/0x54
[ 46.265566] crng_fast_load+0xf8/0x138
[ 46.269407] add_interrupt_randomness+0x21c/0x24c
[ 46.274204] handle_irq_event_percpu+0x40/0x84
[ 46.278739] handle_irq_event+0x40/0x64
[ 46.282667] handle_fasteoi_irq+0xbc/0x178
[ 46.286854] generic_handle_irq+0x28/0x3c
[ 46.290954] __handle_domain_irq+0x6c/0xe8
[ 46.295148] gic_handle_irq+0x64/0xc4
[ 46.298904] __irq_svc+0x70/0x98
[ 46.302225] _raw_spin_unlock_irq+0x30/0x34
[ 46.306505] finish_task_switch+0xc0/0x27c
[ 46.310693] __schedule+0x2c0/0x79c
[ 46.314272] schedule_idle+0x40/0x84
[ 46.317941] do_idle+0x178/0x2b4
[ 46.321259] cpu_startup_entry+0x20/0x24
[ 46.325278] rest_init+0x214/0x264
[ 46.328775] start_kernel+0x39c/0x424
[ 46.332527] (null)
[ 46.334891]
[ 46.334891] to a HARDIRQ-irq-unsafe lock:
[ 46.340379] (fs_reclaim){+.+.}
[ 46.340391]
[ 46.340391] ... which became HARDIRQ-irq-unsafe at:
[ 46.349885] ...
[ 46.349895] lock_acquire+0x70/0x90
[ 46.355225] fs_reclaim_acquire.part.3+0x38/0x48
[ 46.359933] fs_reclaim_acquire+0x1c/0x20
[ 46.364036] kmem_cache_alloc+0x2c/0x174
[ 46.368051] alloc_worker.constprop.10+0x1c/0x58
[ 46.372759] init_rescuer.part.4+0x18/0xa4
[ 46.376952] workqueue_init+0xc0/0x210
[ 46.380793] kernel_init_freeable+0x58/0x1d8
[ 46.385156] kernel_init+0x10/0x11c
[ 46.388736] ret_from_fork+0x14/0x20
[ 46.392399] (null)
[ 46.394762]
[ 46.394762] other info that might help us debug this:
[ 46.394762]
[ 46.402769] Possible interrupt unsafe locking scenario:
[ 46.402769]
[ 46.409560]CPU0CPU1
[ 46.414092]
[ 46.418622] lock(fs_reclaim);
[ 46.421772]local_irq_disable();
[ 46.427693]lock(_lock_key);
[ 46.433707]lock(fs_reclaim);
[ 46.439372]
[ 46.441993] lock(_lock_key);
[ 46.445661]
[ 46.445661] *** DEADLOCK ***
[ 46.445661]
Signed-off-by: Robin Gong
---
drivers/tty/serial/imx.c | 97 ++--
1 file changed, 53 insertions(+), 44 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index b83bc2c..f2a2966 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -223,6 +223,7 @@ struct imx_port {
dma_cookie_trx_cookie;
unsigned inttx_bytes;
unsigned intdma_tx_nents;
+ struct work_struct tsk_dma_tx;
unsigned intsaved_reg[10];
boolcontext_saved;
};
@@ -491,8 +492,6 @@ static void imx_uart_enable_ms(struct uart_port *port)
mctrl_gpio_enable_ms(sport->gpios);
}
-static void imx_uart_dma_tx(struct imx_port *sport);
-
/* called with port.lock taken and irqs off */
static inline void imx_uart_transmit_buffer(struct imx_port *sport)
{
@@ -524,7 +523,7 @@ static inline void
[PATCH v4 0/7] add virt-dma support for imx-sdma
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Change from v3:
1. add two uart patches which impacted by this patchset.
2. unlock 'vc.lock' before cyclic dma callback and lock again after
it because some driver such as uart will call dmaengine_tx_status
which will acquire 'vc.lock' again and dead lock comes out.
3. remove 'Revert commit' stuff since that patch is not wrong and
combine two patch into one patch as Sascha's comment.
Change from v2:
1. include Sascha's patch to make the main patch easier to review.
Thanks Sacha.
2. remove useless 'desc'/'chan' in struct sdma_channe.
Change from v1:
1. split v1 patch into 5 patches.
2. remove some unnecessary condition check.
3. remove unnecessary 'pending' list.
Robin Gong (6):
tty: serial: imx: correct dma cookie status
dmaengine: imx-sdma: add virt-dma support
dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct
sdma_channel'
dmaengine: imx-sdma: remove the maximum limitation for bd numbers
dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
tty: serial: imx: split all dma setup operations out of 'port.lock'
protector
Sascha Hauer (1):
dmaengine: imx-sdma: factor out a struct sdma_desc from struct
sdma_channel
drivers/dma/Kconfig | 1 +
drivers/dma/imx-sdma.c | 394 +++
drivers/tty/serial/imx.c | 99 ++--
3 files changed, 282 insertions(+), 212 deletions(-)
--
2.7.4
[PATCH v4 2/7] dmaengine: imx-sdma: factor out a struct sdma_desc from struct sdma_channel
From: Sascha Hauer
This is a preparation step to make the adding of virt-dma easier.
We create a struct sdma_desc, move some fields from struct sdma_channel
there and add a pointer from the former to the latter. For now we
allocate the data statically in struct sdma_channel, but with
virt-dma support it will be dynamically allocated.
Signed-off-by: Sascha Hauer
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 137 ++---
1 file changed, 83 insertions(+), 54 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ccd03c3..556d087 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -296,6 +296,30 @@ struct sdma_context_data {
struct sdma_engine;
/**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail ID of the buffer that was processed
+ * @buf_ptail ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count the transfer count setuped
+ * @sdmac sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+ unsigned intnum_bd;
+ dma_addr_t bd_phys;
+ unsigned intbuf_tail;
+ unsigned intbuf_ptail;
+ unsigned intperiod_len;
+ unsigned intchn_real_count;
+ unsigned intchn_count;
+ struct sdma_channel *sdmac;
+ struct sdma_buffer_descriptor *bd;
+};
+
+/**
* struct sdma_channel - housekeeping for a SDMA channel
*
* @sdma pointer to the SDMA engine for this channel
@@ -305,11 +329,10 @@ struct sdma_engine;
* @event_id0 aka dma request line
* @event_id1 for channels that use 2 events
* @word_size peripheral access size
- * @buf_tail ID of the buffer that was processed
- * @buf_ptail ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
*/
struct sdma_channel {
+ struct sdma_desc*desc;
+ struct sdma_desc_desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -317,12 +340,6 @@ struct sdma_channel {
unsigned intevent_id0;
unsigned intevent_id1;
enum dma_slave_buswidth word_size;
- unsigned intbuf_tail;
- unsigned intbuf_ptail;
- unsigned intnum_bd;
- unsigned intperiod_len;
- struct sdma_buffer_descriptor *bd;
- dma_addr_t bd_phys;
unsigned intpc_from_device, pc_to_device;
unsigned intdevice_to_device;
unsigned long flags;
@@ -332,10 +349,8 @@ struct sdma_channel {
u32 shp_addr, per_addr;
struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor desc;
+ struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- unsigned intchn_count;
- unsigned intchn_real_count;
struct tasklet_struct tasklet;
struct imx_dma_data data;
boolenabled;
@@ -398,6 +413,8 @@ struct sdma_engine {
u32 spba_start_addr;
u32 spba_end_addr;
unsigned intirq;
+ dma_addr_t bd0_phys;
+ struct sdma_buffer_descriptor *bd0;
};
static struct sdma_driver_data sdma_imx31 = {
@@ -632,7 +649,7 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
u32 address)
{
- struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+ struct sdma_buffer_descriptor *bd0 = sdma->bd0;
void *buf_virt;
dma_addr_t buf_phys;
int ret;
@@ -707,7 +724,9 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* call callback function.
*/
while (1) {
- bd = >bd[sdmac->buf_tail];
+ struct sdma_desc *desc = sdmac->desc;
+
+ bd = >bd[desc->buf_tail];
if (bd->mode.status & BD_DONE)
break;
@@ -723,11 +742,11 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
[PATCH v4 1/7] tty: serial: imx: correct dma cookie status
Correct to check the right rx dma cookie status in spit of it
works because only one cookie is running in the current sdma.
But it will not once sdma driver support multi cookies
running based on virt-dma.
Signed-off-by: Robin Gong
---
drivers/tty/serial/imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index c2fc6be..b83bc2c 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1051,7 +1051,7 @@ static void imx_uart_dma_rx_callback(void *data)
unsigned int r_bytes;
unsigned int bd_size;
- status = dmaengine_tx_status(chan, (dma_cookie_t)0, );
+ status = dmaengine_tx_status(chan, sport->rx_cookie, );
if (status == DMA_ERROR) {
imx_uart_clear_rx_errors(sport);
--
2.7.4
[PATCH v4 5/7] dmaengine: imx-sdma: remove the maximum limitation for bd numbers
No this limitation now after virtual dma used since bd is allocated
dynamically instead of static.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 27b76eb..f56226f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -292,7 +292,6 @@ struct sdma_context_data {
u32 scratch7;
} __attribute__ ((packed));
-#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
struct sdma_engine;
@@ -1297,13 +1296,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
if (ret)
goto err_bd_out;
- if (sg_len > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, sg_len, NUM_BD);
- ret = -EINVAL;
- goto err_bd_out;
- }
-
desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = >bd[i];
@@ -1413,12 +1405,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
if (ret)
goto err_bd_out;
- if (num_periods > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, num_periods, NUM_BD);
- goto err_bd_out;
- }
-
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
channel, period_len, 0x);
--
2.7.4
[PATCH v4 7/7] tty: serial: imx: split all dma setup operations out of 'port.lock' protector
After sdma driver change to virt-dma, all bds will be allocated
dynamically with 'port.lock' acquired instead of statically allocated
before. That means the lock sequence is 'port.lock' -> 'fs_reclaim_acquire'
.But in case uart rx/tx dma callback coming after other kernel code which
have already acquired 'fs_reclaim_acquire' lock, which means the above lock
sequence reverted as 'fs_reclaim_acquire' -> 'port.lock'(acquired in uart
dma callback), thus, lockdep warning comes as beow. Actually don't need to
spinlock all DMA operations in UART driver with 'port.lock', because dma
driver can wipe off race condition by commone virt-dma lock . Split all dma
operations out of the code areas which protected by 'port.lock'.
[ 46.155406] =
[ 46.161503] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
[ 46.168122] 4.17.0-rc6-8-g7caafa3-dirty #48 Not tainted
[ 46.173696] -
[ 46.179795] mxc_uart_stress/419 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 46.186934] fa7c1440 (fs_reclaim){+.+.}, at:
fs_reclaim_acquire.part.3+0x0/0x48
[ 46.194270]
[ 46.194270] and this task is already holding:
[ 46.200106] 09a17fda (_lock_key){-.-.}, at: uart_write+0x84/0x190
[ 46.206658] which would create a new lock dependency:
[ 46.211710] (_lock_key){-.-.} -> (fs_reclaim){+.+.}
[ 46.217132]
[ 46.217132] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 46.225051] (_lock_key){-.-.}
[ 46.225062]
[ 46.225062] ... which became HARDIRQ-irq-safe at:
[ 46.234740] lock_acquire+0x70/0x90
[ 46.238326] _raw_spin_lock_irqsave+0x40/0x54
[ 46.242777] imx_uart_console_write+0x1bc/0x1e0
[ 46.247402] console_unlock+0x320/0x5f0
[ 46.251329] vprintk_emit+0x22c/0x3fc
[ 46.255082] vprintk_default+0x28/0x30
[ 46.258923] vprintk_func+0x78/0xcc
[ 46.262503] printk+0x34/0x54
[ 46.265566] crng_fast_load+0xf8/0x138
[ 46.269407] add_interrupt_randomness+0x21c/0x24c
[ 46.274204] handle_irq_event_percpu+0x40/0x84
[ 46.278739] handle_irq_event+0x40/0x64
[ 46.282667] handle_fasteoi_irq+0xbc/0x178
[ 46.286854] generic_handle_irq+0x28/0x3c
[ 46.290954] __handle_domain_irq+0x6c/0xe8
[ 46.295148] gic_handle_irq+0x64/0xc4
[ 46.298904] __irq_svc+0x70/0x98
[ 46.302225] _raw_spin_unlock_irq+0x30/0x34
[ 46.306505] finish_task_switch+0xc0/0x27c
[ 46.310693] __schedule+0x2c0/0x79c
[ 46.314272] schedule_idle+0x40/0x84
[ 46.317941] do_idle+0x178/0x2b4
[ 46.321259] cpu_startup_entry+0x20/0x24
[ 46.325278] rest_init+0x214/0x264
[ 46.328775] start_kernel+0x39c/0x424
[ 46.332527] (null)
[ 46.334891]
[ 46.334891] to a HARDIRQ-irq-unsafe lock:
[ 46.340379] (fs_reclaim){+.+.}
[ 46.340391]
[ 46.340391] ... which became HARDIRQ-irq-unsafe at:
[ 46.349885] ...
[ 46.349895] lock_acquire+0x70/0x90
[ 46.355225] fs_reclaim_acquire.part.3+0x38/0x48
[ 46.359933] fs_reclaim_acquire+0x1c/0x20
[ 46.364036] kmem_cache_alloc+0x2c/0x174
[ 46.368051] alloc_worker.constprop.10+0x1c/0x58
[ 46.372759] init_rescuer.part.4+0x18/0xa4
[ 46.376952] workqueue_init+0xc0/0x210
[ 46.380793] kernel_init_freeable+0x58/0x1d8
[ 46.385156] kernel_init+0x10/0x11c
[ 46.388736] ret_from_fork+0x14/0x20
[ 46.392399] (null)
[ 46.394762]
[ 46.394762] other info that might help us debug this:
[ 46.394762]
[ 46.402769] Possible interrupt unsafe locking scenario:
[ 46.402769]
[ 46.409560]CPU0CPU1
[ 46.414092]
[ 46.418622] lock(fs_reclaim);
[ 46.421772]local_irq_disable();
[ 46.427693]lock(_lock_key);
[ 46.433707]lock(fs_reclaim);
[ 46.439372]
[ 46.441993] lock(_lock_key);
[ 46.445661]
[ 46.445661] *** DEADLOCK ***
[ 46.445661]
Signed-off-by: Robin Gong
---
drivers/tty/serial/imx.c | 97 ++--
1 file changed, 53 insertions(+), 44 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index b83bc2c..f2a2966 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -223,6 +223,7 @@ struct imx_port {
dma_cookie_trx_cookie;
unsigned inttx_bytes;
unsigned intdma_tx_nents;
+ struct work_struct tsk_dma_tx;
unsigned intsaved_reg[10];
boolcontext_saved;
};
@@ -491,8 +492,6 @@ static void imx_uart_enable_ms(struct uart_port *port)
mctrl_gpio_enable_ms(sport->gpios);
}
-static void imx_uart_dma_tx(struct imx_port *sport);
-
/* called with port.lock taken and irqs off */
static inline void imx_uart_transmit_buffer(struct imx_port *sport)
{
@@ -524,7 +523,7 @@ static inline void
Re: [PATCH v2 6/7] vmw_balloon: update copyright message
at 10:24 PM, Greg Kroah-Hartman wrote: > On Wed, Jun 13, 2018 at 06:54:11AM -0700, Nadav Amit wrote: >> Removing the paragraph about writing to the Free Software Foundation's >> mailing address from the sample GPL notice according to checkpatch >> request. >> >> In addition, updating the year and adding a license tag. >> >> Reviewed-by: Xavier Deguillard >> Signed-off-by: Nadav Amit >> --- >> drivers/misc/vmw_balloon.c | 7 ++- >> 1 file changed, 2 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c >> index 400a1ccefc8e..b982059ce7b7 100644 >> --- a/drivers/misc/vmw_balloon.c >> +++ b/drivers/misc/vmw_balloon.c >> @@ -1,7 +1,8 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> /* >> * VMware Balloon driver. >> * >> - * Copyright (C) 2000-2014, VMware, Inc. All Rights Reserved. >> + * Copyright (C) 2000-2018, VMware, Inc. All Rights Reserved. >> * >> * This program is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License as published by the >> @@ -13,10 +14,6 @@ >> * NON INFRINGEMENT. See the GNU General Public License for more >> * details. > > You still have a lot of boiler-plate text in here that can be removed. > Please do so. I will remove the maintainers, since it is really unsuitable. But what else do you want me to remove? This is a standard GPL license. If I am required to remove the GPL license, I will have to run checks to ensure it is appropriate. Thanks, Nadav
Re: [PATCH v2 6/7] vmw_balloon: update copyright message
at 10:24 PM, Greg Kroah-Hartman wrote: > On Wed, Jun 13, 2018 at 06:54:11AM -0700, Nadav Amit wrote: >> Removing the paragraph about writing to the Free Software Foundation's >> mailing address from the sample GPL notice according to checkpatch >> request. >> >> In addition, updating the year and adding a license tag. >> >> Reviewed-by: Xavier Deguillard >> Signed-off-by: Nadav Amit >> --- >> drivers/misc/vmw_balloon.c | 7 ++- >> 1 file changed, 2 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c >> index 400a1ccefc8e..b982059ce7b7 100644 >> --- a/drivers/misc/vmw_balloon.c >> +++ b/drivers/misc/vmw_balloon.c >> @@ -1,7 +1,8 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> /* >> * VMware Balloon driver. >> * >> - * Copyright (C) 2000-2014, VMware, Inc. All Rights Reserved. >> + * Copyright (C) 2000-2018, VMware, Inc. All Rights Reserved. >> * >> * This program is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License as published by the >> @@ -13,10 +14,6 @@ >> * NON INFRINGEMENT. See the GNU General Public License for more >> * details. > > You still have a lot of boiler-plate text in here that can be removed. > Please do so. I will remove the maintainers, since it is really unsuitable. But what else do you want me to remove? This is a standard GPL license. If I am required to remove the GPL license, I will have to run checks to ensure it is appropriate. Thanks, Nadav
[PATCH] gpio: uniphier: set legitimate irq trigger type in .to_irq hook
If a GPIO chip is a part of a hierarchy IRQ domain, there is no
way to specify the trigger type when gpio(d)_to_irq() allocates an
interrupt on-the-fly.
Currently, uniphier_gpio_to_irq() sets IRQ_TYPE_NONE, but it causes
an error in the .alloc() hook of the parent domain.
(drivers/irq/irq-uniphier-aidet.c)
Even if we change irq-uniphier-aidet.c to accept the NONE type,
GIC complains about it since commit 83a86fbb5b56 ("irqchip/gic:
Loudly complain about the use of IRQ_TYPE_NONE").
Instead, use IRQ_TYPE_LEVEL_HIGH as a temporary value when an irq
is allocated. irq_set_irq_type() will override it when the irq is
really requested.
Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver")
Reported-by: Katsuhiro Suzuki
Signed-off-by: Masahiro Yamada
Tested-by: Katsuhiro Suzuki
---
drivers/gpio/gpio-uniphier.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
index d3cf950..58faeb1 100644
--- a/drivers/gpio/gpio-uniphier.c
+++ b/drivers/gpio/gpio-uniphier.c
@@ -181,7 +181,11 @@ static int uniphier_gpio_to_irq(struct gpio_chip *chip,
unsigned int offset)
fwspec.fwnode = of_node_to_fwnode(chip->parent->of_node);
fwspec.param_count = 2;
fwspec.param[0] = offset - UNIPHIER_GPIO_IRQ_OFFSET;
- fwspec.param[1] = IRQ_TYPE_NONE;
+ /*
+* IRQ_TYPE_NONE is rejected by the parent irq domain. Set LEVEL_HIGH
+* temporarily. Anyway, ->irq_set_type() will override it later.
+*/
+ fwspec.param[1] = IRQ_TYPE_LEVEL_HIGH;
return irq_create_fwspec_mapping();
}
--
2.7.4
[PATCH] gpio: uniphier: set legitimate irq trigger type in .to_irq hook
If a GPIO chip is a part of a hierarchy IRQ domain, there is no
way to specify the trigger type when gpio(d)_to_irq() allocates an
interrupt on-the-fly.
Currently, uniphier_gpio_to_irq() sets IRQ_TYPE_NONE, but it causes
an error in the .alloc() hook of the parent domain.
(drivers/irq/irq-uniphier-aidet.c)
Even if we change irq-uniphier-aidet.c to accept the NONE type,
GIC complains about it since commit 83a86fbb5b56 ("irqchip/gic:
Loudly complain about the use of IRQ_TYPE_NONE").
Instead, use IRQ_TYPE_LEVEL_HIGH as a temporary value when an irq
is allocated. irq_set_irq_type() will override it when the irq is
really requested.
Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver")
Reported-by: Katsuhiro Suzuki
Signed-off-by: Masahiro Yamada
Tested-by: Katsuhiro Suzuki
---
drivers/gpio/gpio-uniphier.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
index d3cf950..58faeb1 100644
--- a/drivers/gpio/gpio-uniphier.c
+++ b/drivers/gpio/gpio-uniphier.c
@@ -181,7 +181,11 @@ static int uniphier_gpio_to_irq(struct gpio_chip *chip,
unsigned int offset)
fwspec.fwnode = of_node_to_fwnode(chip->parent->of_node);
fwspec.param_count = 2;
fwspec.param[0] = offset - UNIPHIER_GPIO_IRQ_OFFSET;
- fwspec.param[1] = IRQ_TYPE_NONE;
+ /*
+* IRQ_TYPE_NONE is rejected by the parent irq domain. Set LEVEL_HIGH
+* temporarily. Anyway, ->irq_set_type() will override it later.
+*/
+ fwspec.param[1] = IRQ_TYPE_LEVEL_HIGH;
return irq_create_fwspec_mapping();
}
--
2.7.4
Re: [PATCH v2 6/7] vmw_balloon: update copyright message
On Wed, Jun 13, 2018 at 06:54:11AM -0700, Nadav Amit wrote: > Removing the paragraph about writing to the Free Software Foundation's > mailing address from the sample GPL notice according to checkpatch > request. > > In addition, updating the year and adding a license tag. > > Reviewed-by: Xavier Deguillard > Signed-off-by: Nadav Amit > --- > drivers/misc/vmw_balloon.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c > index 400a1ccefc8e..b982059ce7b7 100644 > --- a/drivers/misc/vmw_balloon.c > +++ b/drivers/misc/vmw_balloon.c > @@ -1,7 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * VMware Balloon driver. > * > - * Copyright (C) 2000-2014, VMware, Inc. All Rights Reserved. > + * Copyright (C) 2000-2018, VMware, Inc. All Rights Reserved. > * > * This program is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License as published by the > @@ -13,10 +14,6 @@ > * NON INFRINGEMENT. See the GNU General Public License for more > * details. You still have a lot of boiler-plate text in here that can be removed. Please do so. thanks, greg k-h
Re: [PATCH v2 6/7] vmw_balloon: update copyright message
On Wed, Jun 13, 2018 at 06:54:11AM -0700, Nadav Amit wrote: > Removing the paragraph about writing to the Free Software Foundation's > mailing address from the sample GPL notice according to checkpatch > request. > > In addition, updating the year and adding a license tag. > > Reviewed-by: Xavier Deguillard > Signed-off-by: Nadav Amit > --- > drivers/misc/vmw_balloon.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c > index 400a1ccefc8e..b982059ce7b7 100644 > --- a/drivers/misc/vmw_balloon.c > +++ b/drivers/misc/vmw_balloon.c > @@ -1,7 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * VMware Balloon driver. > * > - * Copyright (C) 2000-2014, VMware, Inc. All Rights Reserved. > + * Copyright (C) 2000-2018, VMware, Inc. All Rights Reserved. > * > * This program is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License as published by the > @@ -13,10 +14,6 @@ > * NON INFRINGEMENT. See the GNU General Public License for more > * details. You still have a lot of boiler-plate text in here that can be removed. Please do so. thanks, greg k-h
Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
> When balloon batching is not supported by the hypervisor, the guest
> frame number (GFN) must fit in 32-bit. However, due to a bug, this check
> was mistakenly ignored. In practice, when total RAM is greater than
> 16TB, the balloon does not work currently, making this bug unlikely to
> happen.
>
> Fixes: ef0f8f112984 ("VMware balloon: partially inline
> vmballoon_reserve_page.")
>
> Cc: sta...@vger.kernel.org
Again, no blank line between these things.
Also, please break this up into two different patch series. One for
4.18-final and one for 4.19-rc1. You should always split up bugfixes
from new features/cleanups as that is what I have to do when sending
them to Linus.
thanks,
greg k-h
Re: [PATCH v2 1/7] vmw_balloon: fix inflation of 64-bit GFNs
On Wed, Jun 13, 2018 at 06:54:06AM -0700, Nadav Amit wrote:
> When balloon batching is not supported by the hypervisor, the guest
> frame number (GFN) must fit in 32-bit. However, due to a bug, this check
> was mistakenly ignored. In practice, when total RAM is greater than
> 16TB, the balloon does not work currently, making this bug unlikely to
> happen.
>
> Fixes: ef0f8f112984 ("VMware balloon: partially inline
> vmballoon_reserve_page.")
>
> Cc: sta...@vger.kernel.org
Again, no blank line between these things.
Also, please break this up into two different patch series. One for
4.18-final and one for 4.19-rc1. You should always split up bugfixes
from new features/cleanups as that is what I have to do when sending
them to Linus.
thanks,
greg k-h
[PATCH 1/2] PM / Domains: Rename opp_node to np
The DT node passed here isn't necessarily an OPP node, as this routine
can also be used for cases where the "required-opps" property is present
directly in the device's node. Rename it.
This also removes a stale comment.
Signed-off-by: Viresh Kumar
---
drivers/base/power/domain.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 4925af5c4cf0..c298de8a8308 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2487,10 +2487,9 @@ EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
* power domain corresponding to a DT node's "required-opps" property.
*
* @dev: Device for which the performance-state needs to be found.
- * @opp_node: DT node where the "required-opps" property is present. This can
be
+ * @np: DT node where the "required-opps" property is present. This can be
* the device node itself (if it doesn't have an OPP table) or a node
* within the OPP table of a device (if device has an OPP table).
- * @state: Pointer to return performance state.
*
* Returns performance state corresponding to the "required-opps" property of
* a DT node. This calls platform specific genpd->opp_to_performance_state()
@@ -2499,7 +2498,7 @@ EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
* Returns performance state on success and 0 on failure.
*/
unsigned int of_genpd_opp_to_performance_state(struct device *dev,
- struct device_node *opp_node)
+ struct device_node *np)
{
struct generic_pm_domain *genpd;
struct dev_pm_opp *opp;
@@ -2514,7 +2513,7 @@ unsigned int of_genpd_opp_to_performance_state(struct
device *dev,
genpd_lock(genpd);
- opp = of_dev_pm_opp_find_required_opp(>dev, opp_node);
+ opp = of_dev_pm_opp_find_required_opp(>dev, np);
if (IS_ERR(opp)) {
dev_err(dev, "Failed to find required OPP: %ld\n",
PTR_ERR(opp));
--
2.18.0.rc1.242.g61856ae69a2c
[PATCH 1/2] PM / Domains: Rename opp_node to np
The DT node passed here isn't necessarily an OPP node, as this routine
can also be used for cases where the "required-opps" property is present
directly in the device's node. Rename it.
This also removes a stale comment.
Signed-off-by: Viresh Kumar
---
drivers/base/power/domain.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 4925af5c4cf0..c298de8a8308 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2487,10 +2487,9 @@ EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
* power domain corresponding to a DT node's "required-opps" property.
*
* @dev: Device for which the performance-state needs to be found.
- * @opp_node: DT node where the "required-opps" property is present. This can
be
+ * @np: DT node where the "required-opps" property is present. This can be
* the device node itself (if it doesn't have an OPP table) or a node
* within the OPP table of a device (if device has an OPP table).
- * @state: Pointer to return performance state.
*
* Returns performance state corresponding to the "required-opps" property of
* a DT node. This calls platform specific genpd->opp_to_performance_state()
@@ -2499,7 +2498,7 @@ EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
* Returns performance state on success and 0 on failure.
*/
unsigned int of_genpd_opp_to_performance_state(struct device *dev,
- struct device_node *opp_node)
+ struct device_node *np)
{
struct generic_pm_domain *genpd;
struct dev_pm_opp *opp;
@@ -2514,7 +2513,7 @@ unsigned int of_genpd_opp_to_performance_state(struct
device *dev,
genpd_lock(genpd);
- opp = of_dev_pm_opp_find_required_opp(>dev, opp_node);
+ opp = of_dev_pm_opp_find_required_opp(>dev, np);
if (IS_ERR(opp)) {
dev_err(dev, "Failed to find required OPP: %ld\n",
PTR_ERR(opp));
--
2.18.0.rc1.242.g61856ae69a2c
[PATCH 2/2] PM / Domains: Fix return value of of_genpd_opp_to_performance_state()
of_genpd_opp_to_performance_state() should return 0 for errors, but the
dummy routine isn't doing that. Fix it.
Signed-off-by: Viresh Kumar
---
include/linux/pm_domain.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 9206a4fef9ac..139f79c8477a 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -276,7 +276,7 @@ static inline unsigned int
of_genpd_opp_to_performance_state(struct device *dev,
struct device_node *opp_node)
{
- return -ENODEV;
+ return 0;
}
static inline int genpd_dev_pm_attach(struct device *dev)
--
2.18.0.rc1.242.g61856ae69a2c
[PATCH 2/2] PM / Domains: Fix return value of of_genpd_opp_to_performance_state()
of_genpd_opp_to_performance_state() should return 0 for errors, but the
dummy routine isn't doing that. Fix it.
Signed-off-by: Viresh Kumar
---
include/linux/pm_domain.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 9206a4fef9ac..139f79c8477a 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -276,7 +276,7 @@ static inline unsigned int
of_genpd_opp_to_performance_state(struct device *dev,
struct device_node *opp_node)
{
- return -ENODEV;
+ return 0;
}
static inline int genpd_dev_pm_attach(struct device *dev)
--
2.18.0.rc1.242.g61856ae69a2c
Re: [PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
On Wed, Jun 13, 2018 at 11:07:00AM +0200, Michal Hocko wrote:
> On Wed 13-06-18 05:41:08, Naoya Horiguchi wrote:
> [...]
> > From: Naoya Horiguchi
> > Date: Wed, 13 Jun 2018 12:43:27 +0900
> > Subject: [PATCH] mm: zero remaining unavailable struct pages
> >
> > There is a kernel panic that is triggered when reading /proc/kpageflags
> > on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
> >
> > BUG: unable to handle kernel paging request at fffe
> > PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
> > Oops: [#1] SMP PTI
> > CPU: 2 PID: 1728 Comm: page-types Not tainted
> > 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28
> > 04/01/2014
> > RIP: 0010:stable_page_flags+0x27/0x3c0
> > Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89
> > fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6
> > c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
> > RSP: 0018:bbd44111fde0 EFLAGS: 00010202
> > RAX: fffe RBX: 7fffeff9 RCX:
> > RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
> > RBP: R08: 0001 R09: 0001
> > R10: bbd44111fed8 R11: R12: ed1182fff5c0
> > R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
> > FS: 7efc4335a500() GS:93a5bfc0()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: fffe CR3: b2a58000 CR4: 001406e0
> > Call Trace:
> >kpageflags_read+0xc7/0x120
> >proc_reg_read+0x3c/0x60
> >__vfs_read+0x36/0x170
> >vfs_read+0x89/0x130
> >ksys_pread64+0x71/0x90
> >do_syscall_64+0x5b/0x160
> >entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x7efc42e75e23
> > Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00
> > 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0
> > ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
> >
> > According to kernel bisection, this problem became visible due to commit
> > f7f99100d8d9 which changes how struct pages are initialized.
> >
> > Memblock layout affects the pfn ranges covered by node/zone. Consider
> > that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
> > the default (no memmap= given) memblock layout is like below:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001fff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x4
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x0001-0x00013fff],
> > 0x4000 bytes on node 0 flags: 0x0
> >memory[0x3] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > If you give memmap=1G!4G (so it just covers memory[0x2]),
> > the range [0x1-0x13fff] is gone:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001bff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x3
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > This causes shrinking node 0's pfn range because it is calculated by
> > the address range of memblock.memory. So some of struct pages in the
> > gap range are left uninitialized.
> >
> > We have a function zero_resv_unavail() which does zeroing the struct
> > pages outside memblock.memory, but currently it covers only the reserved
> > unavailable range (i.e. memblock.memory && !memblock.reserved).
> > This patch extends it to cover all unavailable range, which fixes
> > the reported issue.
>
> Thanks for pin pointing this down Naoya! I am wondering why we cannot
> simply mark the excluded ranges to be reserved instead.
I tried your idea with the change below, and it also fixes the kernel panic.
---
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index d1f25c831447..2cef120535d4 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1248,6 +1248,7 @@ void __init e820__memblock_setup(void)
{
int i;
u64 end;
+ u64 addr = 0;
/*
* The bootstrap memblock region count maximum is 128 entries
@@ -1264,13 +1265,16 @@ void __init e820__memblock_setup(void)
struct e820_entry *entry = _table->entries[i];
end = entry->addr + entry->size;
+
Re: [PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
On Wed, Jun 13, 2018 at 11:07:00AM +0200, Michal Hocko wrote:
> On Wed 13-06-18 05:41:08, Naoya Horiguchi wrote:
> [...]
> > From: Naoya Horiguchi
> > Date: Wed, 13 Jun 2018 12:43:27 +0900
> > Subject: [PATCH] mm: zero remaining unavailable struct pages
> >
> > There is a kernel panic that is triggered when reading /proc/kpageflags
> > on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
> >
> > BUG: unable to handle kernel paging request at fffe
> > PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
> > Oops: [#1] SMP PTI
> > CPU: 2 PID: 1728 Comm: page-types Not tainted
> > 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28
> > 04/01/2014
> > RIP: 0010:stable_page_flags+0x27/0x3c0
> > Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89
> > fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6
> > c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
> > RSP: 0018:bbd44111fde0 EFLAGS: 00010202
> > RAX: fffe RBX: 7fffeff9 RCX:
> > RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
> > RBP: R08: 0001 R09: 0001
> > R10: bbd44111fed8 R11: R12: ed1182fff5c0
> > R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
> > FS: 7efc4335a500() GS:93a5bfc0()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: fffe CR3: b2a58000 CR4: 001406e0
> > Call Trace:
> >kpageflags_read+0xc7/0x120
> >proc_reg_read+0x3c/0x60
> >__vfs_read+0x36/0x170
> >vfs_read+0x89/0x130
> >ksys_pread64+0x71/0x90
> >do_syscall_64+0x5b/0x160
> >entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x7efc42e75e23
> > Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00
> > 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0
> > ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
> >
> > According to kernel bisection, this problem became visible due to commit
> > f7f99100d8d9 which changes how struct pages are initialized.
> >
> > Memblock layout affects the pfn ranges covered by node/zone. Consider
> > that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
> > the default (no memmap= given) memblock layout is like below:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001fff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x4
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x0001-0x00013fff],
> > 0x4000 bytes on node 0 flags: 0x0
> >memory[0x3] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > If you give memmap=1G!4G (so it just covers memory[0x2]),
> > the range [0x1-0x13fff] is gone:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001bff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x3
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > This causes shrinking node 0's pfn range because it is calculated by
> > the address range of memblock.memory. So some of struct pages in the
> > gap range are left uninitialized.
> >
> > We have a function zero_resv_unavail() which does zeroing the struct
> > pages outside memblock.memory, but currently it covers only the reserved
> > unavailable range (i.e. memblock.memory && !memblock.reserved).
> > This patch extends it to cover all unavailable range, which fixes
> > the reported issue.
>
> Thanks for pin pointing this down Naoya! I am wondering why we cannot
> simply mark the excluded ranges to be reserved instead.
I tried your idea with the change below, and it also fixes the kernel panic.
---
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index d1f25c831447..2cef120535d4 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1248,6 +1248,7 @@ void __init e820__memblock_setup(void)
{
int i;
u64 end;
+ u64 addr = 0;
/*
* The bootstrap memblock region count maximum is 128 entries
@@ -1264,13 +1265,16 @@ void __init e820__memblock_setup(void)
struct e820_entry *entry = _table->entries[i];
end = entry->addr + entry->size;
+
[PATCH v2 3/3] mtd: rawnand: denali: optimize timing parameters for data interface
This commit improves the ->setup_data_interface() hook.
The denali_setup_data_interface() needs the frequency of clk_x
and the ratio of clk_x / clk.
The latter is currently hardcoded in the driver, like this:
#define DENALI_CLK_X_MULT 6
The IP datasheet requires that clk_x / clk be 4, 5, or 6. I just
chose 6 because it is the most defensive value, but it is not optimal.
By getting the clock rate of both "clk" and "clk_x", the driver can
compute the timing values more precisely.
To not break the existing platforms, the fallback value, 50 MHz is
provided. It is true for all upstreamed platforms.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Split patches into sensible chunks
drivers/mtd/nand/raw/denali.c | 49 +++
drivers/mtd/nand/raw/denali.h | 1 +
drivers/mtd/nand/raw/denali_dt.c | 2 ++
drivers/mtd/nand/raw/denali_pci.c | 1 +
4 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 2a302a1..2de46d4 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -51,14 +51,6 @@ MODULE_LICENSE("GPL");
#define DENALI_INVALID_BANK-1
#define DENALI_NR_BANKS4
-/*
- * The bus interface clock, clk_x, is phase aligned with the core clock. The
- * clk_x is an integral multiple N of the core clk. The value N is configured
- * at IP delivery time, and its available value is 4, 5, or 6. We need to
align
- * to the largest value to make it work with any possible configuration.
- */
-#define DENALI_CLK_X_MULT 6
-
static inline struct denali_nand_info *mtd_to_denali(struct mtd_info *mtd)
{
return container_of(mtd_to_nand(mtd), struct denali_nand_info, nand);
@@ -954,7 +946,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
{
struct denali_nand_info *denali = mtd_to_denali(mtd);
const struct nand_sdr_timings *timings;
- unsigned long t_clk;
+ unsigned long t_x, mult_x;
int acc_clks, re_2_we, re_2_re, we_2_re, addr_2_data;
int rdwr_en_lo, rdwr_en_hi, rdwr_en_lo_hi, cs_setup;
int addr_2_data_mask;
@@ -965,15 +957,24 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
return PTR_ERR(timings);
/* clk_x period in picoseconds */
- t_clk = DIV_ROUND_DOWN_ULL(1ULL, denali->clk_x_rate);
- if (!t_clk)
+ t_x = DIV_ROUND_DOWN_ULL(1ULL, denali->clk_x_rate);
+ if (!t_x)
+ return -EINVAL;
+
+ /*
+* The bus interface clock, clk_x, is phase aligned with the core clock.
+* The clk_x is an integral multiple N of the core clk. The value N is
+* configured at IP delivery time, and its available value is 4, 5, 6.
+*/
+ mult_x = DIV_ROUND_CLOSEST_ULL(denali->clk_x_rate, denali->clk_rate);
+ if (mult_x < 4 || mult_x > 6)
return -EINVAL;
if (chipnr == NAND_DATA_IFACE_CHECK_ONLY)
return 0;
/* tREA -> ACC_CLKS */
- acc_clks = DIV_ROUND_UP(timings->tREA_max, t_clk);
+ acc_clks = DIV_ROUND_UP(timings->tREA_max, t_x);
acc_clks = min_t(int, acc_clks, ACC_CLKS__VALUE);
tmp = ioread32(denali->reg + ACC_CLKS);
@@ -982,7 +983,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
iowrite32(tmp, denali->reg + ACC_CLKS);
/* tRWH -> RE_2_WE */
- re_2_we = DIV_ROUND_UP(timings->tRHW_min, t_clk);
+ re_2_we = DIV_ROUND_UP(timings->tRHW_min, t_x);
re_2_we = min_t(int, re_2_we, RE_2_WE__VALUE);
tmp = ioread32(denali->reg + RE_2_WE);
@@ -991,7 +992,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
iowrite32(tmp, denali->reg + RE_2_WE);
/* tRHZ -> RE_2_RE */
- re_2_re = DIV_ROUND_UP(timings->tRHZ_max, t_clk);
+ re_2_re = DIV_ROUND_UP(timings->tRHZ_max, t_x);
re_2_re = min_t(int, re_2_re, RE_2_RE__VALUE);
tmp = ioread32(denali->reg + RE_2_RE);
@@ -1005,8 +1006,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
* With WE_2_RE properly set, the Denali controller automatically takes
* care of the delay; the driver need not set NAND_WAIT_TCCS.
*/
- we_2_re = DIV_ROUND_UP(max(timings->tCCS_min, timings->tWHR_min),
- t_clk);
+ we_2_re = DIV_ROUND_UP(max(timings->tCCS_min, timings->tWHR_min), t_x);
we_2_re = min_t(int, we_2_re, TWHR2_AND_WE_2_RE__WE_2_RE);
tmp = ioread32(denali->reg + TWHR2_AND_WE_2_RE);
@@ -1021,7 +1021,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
if (denali->revision < 0x0501)
addr_2_data_mask >>= 1;
- addr_2_data = DIV_ROUND_UP(timings->tADL_min, t_clk);
+ addr_2_data =
[PATCH v2 0/3] mtd: rawnand: denali: add new clocks and improve setup_data_interface
The ->setup_data_interface() hook needs to know the clock frequency. In fact, this IP needs three clocks, bus "which clock?" is really confusing. (It is not described in the DT-binding at all.) This series adds more clocks. In the new binding, three clocks are required: core clock, bus interface clock, ECC engine clock. This series also takes care of the backward compatibility by providing hardcoded values in case the new clocks are missing. So, existing DT should work. Changes in v2: - Split patches into sensible chunks Masahiro Yamada (3): mtd: rawnand: denali_dt: use dev as a shorthand of >dev mtd: rawnand: denali_dt: add more clocks based on IP datasheet mtd: rawnand: denali: optimize timing parameters for data interface .../devicetree/bindings/mtd/denali-nand.txt| 5 ++ drivers/mtd/nand/raw/denali.c | 49 drivers/mtd/nand/raw/denali.h | 1 + drivers/mtd/nand/raw/denali_dt.c | 66 ++ drivers/mtd/nand/raw/denali_pci.c | 1 + 5 files changed, 86 insertions(+), 36 deletions(-) -- 2.7.4
[PATCH v2 3/3] mtd: rawnand: denali: optimize timing parameters for data interface
This commit improves the ->setup_data_interface() hook.
The denali_setup_data_interface() needs the frequency of clk_x
and the ratio of clk_x / clk.
The latter is currently hardcoded in the driver, like this:
#define DENALI_CLK_X_MULT 6
The IP datasheet requires that clk_x / clk be 4, 5, or 6. I just
chose 6 because it is the most defensive value, but it is not optimal.
By getting the clock rate of both "clk" and "clk_x", the driver can
compute the timing values more precisely.
To not break the existing platforms, the fallback value, 50 MHz is
provided. It is true for all upstreamed platforms.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Split patches into sensible chunks
drivers/mtd/nand/raw/denali.c | 49 +++
drivers/mtd/nand/raw/denali.h | 1 +
drivers/mtd/nand/raw/denali_dt.c | 2 ++
drivers/mtd/nand/raw/denali_pci.c | 1 +
4 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 2a302a1..2de46d4 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -51,14 +51,6 @@ MODULE_LICENSE("GPL");
#define DENALI_INVALID_BANK-1
#define DENALI_NR_BANKS4
-/*
- * The bus interface clock, clk_x, is phase aligned with the core clock. The
- * clk_x is an integral multiple N of the core clk. The value N is configured
- * at IP delivery time, and its available value is 4, 5, or 6. We need to
align
- * to the largest value to make it work with any possible configuration.
- */
-#define DENALI_CLK_X_MULT 6
-
static inline struct denali_nand_info *mtd_to_denali(struct mtd_info *mtd)
{
return container_of(mtd_to_nand(mtd), struct denali_nand_info, nand);
@@ -954,7 +946,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
{
struct denali_nand_info *denali = mtd_to_denali(mtd);
const struct nand_sdr_timings *timings;
- unsigned long t_clk;
+ unsigned long t_x, mult_x;
int acc_clks, re_2_we, re_2_re, we_2_re, addr_2_data;
int rdwr_en_lo, rdwr_en_hi, rdwr_en_lo_hi, cs_setup;
int addr_2_data_mask;
@@ -965,15 +957,24 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
return PTR_ERR(timings);
/* clk_x period in picoseconds */
- t_clk = DIV_ROUND_DOWN_ULL(1ULL, denali->clk_x_rate);
- if (!t_clk)
+ t_x = DIV_ROUND_DOWN_ULL(1ULL, denali->clk_x_rate);
+ if (!t_x)
+ return -EINVAL;
+
+ /*
+* The bus interface clock, clk_x, is phase aligned with the core clock.
+* The clk_x is an integral multiple N of the core clk. The value N is
+* configured at IP delivery time, and its available value is 4, 5, 6.
+*/
+ mult_x = DIV_ROUND_CLOSEST_ULL(denali->clk_x_rate, denali->clk_rate);
+ if (mult_x < 4 || mult_x > 6)
return -EINVAL;
if (chipnr == NAND_DATA_IFACE_CHECK_ONLY)
return 0;
/* tREA -> ACC_CLKS */
- acc_clks = DIV_ROUND_UP(timings->tREA_max, t_clk);
+ acc_clks = DIV_ROUND_UP(timings->tREA_max, t_x);
acc_clks = min_t(int, acc_clks, ACC_CLKS__VALUE);
tmp = ioread32(denali->reg + ACC_CLKS);
@@ -982,7 +983,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
iowrite32(tmp, denali->reg + ACC_CLKS);
/* tRWH -> RE_2_WE */
- re_2_we = DIV_ROUND_UP(timings->tRHW_min, t_clk);
+ re_2_we = DIV_ROUND_UP(timings->tRHW_min, t_x);
re_2_we = min_t(int, re_2_we, RE_2_WE__VALUE);
tmp = ioread32(denali->reg + RE_2_WE);
@@ -991,7 +992,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
iowrite32(tmp, denali->reg + RE_2_WE);
/* tRHZ -> RE_2_RE */
- re_2_re = DIV_ROUND_UP(timings->tRHZ_max, t_clk);
+ re_2_re = DIV_ROUND_UP(timings->tRHZ_max, t_x);
re_2_re = min_t(int, re_2_re, RE_2_RE__VALUE);
tmp = ioread32(denali->reg + RE_2_RE);
@@ -1005,8 +1006,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
* With WE_2_RE properly set, the Denali controller automatically takes
* care of the delay; the driver need not set NAND_WAIT_TCCS.
*/
- we_2_re = DIV_ROUND_UP(max(timings->tCCS_min, timings->tWHR_min),
- t_clk);
+ we_2_re = DIV_ROUND_UP(max(timings->tCCS_min, timings->tWHR_min), t_x);
we_2_re = min_t(int, we_2_re, TWHR2_AND_WE_2_RE__WE_2_RE);
tmp = ioread32(denali->reg + TWHR2_AND_WE_2_RE);
@@ -1021,7 +1021,7 @@ static int denali_setup_data_interface(struct mtd_info
*mtd, int chipnr,
if (denali->revision < 0x0501)
addr_2_data_mask >>= 1;
- addr_2_data = DIV_ROUND_UP(timings->tADL_min, t_clk);
+ addr_2_data =
[PATCH v2 0/3] mtd: rawnand: denali: add new clocks and improve setup_data_interface
The ->setup_data_interface() hook needs to know the clock frequency. In fact, this IP needs three clocks, bus "which clock?" is really confusing. (It is not described in the DT-binding at all.) This series adds more clocks. In the new binding, three clocks are required: core clock, bus interface clock, ECC engine clock. This series also takes care of the backward compatibility by providing hardcoded values in case the new clocks are missing. So, existing DT should work. Changes in v2: - Split patches into sensible chunks Masahiro Yamada (3): mtd: rawnand: denali_dt: use dev as a shorthand of >dev mtd: rawnand: denali_dt: add more clocks based on IP datasheet mtd: rawnand: denali: optimize timing parameters for data interface .../devicetree/bindings/mtd/denali-nand.txt| 5 ++ drivers/mtd/nand/raw/denali.c | 49 drivers/mtd/nand/raw/denali.h | 1 + drivers/mtd/nand/raw/denali_dt.c | 66 ++ drivers/mtd/nand/raw/denali_pci.c | 1 + 5 files changed, 86 insertions(+), 36 deletions(-) -- 2.7.4
[PATCH v2 1/3] mtd: rawnand: denali_dt: use dev as a shorthand of >dev
Add 'dev' as a shorthand before adding more code that takes a
pointer to struce device.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mtd/nand/raw/denali_dt.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index cfd33e6..d923cfa 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -79,44 +79,45 @@ MODULE_DEVICE_TABLE(of, denali_nand_dt_ids);
static int denali_dt_probe(struct platform_device *pdev)
{
+ struct device *dev = >dev;
struct resource *res;
struct denali_dt *dt;
const struct denali_dt_data *data;
struct denali_nand_info *denali;
int ret;
- dt = devm_kzalloc(>dev, sizeof(*dt), GFP_KERNEL);
+ dt = devm_kzalloc(dev, sizeof(*dt), GFP_KERNEL);
if (!dt)
return -ENOMEM;
denali = >denali;
- data = of_device_get_match_data(>dev);
+ data = of_device_get_match_data(dev);
if (data) {
denali->revision = data->revision;
denali->caps = data->caps;
denali->ecc_caps = data->ecc_caps;
}
- denali->dev = >dev;
+ denali->dev = dev;
denali->irq = platform_get_irq(pdev, 0);
if (denali->irq < 0) {
- dev_err(>dev, "no irq defined\n");
+ dev_err(dev, "no irq defined\n");
return denali->irq;
}
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "denali_reg");
- denali->reg = devm_ioremap_resource(>dev, res);
+ denali->reg = devm_ioremap_resource(dev, res);
if (IS_ERR(denali->reg))
return PTR_ERR(denali->reg);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_data");
- denali->host = devm_ioremap_resource(>dev, res);
+ denali->host = devm_ioremap_resource(dev, res);
if (IS_ERR(denali->host))
return PTR_ERR(denali->host);
- dt->clk = devm_clk_get(>dev, NULL);
+ dt->clk = devm_clk_get(dev, NULL);
if (IS_ERR(dt->clk)) {
- dev_err(>dev, "no clk available\n");
+ dev_err(dev, "no clk available\n");
return PTR_ERR(dt->clk);
}
ret = clk_prepare_enable(dt->clk);
--
2.7.4
[PATCH v2 1/3] mtd: rawnand: denali_dt: use dev as a shorthand of >dev
Add 'dev' as a shorthand before adding more code that takes a
pointer to struce device.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mtd/nand/raw/denali_dt.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index cfd33e6..d923cfa 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -79,44 +79,45 @@ MODULE_DEVICE_TABLE(of, denali_nand_dt_ids);
static int denali_dt_probe(struct platform_device *pdev)
{
+ struct device *dev = >dev;
struct resource *res;
struct denali_dt *dt;
const struct denali_dt_data *data;
struct denali_nand_info *denali;
int ret;
- dt = devm_kzalloc(>dev, sizeof(*dt), GFP_KERNEL);
+ dt = devm_kzalloc(dev, sizeof(*dt), GFP_KERNEL);
if (!dt)
return -ENOMEM;
denali = >denali;
- data = of_device_get_match_data(>dev);
+ data = of_device_get_match_data(dev);
if (data) {
denali->revision = data->revision;
denali->caps = data->caps;
denali->ecc_caps = data->ecc_caps;
}
- denali->dev = >dev;
+ denali->dev = dev;
denali->irq = platform_get_irq(pdev, 0);
if (denali->irq < 0) {
- dev_err(>dev, "no irq defined\n");
+ dev_err(dev, "no irq defined\n");
return denali->irq;
}
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "denali_reg");
- denali->reg = devm_ioremap_resource(>dev, res);
+ denali->reg = devm_ioremap_resource(dev, res);
if (IS_ERR(denali->reg))
return PTR_ERR(denali->reg);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_data");
- denali->host = devm_ioremap_resource(>dev, res);
+ denali->host = devm_ioremap_resource(dev, res);
if (IS_ERR(denali->host))
return PTR_ERR(denali->host);
- dt->clk = devm_clk_get(>dev, NULL);
+ dt->clk = devm_clk_get(dev, NULL);
if (IS_ERR(dt->clk)) {
- dev_err(>dev, "no clk available\n");
+ dev_err(dev, "no clk available\n");
return PTR_ERR(dt->clk);
}
ret = clk_prepare_enable(dt->clk);
--
2.7.4
[PATCH v2 2/3] mtd: rawnand: denali_dt: add more clocks based on IP datasheet
According to the Denali User's Guide, this IP needs three clocks:
- clk: controller core clock
- clk_x: bus interface clock
- ecc_clk: clock at which ECC circuitry is run
Currently, denali_dt.c requires a single anonymous clock and its
frequency. However, the driver needs to get the frequency of "clk_x"
not "clk". This is confusing because people tend to assume the
anonymous clock means the core clock.
Instead of the cheesy implementation, the clocks in the real hardware
should be represented in the driver and the DT-binding.
However, adding new clocks would break the existing platforms. For the
backward compatibility, the driver still accepts a single clock just as
before. If clk_x is missing, clk_x_rate is set to a hardcoded value.
It is fine because both Altera (Intel) SOCFPGA and Socionext UniPhier
use 200 MHz for the bus interface clock.
Signed-off-by: Masahiro Yamada
---
Changes in v2: split into sensible chunks
.../devicetree/bindings/mtd/denali-nand.txt| 5 +++
drivers/mtd/nand/raw/denali_dt.c | 49 --
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt
b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index 0ee8edb..f33da87 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -8,6 +8,9 @@ Required properties:
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
- interrupts : The interrupt number.
+ - clocks: should contain phandle of the controller core clock, the bus
+interface clock, and the ECC circuit clock.
+ - clock-names: should contain "nand", "nand_x", "ecc"
Optional properties:
- nand-ecc-step-size: see nand.txt for details. If present, the value must
be
@@ -31,5 +34,7 @@ nand: nand@ff90 {
compatible = "altr,socfpga-denali-nand";
reg = <0xff90 0x20>, <0xffb8 0x1000>;
reg-names = "nand_data", "denali_reg";
+ clocks = <_clk>, <_x_clk>, <_ecc_clk>;
+ clock-names = "nand", "nand_x", "ecc";
interrupts = <0 144 4>;
};
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index d923cfa..afaae37 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -27,7 +27,9 @@
struct denali_dt {
struct denali_nand_info denali;
- struct clk *clk;
+ struct clk *clk;/* core clock */
+ struct clk *clk_x; /* bus interface clock */
+ struct clk *clk_ecc;/* ECC circuit clock */
};
struct denali_dt_data {
@@ -115,24 +117,61 @@ static int denali_dt_probe(struct platform_device *pdev)
if (IS_ERR(denali->host))
return PTR_ERR(denali->host);
- dt->clk = devm_clk_get(dev, NULL);
+ /*
+* A single anonymous clock is supported for the backward compatibility.
+* New platforms should support all the named clocks.
+*/
+ dt->clk = devm_clk_get(dev, "nand");
+ if (IS_ERR(dt->clk))
+ dt->clk = devm_clk_get(dev, NULL);
if (IS_ERR(dt->clk)) {
dev_err(dev, "no clk available\n");
return PTR_ERR(dt->clk);
}
+
+ dt->clk_x = devm_clk_get(dev, "nand_x");
+ if (IS_ERR(dt->clk_x))
+ dt->clk_x = NULL;
+
+ dt->clk_ecc = devm_clk_get(dev, "ecc");
+ if (IS_ERR(dt->clk_ecc))
+ dt->clk_ecc = NULL;
+
ret = clk_prepare_enable(dt->clk);
if (ret)
return ret;
- denali->clk_x_rate = clk_get_rate(dt->clk);
+ ret = clk_prepare_enable(dt->clk_x);
+ if (ret)
+ goto out_disable_clk;
+
+ ret = clk_prepare_enable(dt->clk_ecc);
+ if (ret)
+ goto out_disable_clk_x;
+
+ if (dt->clk_x) {
+ denali->clk_x_rate = clk_get_rate(dt->clk_x);
+ } else {
+ /*
+* Hardcode the clock rates for the backward compatibility.
+* This works for both SOCFPGA and UniPhier.
+*/
+ dev_notice(dev,
+ "necessary clock is missing. default clock rates are
used.\n");
+ denali->clk_x_rate = 2;
+ }
ret = denali_init(denali);
if (ret)
- goto out_disable_clk;
+ goto out_disable_clk_ecc;
platform_set_drvdata(pdev, dt);
return 0;
+out_disable_clk_ecc:
+ clk_disable_unprepare(dt->clk_ecc);
+out_disable_clk_x:
+ clk_disable_unprepare(dt->clk_x);
out_disable_clk:
clk_disable_unprepare(dt->clk);
@@ -144,6 +183,8 @@ static int denali_dt_remove(struct platform_device *pdev)
struct denali_dt *dt = platform_get_drvdata(pdev);
denali_remove(>denali);
+
[PATCH v2 2/3] mtd: rawnand: denali_dt: add more clocks based on IP datasheet
According to the Denali User's Guide, this IP needs three clocks:
- clk: controller core clock
- clk_x: bus interface clock
- ecc_clk: clock at which ECC circuitry is run
Currently, denali_dt.c requires a single anonymous clock and its
frequency. However, the driver needs to get the frequency of "clk_x"
not "clk". This is confusing because people tend to assume the
anonymous clock means the core clock.
Instead of the cheesy implementation, the clocks in the real hardware
should be represented in the driver and the DT-binding.
However, adding new clocks would break the existing platforms. For the
backward compatibility, the driver still accepts a single clock just as
before. If clk_x is missing, clk_x_rate is set to a hardcoded value.
It is fine because both Altera (Intel) SOCFPGA and Socionext UniPhier
use 200 MHz for the bus interface clock.
Signed-off-by: Masahiro Yamada
---
Changes in v2: split into sensible chunks
.../devicetree/bindings/mtd/denali-nand.txt| 5 +++
drivers/mtd/nand/raw/denali_dt.c | 49 --
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt
b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index 0ee8edb..f33da87 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -8,6 +8,9 @@ Required properties:
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
- interrupts : The interrupt number.
+ - clocks: should contain phandle of the controller core clock, the bus
+interface clock, and the ECC circuit clock.
+ - clock-names: should contain "nand", "nand_x", "ecc"
Optional properties:
- nand-ecc-step-size: see nand.txt for details. If present, the value must
be
@@ -31,5 +34,7 @@ nand: nand@ff90 {
compatible = "altr,socfpga-denali-nand";
reg = <0xff90 0x20>, <0xffb8 0x1000>;
reg-names = "nand_data", "denali_reg";
+ clocks = <_clk>, <_x_clk>, <_ecc_clk>;
+ clock-names = "nand", "nand_x", "ecc";
interrupts = <0 144 4>;
};
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index d923cfa..afaae37 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -27,7 +27,9 @@
struct denali_dt {
struct denali_nand_info denali;
- struct clk *clk;
+ struct clk *clk;/* core clock */
+ struct clk *clk_x; /* bus interface clock */
+ struct clk *clk_ecc;/* ECC circuit clock */
};
struct denali_dt_data {
@@ -115,24 +117,61 @@ static int denali_dt_probe(struct platform_device *pdev)
if (IS_ERR(denali->host))
return PTR_ERR(denali->host);
- dt->clk = devm_clk_get(dev, NULL);
+ /*
+* A single anonymous clock is supported for the backward compatibility.
+* New platforms should support all the named clocks.
+*/
+ dt->clk = devm_clk_get(dev, "nand");
+ if (IS_ERR(dt->clk))
+ dt->clk = devm_clk_get(dev, NULL);
if (IS_ERR(dt->clk)) {
dev_err(dev, "no clk available\n");
return PTR_ERR(dt->clk);
}
+
+ dt->clk_x = devm_clk_get(dev, "nand_x");
+ if (IS_ERR(dt->clk_x))
+ dt->clk_x = NULL;
+
+ dt->clk_ecc = devm_clk_get(dev, "ecc");
+ if (IS_ERR(dt->clk_ecc))
+ dt->clk_ecc = NULL;
+
ret = clk_prepare_enable(dt->clk);
if (ret)
return ret;
- denali->clk_x_rate = clk_get_rate(dt->clk);
+ ret = clk_prepare_enable(dt->clk_x);
+ if (ret)
+ goto out_disable_clk;
+
+ ret = clk_prepare_enable(dt->clk_ecc);
+ if (ret)
+ goto out_disable_clk_x;
+
+ if (dt->clk_x) {
+ denali->clk_x_rate = clk_get_rate(dt->clk_x);
+ } else {
+ /*
+* Hardcode the clock rates for the backward compatibility.
+* This works for both SOCFPGA and UniPhier.
+*/
+ dev_notice(dev,
+ "necessary clock is missing. default clock rates are
used.\n");
+ denali->clk_x_rate = 2;
+ }
ret = denali_init(denali);
if (ret)
- goto out_disable_clk;
+ goto out_disable_clk_ecc;
platform_set_drvdata(pdev, dt);
return 0;
+out_disable_clk_ecc:
+ clk_disable_unprepare(dt->clk_ecc);
+out_disable_clk_x:
+ clk_disable_unprepare(dt->clk_x);
out_disable_clk:
clk_disable_unprepare(dt->clk);
@@ -144,6 +183,8 @@ static int denali_dt_remove(struct platform_device *pdev)
struct denali_dt *dt = platform_get_drvdata(pdev);
denali_remove(>denali);
+
Re: [PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
On Wed, Jun 13, 2018 at 10:40:32AM +0200, Oscar Salvador wrote:
> On Wed, Jun 13, 2018 at 05:41:08AM +, Naoya Horiguchi wrote:
> > Hi everyone,
> >
> > I wrote a patch for this issue.
> > There was a discussion about prechecking approach, but I finally found
> > out it's hard to make change on memblock after numa_init, so I take
> > another apporach (see patch description).
> >
> > I'm glad if you check that it works for you.
> >
> > Thanks,
> > Naoya Horiguchi
> > ---
> > From: Naoya Horiguchi
> > Date: Wed, 13 Jun 2018 12:43:27 +0900
> > Subject: [PATCH] mm: zero remaining unavailable struct pages
> >
> > There is a kernel panic that is triggered when reading /proc/kpageflags
> > on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
> >
> > BUG: unable to handle kernel paging request at fffe
> > PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
> > Oops: [#1] SMP PTI
> > CPU: 2 PID: 1728 Comm: page-types Not tainted
> > 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28
> > 04/01/2014
> > RIP: 0010:stable_page_flags+0x27/0x3c0
> > Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89
> > fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6
> > c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
> > RSP: 0018:bbd44111fde0 EFLAGS: 00010202
> > RAX: fffe RBX: 7fffeff9 RCX:
> > RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
> > RBP: R08: 0001 R09: 0001
> > R10: bbd44111fed8 R11: R12: ed1182fff5c0
> > R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
> > FS: 7efc4335a500() GS:93a5bfc0()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: fffe CR3: b2a58000 CR4: 001406e0
> > Call Trace:
> >kpageflags_read+0xc7/0x120
> >proc_reg_read+0x3c/0x60
> >__vfs_read+0x36/0x170
> >vfs_read+0x89/0x130
> >ksys_pread64+0x71/0x90
> >do_syscall_64+0x5b/0x160
> >entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x7efc42e75e23
> > Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00
> > 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0
> > ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
> >
> > According to kernel bisection, this problem became visible due to commit
> > f7f99100d8d9 which changes how struct pages are initialized.
> >
> > Memblock layout affects the pfn ranges covered by node/zone. Consider
> > that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
> > the default (no memmap= given) memblock layout is like below:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001fff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x4
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x0001-0x00013fff],
> > 0x4000 bytes on node 0 flags: 0x0
> >memory[0x3] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > If you give memmap=1G!4G (so it just covers memory[0x2]),
> > the range [0x1-0x13fff] is gone:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001bff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x3
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > This causes shrinking node 0's pfn range because it is calculated by
> > the address range of memblock.memory. So some of struct pages in the
> > gap range are left uninitialized.
> >
> > We have a function zero_resv_unavail() which does zeroing the struct
> > pages outside memblock.memory, but currently it covers only the reserved
> > unavailable range (i.e. memblock.memory && !memblock.reserved).
> > This patch extends it to cover all unavailable range, which fixes
> > the reported issue.
> >
> > Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
> > Signed-off-by: Naoya Horiguchi
> > ---
> > include/linux/memblock.h | 16
> > mm/page_alloc.c | 33 -
> > 2 files changed, 24 insertions(+), 25 deletions(-)
> >
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> >
Re: [PATCH v1] mm: zero remaining unavailable struct pages (Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM)
On Wed, Jun 13, 2018 at 10:40:32AM +0200, Oscar Salvador wrote:
> On Wed, Jun 13, 2018 at 05:41:08AM +, Naoya Horiguchi wrote:
> > Hi everyone,
> >
> > I wrote a patch for this issue.
> > There was a discussion about prechecking approach, but I finally found
> > out it's hard to make change on memblock after numa_init, so I take
> > another apporach (see patch description).
> >
> > I'm glad if you check that it works for you.
> >
> > Thanks,
> > Naoya Horiguchi
> > ---
> > From: Naoya Horiguchi
> > Date: Wed, 13 Jun 2018 12:43:27 +0900
> > Subject: [PATCH] mm: zero remaining unavailable struct pages
> >
> > There is a kernel panic that is triggered when reading /proc/kpageflags
> > on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
> >
> > BUG: unable to handle kernel paging request at fffe
> > PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
> > Oops: [#1] SMP PTI
> > CPU: 2 PID: 1728 Comm: page-types Not tainted
> > 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28
> > 04/01/2014
> > RIP: 0010:stable_page_flags+0x27/0x3c0
> > Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89
> > fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6
> > c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
> > RSP: 0018:bbd44111fde0 EFLAGS: 00010202
> > RAX: fffe RBX: 7fffeff9 RCX:
> > RDX: 0001 RSI: 0202 RDI: ed1182fff5c0
> > RBP: R08: 0001 R09: 0001
> > R10: bbd44111fed8 R11: R12: ed1182fff5c0
> > R13: 000bffd7 R14: 02fff5c0 R15: bbd44111ff10
> > FS: 7efc4335a500() GS:93a5bfc0()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: fffe CR3: b2a58000 CR4: 001406e0
> > Call Trace:
> >kpageflags_read+0xc7/0x120
> >proc_reg_read+0x3c/0x60
> >__vfs_read+0x36/0x170
> >vfs_read+0x89/0x130
> >ksys_pread64+0x71/0x90
> >do_syscall_64+0x5b/0x160
> >entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x7efc42e75e23
> > Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00
> > 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0
> > ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
> >
> > According to kernel bisection, this problem became visible due to commit
> > f7f99100d8d9 which changes how struct pages are initialized.
> >
> > Memblock layout affects the pfn ranges covered by node/zone. Consider
> > that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
> > the default (no memmap= given) memblock layout is like below:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001fff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x4
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x0001-0x00013fff],
> > 0x4000 bytes on node 0 flags: 0x0
> >memory[0x3] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > If you give memmap=1G!4G (so it just covers memory[0x2]),
> > the range [0x1-0x13fff] is gone:
> >
> > MEMBLOCK configuration:
> >memory size = 0x0001bff75c00 reserved size = 0x0300c000
> >memory.cnt = 0x3
> >memory[0x0] [0x1000-0x0009efff],
> > 0x0009e000 bytes on node 0 flags: 0x0
> >memory[0x1] [0x0010-0xbffd6fff],
> > 0xbfed7000 bytes on node 0 flags: 0x0
> >memory[0x2] [0x00014000-0x00023fff],
> > 0x0001 bytes on node 1 flags: 0x0
> >...
> >
> > This causes shrinking node 0's pfn range because it is calculated by
> > the address range of memblock.memory. So some of struct pages in the
> > gap range are left uninitialized.
> >
> > We have a function zero_resv_unavail() which does zeroing the struct
> > pages outside memblock.memory, but currently it covers only the reserved
> > unavailable range (i.e. memblock.memory && !memblock.reserved).
> > This patch extends it to cover all unavailable range, which fixes
> > the reported issue.
> >
> > Fixes: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap")
> > Signed-off-by: Naoya Horiguchi
> > ---
> > include/linux/memblock.h | 16
> > mm/page_alloc.c | 33 -
> > 2 files changed, 24 insertions(+), 25 deletions(-)
> >
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> >
[PATCH] extcon: Release locking when sending the notification of connector state
Previously, extcon used the spinlock before calling the notifier_call_chain
to prevent the scheduled out of task and to prevent the notification delay.
When spinlock is locked for sending the notification, deadlock issue
occured on the side of extcon consumer device. To fix this issue,
extcon consumer device should always use the work. it is always not
reasonable to use work.
To fix this issue on extcon consumer device, release locking when sending
the notification of connector state.
Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support
the notification")
Cc: sta...@vger.kernel.org
Cc: Roger Quadros
Cc: Kishon Vijay Abraham I
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 8bff5fd18185..f75b08a45d4e 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
return index;
spin_lock_irqsave(>lock, flags);
-
state = !!(edev->state & BIT(index));
+ spin_unlock_irqrestore(>lock, flags);
/*
* Call functions in a raw notifier chain for the specific one
@@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
*/
raw_notifier_call_chain(>nh_all, state, edev);
+ spin_lock_irqsave(>lock, flags);
/* This could be in interrupt handler */
prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
if (!prop_buf) {
--
1.9.1
[PATCH] extcon: Release locking when sending the notification of connector state
Previously, extcon used the spinlock before calling the notifier_call_chain
to prevent the scheduled out of task and to prevent the notification delay.
When spinlock is locked for sending the notification, deadlock issue
occured on the side of extcon consumer device. To fix this issue,
extcon consumer device should always use the work. it is always not
reasonable to use work.
To fix this issue on extcon consumer device, release locking when sending
the notification of connector state.
Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support
the notification")
Cc: sta...@vger.kernel.org
Cc: Roger Quadros
Cc: Kishon Vijay Abraham I
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 8bff5fd18185..f75b08a45d4e 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
return index;
spin_lock_irqsave(>lock, flags);
-
state = !!(edev->state & BIT(index));
+ spin_unlock_irqrestore(>lock, flags);
/*
* Call functions in a raw notifier chain for the specific one
@@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
*/
raw_notifier_call_chain(>nh_all, state, edev);
+ spin_lock_irqsave(>lock, flags);
/* This could be in interrupt handler */
prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
if (!prop_buf) {
--
1.9.1
Re: [PATCH] selftests: kselftest_harness: return Kselftest Skip code for skipped tests
On Wed, Jun 13, 2018 at 6:34 PM, Shuah Khan (Samsung OSG)
wrote:
> When a test is skipped because of unmet dependencies and/or unsupported
> configuration, kselftest_harness exits with error which is treated as a
> fail by the Kselftest framework. This leads to false negative result even
> when the test could not be run.
>
> Change it to return kselftest skip code when a test gets skipped to
> clearly report that the test could not be run. This change add skip
> handling to kselftest_harness with minimal changes adding a new skipped
> field to struct __test_metadata and using it to recognize KSFT_SKIP exit
> from the test function (t->fn) to __run_test() to the test_harness_run()
> to return the right skip code to Kselftest framework.
>
> Kselftest framework SKIP code is 4 and the framework prints appropriate
> messages to indicate that the test is skipped.
Unfortunately this will not work: test step # is used as the failure
code to let test runners know where a child failed. KSFT_SKIP is 4, so
every test failing in step 4 would be seen as a skip instead of a
fail.
Tests must not exit on their own with this harness: only the existing
ASSERT/EXPECT macros can be used. uevent test should never be doing
this:
if (geteuid()) {
TH_LOG("Uevent filtering tests require root
privileges. Skipping test");
_exit(KSFT_SKIP);
}
Nor the _exit(EXIT_FAILURE) calls. Those must all be ASSERT() instead.
Perhaps a new signal could be used, but the return codes are already being used.
-Kees
>
> This change is tested on uevent test and the results are as follows:
>
> Before:
>
> TAP version 13
> selftests: uevent: uevent_filtering
>
> [==] Running 1 tests from 1 test cases.
> [ RUN ] global.uevent_filtering
> uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
> root privileges. Skipping test
> global.uevent_filtering: Test skipped at step #4
> [ FAIL ] global.uevent_filtering
> [==] 0 / 1 tests passed.
> [ FAILED ]
> not ok 1..1 selftests: uevent: uevent_filtering [FAIL]
>
> After:
>
> TAP version 13
> selftests: uevent: uevent_filtering
>
> [==] Running 1 tests from 1 test cases.
> [ RUN ] global.uevent_filtering
> uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
> root privileges. Skipping test
> global.uevent_filtering: Test skipped at step #4
> [ SKIP ] global.uevent_filtering
> not ok 1..1 selftests: uevent: uevent_filtering [SKIP]
>
> Signed-off-by: Shuah Khan (Samsung OSG)
> ---
> tools/testing/selftests/kselftest_harness.h | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/kselftest_harness.h
> b/tools/testing/selftests/kselftest_harness.h
> index 6ae3730c4ee3..7af9ab97b367 100644
> --- a/tools/testing/selftests/kselftest_harness.h
> +++ b/tools/testing/selftests/kselftest_harness.h
> @@ -631,6 +631,7 @@ struct __test_metadata {
> void (*fn)(struct __test_metadata *);
> int termsig;
> int passed;
> + int skipped;
> int trigger; /* extra handler after the evaluation */
> __u8 step;
> bool no_print; /* manual trigger when TH_LOG_STREAM is not available
> */
> @@ -694,6 +695,7 @@ void __run_test(struct __test_metadata *t)
> int status;
>
> t->passed = 1;
> + t->skipped = 0;
> t->trigger = 0;
> printf("[ RUN ] %s\n", t->name);
> child_pid = fork();
> @@ -716,9 +718,12 @@ void __run_test(struct __test_metadata *t)
> t->name,
> WEXITSTATUS(status));
> } else if (!t->passed) {
> + if (WEXITSTATUS(status) == KSFT_SKIP)
> + t->skipped = 1;
> fprintf(TH_LOG_STREAM,
> - "%s: Test failed at step #%d\n",
> + "%s: Test %s at step #%d\n",
> t->name,
> + (t->skipped ? "skipped" : "failed"),
> WEXITSTATUS(status));
> }
> } else if (WIFSIGNALED(status)) {
> @@ -743,7 +748,11 @@ void __run_test(struct __test_metadata *t)
> status);
> }
> }
> - printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"), t->name);
> + if (t->skipped)
> + printf("[ %4s ] %s\n", "SKIP", t->name);
> + else
> + printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"),
> + t->name);
> }
>
> static int test_harness_run(int __attribute__((unused)) argc,
> @@ -762,6 +771,8 @@ static int test_harness_run(int
Re: [PATCH] selftests: kselftest_harness: return Kselftest Skip code for skipped tests
On Wed, Jun 13, 2018 at 6:34 PM, Shuah Khan (Samsung OSG)
wrote:
> When a test is skipped because of unmet dependencies and/or unsupported
> configuration, kselftest_harness exits with error which is treated as a
> fail by the Kselftest framework. This leads to false negative result even
> when the test could not be run.
>
> Change it to return kselftest skip code when a test gets skipped to
> clearly report that the test could not be run. This change add skip
> handling to kselftest_harness with minimal changes adding a new skipped
> field to struct __test_metadata and using it to recognize KSFT_SKIP exit
> from the test function (t->fn) to __run_test() to the test_harness_run()
> to return the right skip code to Kselftest framework.
>
> Kselftest framework SKIP code is 4 and the framework prints appropriate
> messages to indicate that the test is skipped.
Unfortunately this will not work: test step # is used as the failure
code to let test runners know where a child failed. KSFT_SKIP is 4, so
every test failing in step 4 would be seen as a skip instead of a
fail.
Tests must not exit on their own with this harness: only the existing
ASSERT/EXPECT macros can be used. uevent test should never be doing
this:
if (geteuid()) {
TH_LOG("Uevent filtering tests require root
privileges. Skipping test");
_exit(KSFT_SKIP);
}
Nor the _exit(EXIT_FAILURE) calls. Those must all be ASSERT() instead.
Perhaps a new signal could be used, but the return codes are already being used.
-Kees
>
> This change is tested on uevent test and the results are as follows:
>
> Before:
>
> TAP version 13
> selftests: uevent: uevent_filtering
>
> [==] Running 1 tests from 1 test cases.
> [ RUN ] global.uevent_filtering
> uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
> root privileges. Skipping test
> global.uevent_filtering: Test skipped at step #4
> [ FAIL ] global.uevent_filtering
> [==] 0 / 1 tests passed.
> [ FAILED ]
> not ok 1..1 selftests: uevent: uevent_filtering [FAIL]
>
> After:
>
> TAP version 13
> selftests: uevent: uevent_filtering
>
> [==] Running 1 tests from 1 test cases.
> [ RUN ] global.uevent_filtering
> uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
> root privileges. Skipping test
> global.uevent_filtering: Test skipped at step #4
> [ SKIP ] global.uevent_filtering
> not ok 1..1 selftests: uevent: uevent_filtering [SKIP]
>
> Signed-off-by: Shuah Khan (Samsung OSG)
> ---
> tools/testing/selftests/kselftest_harness.h | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/kselftest_harness.h
> b/tools/testing/selftests/kselftest_harness.h
> index 6ae3730c4ee3..7af9ab97b367 100644
> --- a/tools/testing/selftests/kselftest_harness.h
> +++ b/tools/testing/selftests/kselftest_harness.h
> @@ -631,6 +631,7 @@ struct __test_metadata {
> void (*fn)(struct __test_metadata *);
> int termsig;
> int passed;
> + int skipped;
> int trigger; /* extra handler after the evaluation */
> __u8 step;
> bool no_print; /* manual trigger when TH_LOG_STREAM is not available
> */
> @@ -694,6 +695,7 @@ void __run_test(struct __test_metadata *t)
> int status;
>
> t->passed = 1;
> + t->skipped = 0;
> t->trigger = 0;
> printf("[ RUN ] %s\n", t->name);
> child_pid = fork();
> @@ -716,9 +718,12 @@ void __run_test(struct __test_metadata *t)
> t->name,
> WEXITSTATUS(status));
> } else if (!t->passed) {
> + if (WEXITSTATUS(status) == KSFT_SKIP)
> + t->skipped = 1;
> fprintf(TH_LOG_STREAM,
> - "%s: Test failed at step #%d\n",
> + "%s: Test %s at step #%d\n",
> t->name,
> + (t->skipped ? "skipped" : "failed"),
> WEXITSTATUS(status));
> }
> } else if (WIFSIGNALED(status)) {
> @@ -743,7 +748,11 @@ void __run_test(struct __test_metadata *t)
> status);
> }
> }
> - printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"), t->name);
> + if (t->skipped)
> + printf("[ %4s ] %s\n", "SKIP", t->name);
> + else
> + printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"),
> + t->name);
> }
>
> static int test_harness_run(int __attribute__((unused)) argc,
> @@ -762,6 +771,8 @@ static int test_harness_run(int
Improving kselfests cross compilation
Hi Shuah,
I was giving a shot at building the kselftests from within buildroot [1]
as of Linux be779f03d563981c65cc7417cc5e0dbbc5b89d30 and there are a
number of things that make it still reasonably hard even today:
- 3c545084130c1fd5cf873a5fec3ee29070128e06 ("selftests: sparc64: char:
Selftest for privileged ADI driver") this contains inline assembly that
can only work when building for sparc64, yet this is still being built
irrespective of what ARCH is set to
- each Makefile that requires knowledge of the architecture seems to
duplicate what ARCH should be, this cannot be moved to lib.mk since
Makefiles do expect lib.mk to be included last and/or after they have
done their own overrides, but something like common.mk which contains
CC, ARCH etc. could be useful to avoid the repetition of looking at
uname -m etc. etc.
- some tests' Makefile do seem to hardcode paths to the system's include
instead of accepting a configurable path:
gpio/Makefile:
LDLIBS += -lmount -I/usr/include/libmount
I will try to submit patches in the next days that address the most
obvious issues I listed here, but in order for this effort not to be a
constant whack-a-mole game, there really needs to be at least one or two
architectures that must attempt to cross-compile (and run) those tests
and use that as an acceptance criteria.
Thanks for reading.
[1]:
https://git.buildroot.org/buildroot/tree/package/linux-tools/linux-tool-selftests.mk.in
--
Florian
Improving kselfests cross compilation
Hi Shuah,
I was giving a shot at building the kselftests from within buildroot [1]
as of Linux be779f03d563981c65cc7417cc5e0dbbc5b89d30 and there are a
number of things that make it still reasonably hard even today:
- 3c545084130c1fd5cf873a5fec3ee29070128e06 ("selftests: sparc64: char:
Selftest for privileged ADI driver") this contains inline assembly that
can only work when building for sparc64, yet this is still being built
irrespective of what ARCH is set to
- each Makefile that requires knowledge of the architecture seems to
duplicate what ARCH should be, this cannot be moved to lib.mk since
Makefiles do expect lib.mk to be included last and/or after they have
done their own overrides, but something like common.mk which contains
CC, ARCH etc. could be useful to avoid the repetition of looking at
uname -m etc. etc.
- some tests' Makefile do seem to hardcode paths to the system's include
instead of accepting a configurable path:
gpio/Makefile:
LDLIBS += -lmount -I/usr/include/libmount
I will try to submit patches in the next days that address the most
obvious issues I listed here, but in order for this effort not to be a
constant whack-a-mole game, there really needs to be at least one or two
architectures that must attempt to cross-compile (and run) those tests
and use that as an acceptance criteria.
Thanks for reading.
[1]:
https://git.buildroot.org/buildroot/tree/package/linux-tools/linux-tool-selftests.mk.in
--
Florian
Re: linux-next: manual merge of the cifs tree with Linus' tree
Steve,
Looks good. It builds and seems to work in my testing.
Thanks.
- Original Message -
From: "Steve French"
To: "Stephen Rothwell"
Cc: "CIFS" , "Linux-Next Mailing List"
, "Linux Kernel Mailing List"
, "Kees Cook" , "Ronnie
Sahlberg" , "Aurelien Aptel"
Sent: Thursday, 14 June, 2018 10:40:43 AM
Subject: Re: linux-next: manual merge of the cifs tree with Linus' tree
Ronnie,
I fixed up that patch and repushed to cifs-2.6.git for-next. Seems
trivial. Let me know if any issues.
On Wed, Jun 13, 2018 at 6:01 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the cifs tree got a conflict in:
>
> fs/cifs/transport.c
>
> between commit:
>
> 6da2ec56059c ("treewide: kmalloc() -> kmalloc_array()")
>
> from Linus' tree and commit:
>
> 1560d69e21c6 ("cifs: push rfc1002 generation down the stack")
>
> from the cifs tree.
>
> I fixed it up (the latter removed the code modified by the former) and
> can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the cifs tree with Linus' tree
Steve,
Looks good. It builds and seems to work in my testing.
Thanks.
- Original Message -
From: "Steve French"
To: "Stephen Rothwell"
Cc: "CIFS" , "Linux-Next Mailing List"
, "Linux Kernel Mailing List"
, "Kees Cook" , "Ronnie
Sahlberg" , "Aurelien Aptel"
Sent: Thursday, 14 June, 2018 10:40:43 AM
Subject: Re: linux-next: manual merge of the cifs tree with Linus' tree
Ronnie,
I fixed up that patch and repushed to cifs-2.6.git for-next. Seems
trivial. Let me know if any issues.
On Wed, Jun 13, 2018 at 6:01 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the cifs tree got a conflict in:
>
> fs/cifs/transport.c
>
> between commit:
>
> 6da2ec56059c ("treewide: kmalloc() -> kmalloc_array()")
>
> from Linus' tree and commit:
>
> 1560d69e21c6 ("cifs: push rfc1002 generation down the stack")
>
> from the cifs tree.
>
> I fixed it up (the latter removed the code modified by the former) and
> can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] selftests: vm: return Kselftest Skip code for skipped tests
When vm test is skipped because of unmet dependencies and/or unsupported
configuration, it exits with error which is treated as a fail by the
Kselftest framework. This leads to false negative result even when the
test could not be run.
Change it to return kselftest skip code when a test gets skipped to
clearly report that the test could not be run.
Kselftest framework SKIP code is 4 and the framework prints appropriate
messages to indicate that the test is skipped.
Signed-off-by: Shuah Khan (Samsung OSG)
---
tools/testing/selftests/vm/compaction_test.c | 4 +++-
tools/testing/selftests/vm/mlock2-tests.c| 12 +++-
tools/testing/selftests/vm/run_vmtests | 5 -
tools/testing/selftests/vm/userfaultfd.c | 4 +++-
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/vm/compaction_test.c
b/tools/testing/selftests/vm/compaction_test.c
index 1097f04e4d80..bcec71250873 100644
--- a/tools/testing/selftests/vm/compaction_test.c
+++ b/tools/testing/selftests/vm/compaction_test.c
@@ -16,6 +16,8 @@
#include
#include
+#include "../kselftest.h"
+
#define MAP_SIZE 1048576
struct map_list {
@@ -169,7 +171,7 @@ int main(int argc, char **argv)
printf("Either the sysctl compact_unevictable_allowed is not\n"
"set to 1 or couldn't read the proc file.\n"
"Skipping the test\n");
- return 0;
+ return KSFT_SKIP;
}
lim.rlim_cur = RLIM_INFINITY;
diff --git a/tools/testing/selftests/vm/mlock2-tests.c
b/tools/testing/selftests/vm/mlock2-tests.c
index 4997b9222cfa..637b6d0ac0d0 100644
--- a/tools/testing/selftests/vm/mlock2-tests.c
+++ b/tools/testing/selftests/vm/mlock2-tests.c
@@ -9,6 +9,8 @@
#include
#include "mlock2.h"
+#include "../kselftest.h"
+
struct vm_boundaries {
unsigned long start;
unsigned long end;
@@ -303,7 +305,7 @@ static int test_mlock_lock()
if (mlock2_(map, 2 * page_size, 0)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock2(0)");
goto unmap;
@@ -412,7 +414,7 @@ static int test_mlock_onfault()
if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock2(MLOCK_ONFAULT)");
goto unmap;
@@ -425,7 +427,7 @@ static int test_mlock_onfault()
if (munlock(map, 2 * page_size)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("munlock()");
goto unmap;
@@ -457,7 +459,7 @@ static int test_lock_onfault_of_present()
if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock2(MLOCK_ONFAULT)");
goto unmap;
@@ -583,7 +585,7 @@ static int test_vma_management(bool call_mlock)
if (call_mlock && mlock2_(map, 3 * page_size, MLOCK_ONFAULT)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock(ONFAULT)\n");
goto out;
diff --git a/tools/testing/selftests/vm/run_vmtests
b/tools/testing/selftests/vm/run_vmtests
index 22d564673830..88cbe5575f0c 100755
--- a/tools/testing/selftests/vm/run_vmtests
+++ b/tools/testing/selftests/vm/run_vmtests
@@ -2,6 +2,9 @@
# SPDX-License-Identifier: GPL-2.0
#please run as root
+# Kselftest framework requirement - SKIP code is 4.
+ksft_skip=4
+
mnt=./huge
exitcode=0
@@ -36,7 +39,7 @@ if [ -n "$freepgs" ] && [ -n "$hpgsize_KB" ]; then
echo $(( $lackpgs + $nr_hugepgs )) > /proc/sys/vm/nr_hugepages
if [ $? -ne 0 ]; then
echo "Please run this test as root"
- exit 1
+ exit $ksft_skip
fi
while read name size unit; do
if [ "$name" = "HugePages_Free:" ]; then
diff --git a/tools/testing/selftests/vm/userfaultfd.c
b/tools/testing/selftests/vm/userfaultfd.c
index de2f9ec8a87f..7b8171e3128a 100644
--- a/tools/testing/selftests/vm/userfaultfd.c
+++ b/tools/testing/selftests/vm/userfaultfd.c
@@ -69,6 +69,8 @@
[PATCH] selftests: vm: return Kselftest Skip code for skipped tests
When vm test is skipped because of unmet dependencies and/or unsupported
configuration, it exits with error which is treated as a fail by the
Kselftest framework. This leads to false negative result even when the
test could not be run.
Change it to return kselftest skip code when a test gets skipped to
clearly report that the test could not be run.
Kselftest framework SKIP code is 4 and the framework prints appropriate
messages to indicate that the test is skipped.
Signed-off-by: Shuah Khan (Samsung OSG)
---
tools/testing/selftests/vm/compaction_test.c | 4 +++-
tools/testing/selftests/vm/mlock2-tests.c| 12 +++-
tools/testing/selftests/vm/run_vmtests | 5 -
tools/testing/selftests/vm/userfaultfd.c | 4 +++-
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/vm/compaction_test.c
b/tools/testing/selftests/vm/compaction_test.c
index 1097f04e4d80..bcec71250873 100644
--- a/tools/testing/selftests/vm/compaction_test.c
+++ b/tools/testing/selftests/vm/compaction_test.c
@@ -16,6 +16,8 @@
#include
#include
+#include "../kselftest.h"
+
#define MAP_SIZE 1048576
struct map_list {
@@ -169,7 +171,7 @@ int main(int argc, char **argv)
printf("Either the sysctl compact_unevictable_allowed is not\n"
"set to 1 or couldn't read the proc file.\n"
"Skipping the test\n");
- return 0;
+ return KSFT_SKIP;
}
lim.rlim_cur = RLIM_INFINITY;
diff --git a/tools/testing/selftests/vm/mlock2-tests.c
b/tools/testing/selftests/vm/mlock2-tests.c
index 4997b9222cfa..637b6d0ac0d0 100644
--- a/tools/testing/selftests/vm/mlock2-tests.c
+++ b/tools/testing/selftests/vm/mlock2-tests.c
@@ -9,6 +9,8 @@
#include
#include "mlock2.h"
+#include "../kselftest.h"
+
struct vm_boundaries {
unsigned long start;
unsigned long end;
@@ -303,7 +305,7 @@ static int test_mlock_lock()
if (mlock2_(map, 2 * page_size, 0)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock2(0)");
goto unmap;
@@ -412,7 +414,7 @@ static int test_mlock_onfault()
if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock2(MLOCK_ONFAULT)");
goto unmap;
@@ -425,7 +427,7 @@ static int test_mlock_onfault()
if (munlock(map, 2 * page_size)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("munlock()");
goto unmap;
@@ -457,7 +459,7 @@ static int test_lock_onfault_of_present()
if (mlock2_(map, 2 * page_size, MLOCK_ONFAULT)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock2(MLOCK_ONFAULT)");
goto unmap;
@@ -583,7 +585,7 @@ static int test_vma_management(bool call_mlock)
if (call_mlock && mlock2_(map, 3 * page_size, MLOCK_ONFAULT)) {
if (errno == ENOSYS) {
printf("Cannot call new mlock family, skipping test\n");
- _exit(0);
+ _exit(KSFT_SKIP);
}
perror("mlock(ONFAULT)\n");
goto out;
diff --git a/tools/testing/selftests/vm/run_vmtests
b/tools/testing/selftests/vm/run_vmtests
index 22d564673830..88cbe5575f0c 100755
--- a/tools/testing/selftests/vm/run_vmtests
+++ b/tools/testing/selftests/vm/run_vmtests
@@ -2,6 +2,9 @@
# SPDX-License-Identifier: GPL-2.0
#please run as root
+# Kselftest framework requirement - SKIP code is 4.
+ksft_skip=4
+
mnt=./huge
exitcode=0
@@ -36,7 +39,7 @@ if [ -n "$freepgs" ] && [ -n "$hpgsize_KB" ]; then
echo $(( $lackpgs + $nr_hugepgs )) > /proc/sys/vm/nr_hugepages
if [ $? -ne 0 ]; then
echo "Please run this test as root"
- exit 1
+ exit $ksft_skip
fi
while read name size unit; do
if [ "$name" = "HugePages_Free:" ]; then
diff --git a/tools/testing/selftests/vm/userfaultfd.c
b/tools/testing/selftests/vm/userfaultfd.c
index de2f9ec8a87f..7b8171e3128a 100644
--- a/tools/testing/selftests/vm/userfaultfd.c
+++ b/tools/testing/selftests/vm/userfaultfd.c
@@ -69,6 +69,8 @@
[PATCH] devres: Add devm_of_iomap()
There are still quite a few cases where a device might want
to get to a different node of the device-tree, obtain the
resources and map them.
This is generally open coded in drivers which is quite error prone
We have of_iomap() and of_io_request_and_map() but they both
have shortcomings, such as not returning the size of the
resource found (which can be useful) and not being "managed".
This adds a devm_of_iomap() that provides all of these and
should probably replace uses of the above in most drivers.
Signed-off-by: Benjamin Herrenschmidt
---
include/linux/device.h | 4
lib/devres.c | 36
2 files changed, 40 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index beabdbc08420..1529775ecb36 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -686,6 +686,10 @@ extern void devm_free_pages(struct device *dev, unsigned
long addr);
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+void __iomem *devm_of_iomap(struct device *dev,
+ struct device_node *node, int index,
+ resource_size_t *size);
+
/* allows to add/remove a custom action to devres stack */
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
void devm_remove_action(struct device *dev, void (*action)(void *), void
*data);
diff --git a/lib/devres.c b/lib/devres.c
index 78eca713b1d9..e320f80c1c4e 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
void devm_ioremap_release(struct device *dev, void *res)
{
@@ -163,6 +164,41 @@ void __iomem *devm_ioremap_resource(struct device *dev,
struct resource *res)
}
EXPORT_SYMBOL(devm_ioremap_resource);
+/*
+ * devm_of_iomap - Requests a resource and maps the memory mapped IO
+ *for a given device_node managed by a given device
+ *
+ * Checks that a resource is a valid memory region, requests the memory
+ * region and ioremaps it. All operations are managed and will be undone
+ * on driver detach of the device.
+ *
+ * This is to be used when a device requests/maps resources described
+ * by other device tree nodes (children or otherwise).
+ *
+ * @dev: The device "managing" the resource
+ * @node: The device-tree node where the resource resides
+ * @index: index of the MMIO range in the "reg" property
+ * @size: Returns the size of the resource (pass NULL if not needed)
+ * Returns a pointer to the requested and mapped memory or an ERR_PTR() encoded
+ * error code on failure. Usage example:
+ *
+ * base = devm_of_iomap(>dev, node, 0, NULL);
+ * if (IS_ERR(base))
+ * return PTR_ERR(base);
+ */
+void __iomem *devm_of_iomap(struct device *dev, struct device_node *node, int
index,
+ resource_size_t *size)
+{
+ struct resource res;
+
+ if (of_address_to_resource(node, index, ))
+ return IOMEM_ERR_PTR(-EINVAL);
+ if (size)
+ *size = resource_size();
+ return devm_ioremap_resource(dev, );
+}
+EXPORT_SYMBOL(devm_of_iomap);
+
#ifdef CONFIG_HAS_IOPORT_MAP
/*
* Generic iomap devres
[PATCH] devres: Add devm_of_iomap()
There are still quite a few cases where a device might want
to get to a different node of the device-tree, obtain the
resources and map them.
This is generally open coded in drivers which is quite error prone
We have of_iomap() and of_io_request_and_map() but they both
have shortcomings, such as not returning the size of the
resource found (which can be useful) and not being "managed".
This adds a devm_of_iomap() that provides all of these and
should probably replace uses of the above in most drivers.
Signed-off-by: Benjamin Herrenschmidt
---
include/linux/device.h | 4
lib/devres.c | 36
2 files changed, 40 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index beabdbc08420..1529775ecb36 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -686,6 +686,10 @@ extern void devm_free_pages(struct device *dev, unsigned
long addr);
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+void __iomem *devm_of_iomap(struct device *dev,
+ struct device_node *node, int index,
+ resource_size_t *size);
+
/* allows to add/remove a custom action to devres stack */
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
void devm_remove_action(struct device *dev, void (*action)(void *), void
*data);
diff --git a/lib/devres.c b/lib/devres.c
index 78eca713b1d9..e320f80c1c4e 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
void devm_ioremap_release(struct device *dev, void *res)
{
@@ -163,6 +164,41 @@ void __iomem *devm_ioremap_resource(struct device *dev,
struct resource *res)
}
EXPORT_SYMBOL(devm_ioremap_resource);
+/*
+ * devm_of_iomap - Requests a resource and maps the memory mapped IO
+ *for a given device_node managed by a given device
+ *
+ * Checks that a resource is a valid memory region, requests the memory
+ * region and ioremaps it. All operations are managed and will be undone
+ * on driver detach of the device.
+ *
+ * This is to be used when a device requests/maps resources described
+ * by other device tree nodes (children or otherwise).
+ *
+ * @dev: The device "managing" the resource
+ * @node: The device-tree node where the resource resides
+ * @index: index of the MMIO range in the "reg" property
+ * @size: Returns the size of the resource (pass NULL if not needed)
+ * Returns a pointer to the requested and mapped memory or an ERR_PTR() encoded
+ * error code on failure. Usage example:
+ *
+ * base = devm_of_iomap(>dev, node, 0, NULL);
+ * if (IS_ERR(base))
+ * return PTR_ERR(base);
+ */
+void __iomem *devm_of_iomap(struct device *dev, struct device_node *node, int
index,
+ resource_size_t *size)
+{
+ struct resource res;
+
+ if (of_address_to_resource(node, index, ))
+ return IOMEM_ERR_PTR(-EINVAL);
+ if (size)
+ *size = resource_size();
+ return devm_ioremap_resource(dev, );
+}
+EXPORT_SYMBOL(devm_of_iomap);
+
#ifdef CONFIG_HAS_IOPORT_MAP
/*
* Generic iomap devres
[PATCH] selftests: user: return Kselftest Skip code for skipped tests
When user test is skipped because of unmet dependencies and/or unsupported configuration, it exits with error which is treated as a fail by the Kselftest framework. This leads to false negative result even when the test could not be run. Change it to return kselftest skip code when a test gets skipped to clearly report that the test could not be run. Add an explicit check for module presence and return skip code if module isn't present. Kselftest framework SKIP code is 4 and the framework prints appropriate messages to indicate that the test is skipped. Signed-off-by: Shuah Khan (Samsung OSG) --- tools/testing/selftests/user/test_user_copy.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/tools/testing/selftests/user/test_user_copy.sh b/tools/testing/selftests/user/test_user_copy.sh index d60506fc77f8..f9b31a57439b 100755 --- a/tools/testing/selftests/user/test_user_copy.sh +++ b/tools/testing/selftests/user/test_user_copy.sh @@ -2,6 +2,13 @@ # SPDX-License-Identifier: GPL-2.0 # Runs copy_to/from_user infrastructure using test_user_copy kernel module +# Kselftest framework requirement - SKIP code is 4. +ksft_skip=4 + +if ! /sbin/modprobe -q -n test_user_copy; then + echo "user: module test_user_copy is not found [SKIP]" + exit $ksft_skip +fi if /sbin/modprobe -q test_user_copy; then /sbin/modprobe -q -r test_user_copy echo "user_copy: ok" -- 2.17.0
[PATCH] selftests: user: return Kselftest Skip code for skipped tests
When user test is skipped because of unmet dependencies and/or unsupported configuration, it exits with error which is treated as a fail by the Kselftest framework. This leads to false negative result even when the test could not be run. Change it to return kselftest skip code when a test gets skipped to clearly report that the test could not be run. Add an explicit check for module presence and return skip code if module isn't present. Kselftest framework SKIP code is 4 and the framework prints appropriate messages to indicate that the test is skipped. Signed-off-by: Shuah Khan (Samsung OSG) --- tools/testing/selftests/user/test_user_copy.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/tools/testing/selftests/user/test_user_copy.sh b/tools/testing/selftests/user/test_user_copy.sh index d60506fc77f8..f9b31a57439b 100755 --- a/tools/testing/selftests/user/test_user_copy.sh +++ b/tools/testing/selftests/user/test_user_copy.sh @@ -2,6 +2,13 @@ # SPDX-License-Identifier: GPL-2.0 # Runs copy_to/from_user infrastructure using test_user_copy kernel module +# Kselftest framework requirement - SKIP code is 4. +ksft_skip=4 + +if ! /sbin/modprobe -q -n test_user_copy; then + echo "user: module test_user_copy is not found [SKIP]" + exit $ksft_skip +fi if /sbin/modprobe -q test_user_copy; then /sbin/modprobe -q -r test_user_copy echo "user_copy: ok" -- 2.17.0
Re: [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
On Tue, 2018-06-12 at 17:58 +0800, Sean Wang wrote:
> On Wed, 2018-05-30 at 08:26 +0200, Marcel Holtmann wrote:
> > Hi Sean,
> >
> > >>
>
> [ ... ]
>
> > >>> * Unknown packet (code 14 len 30)
> > >>> 0.641509
> > >>> 01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..bl
> > >>> 75 65 74 6f 6f 74 68 64 00 00 00 00 00 00uetoothd..
> > >>> * Unknown packet (code 14 len 30)
> > >>> 0.641592
> > >>> 02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..bt
> > >>> 6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00mon...
> > >>> * Unknown packet (code 16 len 7)[hci0]
> > >>> 6.536771
> > >>> 01 00 00 00 05 00 01 ...
> > >>> = Open Index: 00:00:46:76:22:01 [hci0]
> > >>> 6.717019
> > >>> = Index Info: 00:00:46:76:22:01 (MediaTek, Inc.)[hci0]
> > >>> 6.717030
> > >>
> > >> can you try with the latest BlueZ 5.49 or git version. Seems it actually
> > >> stumbles over the extra packet here. Fun fact is that I can not get a
> > >> backtrace to pin-point the issue in btmon and why it crashes.
> > >>
> > >
> > > I had less experience updating user land BlueZ, but I can try it as
> > > possible and see whether Unknown packets still are present at newest
> > > version BlueZ. Hopefully I don't misunderstand your point here.
> >
> > please use the latest btmon and check if it can read your trace.
> >
>
> sure, I'll have a try with the latest btmon.
I use the btmon version 5.50 and it can read the trace
>
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.741093
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.742088
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.743102
> > >>> 02 01 01 00 00 .
>
>
> [ ... ]
>
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.814708
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.815705
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.816378
> > >>> 02 01 01 00 00 .
> > >>
> > >> Why do I see only HCI events here? Is this event conveying any useful
> > >> information. It is kinda complicated that this is 0xe4 event code which
> > >> is actually reserved for future use by the Bluetooth SIG. Are there any
> > >> accompanying HCI commands for this and they just not make it into btmon?
> > >>
> > >
> > > I have made all vendor HCI commands go through BlueZ core in v2 patch.
> > >
> > > And for these HCI events, they are all corresponding to vendor ACL data,
> > > applied only to firmware setup packets, but they're not being sent via
> > > BlueZ core, so they are not being logged in btmon.
> > >
> > > As for its event, where heading 0xe4 refers to a vendor event and is used
> > > on notification of that either vendor ACL data or vendor HCI command have
> > > been done.
> >
> > I would prefer if everything goes via the Bluetooth core since then we have
> > it all properly scheduled. Sending things down the ACL data path however if
> > kinda funky. Does your hardware accept sending command both via ACL data
> > and as HCI command? If so, then I would prefer sending them as HCI commands
> > since the speed improvement you think you are getting is neglectable on
> > Linux (I have been down that path). This seems to be a pure optimization
> > when Windows is driving the device.
> >
>
> firmware people said the device can support firmware download as HCI
> commands. According to my test, this way indeed works so I will improve the
> part in the next version.
>
>
> > And the vendor event 0xe4 is really only received during firmware download?
> > It is not ever received during normal operation?
> >
>
> 0xe4 is only received during chip initialization.
>
> I also thought 0xe4 is a poor definition for vendor event and already have
> notified firmware people should pick 0xff as its vendor event id in the
> future.
>
> but for now, unfortunately, 0xe4 cannot be changed on the device, the only
> way is to add a workaround in RX path as below to allow btmon can recognize
> these bad events properly.
>
> int mtk_btuart_hci_frame(struct hci_dev *hdev, struct sk_buff *skb)
> {
> struct hci_event_hdr *hdr = (void
Re: [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
On Tue, 2018-06-12 at 17:58 +0800, Sean Wang wrote:
> On Wed, 2018-05-30 at 08:26 +0200, Marcel Holtmann wrote:
> > Hi Sean,
> >
> > >>
>
> [ ... ]
>
> > >>> * Unknown packet (code 14 len 30)
> > >>> 0.641509
> > >>> 01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..bl
> > >>> 75 65 74 6f 6f 74 68 64 00 00 00 00 00 00uetoothd..
> > >>> * Unknown packet (code 14 len 30)
> > >>> 0.641592
> > >>> 02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..bt
> > >>> 6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00mon...
> > >>> * Unknown packet (code 16 len 7)[hci0]
> > >>> 6.536771
> > >>> 01 00 00 00 05 00 01 ...
> > >>> = Open Index: 00:00:46:76:22:01 [hci0]
> > >>> 6.717019
> > >>> = Index Info: 00:00:46:76:22:01 (MediaTek, Inc.)[hci0]
> > >>> 6.717030
> > >>
> > >> can you try with the latest BlueZ 5.49 or git version. Seems it actually
> > >> stumbles over the extra packet here. Fun fact is that I can not get a
> > >> backtrace to pin-point the issue in btmon and why it crashes.
> > >>
> > >
> > > I had less experience updating user land BlueZ, but I can try it as
> > > possible and see whether Unknown packets still are present at newest
> > > version BlueZ. Hopefully I don't misunderstand your point here.
> >
> > please use the latest btmon and check if it can read your trace.
> >
>
> sure, I'll have a try with the latest btmon.
I use the btmon version 5.50 and it can read the trace
>
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.741093
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.742088
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.743102
> > >>> 02 01 01 00 00 .
>
>
> [ ... ]
>
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.814708
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.815705
> > >>> 02 01 01 00 00 .
> > HCI Event: Unknown (0xe4) plen 5 [hci0]
> > 6.816378
> > >>> 02 01 01 00 00 .
> > >>
> > >> Why do I see only HCI events here? Is this event conveying any useful
> > >> information. It is kinda complicated that this is 0xe4 event code which
> > >> is actually reserved for future use by the Bluetooth SIG. Are there any
> > >> accompanying HCI commands for this and they just not make it into btmon?
> > >>
> > >
> > > I have made all vendor HCI commands go through BlueZ core in v2 patch.
> > >
> > > And for these HCI events, they are all corresponding to vendor ACL data,
> > > applied only to firmware setup packets, but they're not being sent via
> > > BlueZ core, so they are not being logged in btmon.
> > >
> > > As for its event, where heading 0xe4 refers to a vendor event and is used
> > > on notification of that either vendor ACL data or vendor HCI command have
> > > been done.
> >
> > I would prefer if everything goes via the Bluetooth core since then we have
> > it all properly scheduled. Sending things down the ACL data path however if
> > kinda funky. Does your hardware accept sending command both via ACL data
> > and as HCI command? If so, then I would prefer sending them as HCI commands
> > since the speed improvement you think you are getting is neglectable on
> > Linux (I have been down that path). This seems to be a pure optimization
> > when Windows is driving the device.
> >
>
> firmware people said the device can support firmware download as HCI
> commands. According to my test, this way indeed works so I will improve the
> part in the next version.
>
>
> > And the vendor event 0xe4 is really only received during firmware download?
> > It is not ever received during normal operation?
> >
>
> 0xe4 is only received during chip initialization.
>
> I also thought 0xe4 is a poor definition for vendor event and already have
> notified firmware people should pick 0xff as its vendor event id in the
> future.
>
> but for now, unfortunately, 0xe4 cannot be changed on the device, the only
> way is to add a workaround in RX path as below to allow btmon can recognize
> these bad events properly.
>
> int mtk_btuart_hci_frame(struct hci_dev *hdev, struct sk_buff *skb)
> {
> struct hci_event_hdr *hdr = (void
Re: [PATCH v3 0/6] add virt-dma support for imx-sdma
Hi Lucas, I have identified the root cause besides the lockdep issue. Will contain the UART patch into my next v4 patchset. Hi Sascha, Will address your comments in v4 too. Thank you both input. On 三, 2018-06-13 at 18:07 +0200, Lucas Stach wrote: > Hi Robin, > > Am Dienstag, den 12.06.2018, 08:58 + schrieb Robin Gong: > > > > Hi Lucas, > > Is the below DEAD LOCK issue same as your side? If yes, then > > I'm afraid that we have to make another patch for uart to split dma > > functions in uart driver out of the code area which protected by > > port.lock. The warning make sense since allocate sdma bd memory > > dynamically in virt-dma instead of static allocated as before. I'll > > make another uart patch into my next version patchset. > Yes, I see the same lockdep splat on my system. Though I'm not sure > if > this is really the root cause of the issue I see. > > I'm getting timeouts for a serdev attached device and I don't think > this system ever enters memory reclaim, so the issue reported by > lockdep seems to be a mostly theoretical on this system. But lets see > how far I get when you fixed this issue, maybe the real bug is hiding > behind this one. > > Regards, > Lucas
Re: [PATCH v3 0/6] add virt-dma support for imx-sdma
Hi Lucas, I have identified the root cause besides the lockdep issue. Will contain the UART patch into my next v4 patchset. Hi Sascha, Will address your comments in v4 too. Thank you both input. On 三, 2018-06-13 at 18:07 +0200, Lucas Stach wrote: > Hi Robin, > > Am Dienstag, den 12.06.2018, 08:58 + schrieb Robin Gong: > > > > Hi Lucas, > > Is the below DEAD LOCK issue same as your side? If yes, then > > I'm afraid that we have to make another patch for uart to split dma > > functions in uart driver out of the code area which protected by > > port.lock. The warning make sense since allocate sdma bd memory > > dynamically in virt-dma instead of static allocated as before. I'll > > make another uart patch into my next version patchset. > Yes, I see the same lockdep splat on my system. Though I'm not sure > if > this is really the root cause of the issue I see. > > I'm getting timeouts for a serdev attached device and I don't think > this system ever enters memory reclaim, so the issue reported by > lockdep seems to be a mostly theoretical on this system. But lets see > how far I get when you fixed this issue, maybe the real bug is hiding > behind this one. > > Regards, > Lucas
linux-next: Tree for Jun 14
Hi all, Note: please do *not* add any v4.19 material to your linux-next included branches until after v4.18-rc1 has been released. Changes since 20180613: The cifs tree gained a conflict against Linus' tree. The fbdev tree gained a conflict against Linus' tree. The akpm-current tree gained conflicts against Linus' tree. Non-merge commits (relative to Linus' tree): 873 803 files changed, 16506 insertions(+), 11137 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 278 trees (counting Linus' and 64 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 (be779f03d563 Merge tag 'kbuild-v4.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (c90fca951e90 Merge tag 'powerpc-4.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (82034c23fcbc arm64: Make sure permission updates happen for pmd/pud) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (faf37c44a105 powerpc/64s: Clear PCR on boot) Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (60d061e34703 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging bpf/master (3bce593ac06b selftests: bpf: config: add config fragments) Merging ipsec/master (d6990976af7c vti6: fix PMTU caching and reporting on xmit) Merging netfilter/master (60d061e34703 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (ab1068d6866e iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs) Merging mac80211/master (885892fb378d mlx4_core: restore optimal ICM memory allocation) Merging rdma-fixes/for-rc (3dc7c7badb75 IB/mlx4: Fix an error handling path in 'mlx4_ib_rereg_user_mr()') Merging sound-current/for-linus (d9d5ed1ad5d8 ALSA: usb-audio: Remove explicitly listed Mytek devices) Merging sound-asoc-fixes/for-linus (2858e2cfc2ef Merge branch 'asoc-4.17' into asoc-linus) Merging regmap-fixes/for-linus (97fe106a8027 Merge branch 'regmap-4.17' into regmap-linus) Merging regulator-fixes/for-linus (59ce5f3e5530 Merge branch 'regulator-4.17' into regulator-linus) Merging spi-fixes/for-linus (5d3257b8ea48 Merge branch 'spi-4.17' into spi-linus) Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to pcie_print_link_status() messages) Merging driver-core.current/driver-core-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging tty.current/tty-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging usb.current/usb-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging usb-gadget-fixes/fixes (6d08b06e67cd Linux 4.17-rc2) Merging usb-serial-fixes/usb-linus (75bc37fefc44 Linux 4.17-rc4) Merging usb-ch
linux-next: Tree for Jun 14
Hi all, Note: please do *not* add any v4.19 material to your linux-next included branches until after v4.18-rc1 has been released. Changes since 20180613: The cifs tree gained a conflict against Linus' tree. The fbdev tree gained a conflict against Linus' tree. The akpm-current tree gained conflicts against Linus' tree. Non-merge commits (relative to Linus' tree): 873 803 files changed, 16506 insertions(+), 11137 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 278 trees (counting Linus' and 64 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 (be779f03d563 Merge tag 'kbuild-v4.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (c90fca951e90 Merge tag 'powerpc-4.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (82034c23fcbc arm64: Make sure permission updates happen for pmd/pud) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (faf37c44a105 powerpc/64s: Clear PCR on boot) Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (60d061e34703 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging bpf/master (3bce593ac06b selftests: bpf: config: add config fragments) Merging ipsec/master (d6990976af7c vti6: fix PMTU caching and reporting on xmit) Merging netfilter/master (60d061e34703 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (ab1068d6866e iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs) Merging mac80211/master (885892fb378d mlx4_core: restore optimal ICM memory allocation) Merging rdma-fixes/for-rc (3dc7c7badb75 IB/mlx4: Fix an error handling path in 'mlx4_ib_rereg_user_mr()') Merging sound-current/for-linus (d9d5ed1ad5d8 ALSA: usb-audio: Remove explicitly listed Mytek devices) Merging sound-asoc-fixes/for-linus (2858e2cfc2ef Merge branch 'asoc-4.17' into asoc-linus) Merging regmap-fixes/for-linus (97fe106a8027 Merge branch 'regmap-4.17' into regmap-linus) Merging regulator-fixes/for-linus (59ce5f3e5530 Merge branch 'regulator-4.17' into regulator-linus) Merging spi-fixes/for-linus (5d3257b8ea48 Merge branch 'spi-4.17' into spi-linus) Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to pcie_print_link_status() messages) Merging driver-core.current/driver-core-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging tty.current/tty-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging usb.current/usb-linus (3ca24ce9ff76 Merge branch 'proc-cmdline') Merging usb-gadget-fixes/fixes (6d08b06e67cd Linux 4.17-rc2) Merging usb-serial-fixes/usb-linus (75bc37fefc44 Linux 4.17-rc4) Merging usb-ch
Re: [PATCH 2/2] iio: adc: Add Spreadtrum SC27XX PMICs ADC support
Hi Peter,
On 13 June 2018 at 17:17, Baolin Wang wrote:
> Hi Peter,
>
> On 13 June 2018 at 16:53, Peter Meerwald-Stadler wrote:
>>
>>> From: Freeman Liu
>>
>> some comments below
>>
>>> The Spreadtrum SC27XX PMICs ADC controller contains 32 channels,
>>> which is used to sample voltages with 12 bits conversion.
>>>
>>> Signed-off-by: Freeman Liu
>>> Signed-off-by: Baolin Wang
>>> ---
>>> drivers/iio/adc/Kconfig | 10 +
>>> drivers/iio/adc/Makefile |1 +
>>> drivers/iio/adc/sc27xx_adc.c | 558
>>> ++
>>> 3 files changed, 569 insertions(+)
>>> create mode 100644 drivers/iio/adc/sc27xx_adc.c
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index 9da7907..985b73e 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -621,6 +621,16 @@ config ROCKCHIP_SARADC
>>> To compile this driver as a module, choose M here: the
>>> module will be called rockchip_saradc.
>>>
>>> +config SC27XX_ADC
>>> + tristate "Spreadtrum SC27xx series PMICs ADC"
>>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>>> + help
>>> + Say yes here to build support for the integrated ADC inside the
>>> + Spreadtrum SC27xx series PMICs.
>>> +
>>> + This driver can also be built as a module. If so, the module
>>> + will be called sc27xx_adc.
>>> +
>>> config SPEAR_ADC
>>> tristate "ST SPEAr ADC"
>>> depends on PLAT_SPEAR || COMPILE_TEST
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index 28a9423..03db7b5 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -59,6 +59,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>> obj-$(CONFIG_QCOM_PM8XXX_XOADC) += qcom-pm8xxx-xoadc.o
>>> obj-$(CONFIG_RCAR_GYRO_ADC) += rcar-gyroadc.o
>>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>> +obj-$(CONFIG_SC27XX_ADC) += sc27xx_adc.o
>>> obj-$(CONFIG_SPEAR_ADC) += spear_adc.o
>>> obj-$(CONFIG_STX104) += stx104.o
>>> obj-$(CONFIG_SUN4I_GPADC) += sun4i-gpadc-iio.o
>>> diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
>>> new file mode 100644
>>> index 000..d74310a
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/sc27xx_adc.c
>>> @@ -0,0 +1,558 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +// Copyright (C) 2018 Spreadtrum Communications Inc.
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +/* PMIC global registers definition */
>>> +#define SC27XX_MODULE_EN 0xc08
>>> +#define SC27XX_MODULE_ADC_EN BIT(5)
>>> +#define SC27XX_ARM_CLK_EN0xc10
>>> +#define SC27XX_CLK_ADC_ENBIT(5)
>>> +#define SC27XX_CLK_ADC_CLK_ENBIT(6)
>>> +
>>> +/* ADC controller registers definition */
>>> +#define SC27XX_ADC_CTL 0x0
>>> +#define SC27XX_ADC_CH_CFG0x4
>>> +#define SC27XX_ADC_DATA 0x4c
>>> +#define SC27XX_ADC_INT_EN0x50
>>> +#define SC27XX_ADC_INT_CLR 0x54
>>> +#define SC27XX_ADC_INT_STS 0x58
>>> +#define SC27XX_ADC_INT_RAW 0x5c
>>> +
>>> +/* Bits and mask definition for SC27XX_ADC_CTL register */
>>> +#define SC27XX_ADC_ENBIT(0)
>>> +#define SC27XX_ADC_CHN_RUN BIT(1)
>>> +#define SC27XX_ADC_12BIT_MODEBIT(2)
>>> +#define SC27XX_ADC_RUN_NUM_MASK GENMASK(7, 4)
>>> +#define SC27XX_ADC_RUN_NUM_SHIFT 4
>>> +
>>> +/* Bits and mask definition for SC27XX_ADC_CH_CFG register */
>>> +#define SC27XX_ADC_CHN_ID_MASK GENMASK(4, 0)
>>> +#define SC27XX_ADC_SCALE_MASKGENMASK(10, 8)
>>> +#define SC27XX_ADC_SCALE_SHIFT 8
>>> +
>>> +/* Bits definitions for SC27XX_ADC_INT_EN registers */
>>> +#define SC27XX_ADC_IRQ_ENBIT(0)
>>> +
>>> +/* Bits definitions for SC27XX_ADC_INT_CLR registers */
>>> +#define SC27XX_ADC_IRQ_CLR BIT(0)
>>> +
>>> +/* Mask definition for SC27XX_ADC_DATA register */
>>> +#define SC27XX_ADC_DATA_MASK GENMASK(11, 0)
>>> +
>>> +/* Timeout (ms) for the trylock of hardware spinlocks */
>>> +#define SC27XX_ADC_HWLOCK_TIMEOUT5000
>>> +
>>> +/* Maximum ADC channel number */
>>> +#define SC27XX_ADC_CHANNEL_MAX 32
>>> +
>>> +/* ADC voltage ratio definition */
>>> +#define SC27XX_VOLT_RATIO(n, d) \
>>> + (((n) << SC27XX_RATIO_NUMERATOR_OFFSET) | (d))
>>> +#define SC27XX_RATIO_NUMERATOR_OFFSET16
>>> +#define SC27XX_RATIO_DENOMINATOR_MASKGENMASK(15, 0)
>>> +
>>> +/* Covert ADC values to voltage values */
>>
>> Convert
>
> Sorry for typo and will fix in next version.
>
>>
>>> +#define SC27XX_ADC_TO_VOLTAGE(volt0, volt1, adc0, adc1, value) \
>>
>> I'd rather define a function than a macro for this
>
> Sure.
>
>>
>>> + ({ \
>>> +
Re: [PATCH 2/2] iio: adc: Add Spreadtrum SC27XX PMICs ADC support
Hi Peter,
On 13 June 2018 at 17:17, Baolin Wang wrote:
> Hi Peter,
>
> On 13 June 2018 at 16:53, Peter Meerwald-Stadler wrote:
>>
>>> From: Freeman Liu
>>
>> some comments below
>>
>>> The Spreadtrum SC27XX PMICs ADC controller contains 32 channels,
>>> which is used to sample voltages with 12 bits conversion.
>>>
>>> Signed-off-by: Freeman Liu
>>> Signed-off-by: Baolin Wang
>>> ---
>>> drivers/iio/adc/Kconfig | 10 +
>>> drivers/iio/adc/Makefile |1 +
>>> drivers/iio/adc/sc27xx_adc.c | 558
>>> ++
>>> 3 files changed, 569 insertions(+)
>>> create mode 100644 drivers/iio/adc/sc27xx_adc.c
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index 9da7907..985b73e 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -621,6 +621,16 @@ config ROCKCHIP_SARADC
>>> To compile this driver as a module, choose M here: the
>>> module will be called rockchip_saradc.
>>>
>>> +config SC27XX_ADC
>>> + tristate "Spreadtrum SC27xx series PMICs ADC"
>>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>>> + help
>>> + Say yes here to build support for the integrated ADC inside the
>>> + Spreadtrum SC27xx series PMICs.
>>> +
>>> + This driver can also be built as a module. If so, the module
>>> + will be called sc27xx_adc.
>>> +
>>> config SPEAR_ADC
>>> tristate "ST SPEAr ADC"
>>> depends on PLAT_SPEAR || COMPILE_TEST
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index 28a9423..03db7b5 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -59,6 +59,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>> obj-$(CONFIG_QCOM_PM8XXX_XOADC) += qcom-pm8xxx-xoadc.o
>>> obj-$(CONFIG_RCAR_GYRO_ADC) += rcar-gyroadc.o
>>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>> +obj-$(CONFIG_SC27XX_ADC) += sc27xx_adc.o
>>> obj-$(CONFIG_SPEAR_ADC) += spear_adc.o
>>> obj-$(CONFIG_STX104) += stx104.o
>>> obj-$(CONFIG_SUN4I_GPADC) += sun4i-gpadc-iio.o
>>> diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
>>> new file mode 100644
>>> index 000..d74310a
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/sc27xx_adc.c
>>> @@ -0,0 +1,558 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +// Copyright (C) 2018 Spreadtrum Communications Inc.
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +/* PMIC global registers definition */
>>> +#define SC27XX_MODULE_EN 0xc08
>>> +#define SC27XX_MODULE_ADC_EN BIT(5)
>>> +#define SC27XX_ARM_CLK_EN0xc10
>>> +#define SC27XX_CLK_ADC_ENBIT(5)
>>> +#define SC27XX_CLK_ADC_CLK_ENBIT(6)
>>> +
>>> +/* ADC controller registers definition */
>>> +#define SC27XX_ADC_CTL 0x0
>>> +#define SC27XX_ADC_CH_CFG0x4
>>> +#define SC27XX_ADC_DATA 0x4c
>>> +#define SC27XX_ADC_INT_EN0x50
>>> +#define SC27XX_ADC_INT_CLR 0x54
>>> +#define SC27XX_ADC_INT_STS 0x58
>>> +#define SC27XX_ADC_INT_RAW 0x5c
>>> +
>>> +/* Bits and mask definition for SC27XX_ADC_CTL register */
>>> +#define SC27XX_ADC_ENBIT(0)
>>> +#define SC27XX_ADC_CHN_RUN BIT(1)
>>> +#define SC27XX_ADC_12BIT_MODEBIT(2)
>>> +#define SC27XX_ADC_RUN_NUM_MASK GENMASK(7, 4)
>>> +#define SC27XX_ADC_RUN_NUM_SHIFT 4
>>> +
>>> +/* Bits and mask definition for SC27XX_ADC_CH_CFG register */
>>> +#define SC27XX_ADC_CHN_ID_MASK GENMASK(4, 0)
>>> +#define SC27XX_ADC_SCALE_MASKGENMASK(10, 8)
>>> +#define SC27XX_ADC_SCALE_SHIFT 8
>>> +
>>> +/* Bits definitions for SC27XX_ADC_INT_EN registers */
>>> +#define SC27XX_ADC_IRQ_ENBIT(0)
>>> +
>>> +/* Bits definitions for SC27XX_ADC_INT_CLR registers */
>>> +#define SC27XX_ADC_IRQ_CLR BIT(0)
>>> +
>>> +/* Mask definition for SC27XX_ADC_DATA register */
>>> +#define SC27XX_ADC_DATA_MASK GENMASK(11, 0)
>>> +
>>> +/* Timeout (ms) for the trylock of hardware spinlocks */
>>> +#define SC27XX_ADC_HWLOCK_TIMEOUT5000
>>> +
>>> +/* Maximum ADC channel number */
>>> +#define SC27XX_ADC_CHANNEL_MAX 32
>>> +
>>> +/* ADC voltage ratio definition */
>>> +#define SC27XX_VOLT_RATIO(n, d) \
>>> + (((n) << SC27XX_RATIO_NUMERATOR_OFFSET) | (d))
>>> +#define SC27XX_RATIO_NUMERATOR_OFFSET16
>>> +#define SC27XX_RATIO_DENOMINATOR_MASKGENMASK(15, 0)
>>> +
>>> +/* Covert ADC values to voltage values */
>>
>> Convert
>
> Sorry for typo and will fix in next version.
>
>>
>>> +#define SC27XX_ADC_TO_VOLTAGE(volt0, volt1, adc0, adc1, value) \
>>
>> I'd rather define a function than a macro for this
>
> Sure.
>
>>
>>> + ({ \
>>> +
Re: [PATCH 08/11] staging: lustre: obdclass: move linux/linux-foo.c to foo.c
> As lustre is now linux-only, having this linux sub-directory
> with files named "linux-something" is just noise. Move them
> to a more friendly name.
Reviewed-by: James Simmons
> Signed-off-by: NeilBrown
> ---
> drivers/staging/lustre/lustre/obdclass/Makefile|2
> .../lustre/lustre/obdclass/linux/linux-module.c| 514
>
> .../lustre/lustre/obdclass/linux/linux-sysctl.c| 162 --
> drivers/staging/lustre/lustre/obdclass/module.c| 514
>
> drivers/staging/lustre/lustre/obdclass/sysctl.c| 162 ++
> 5 files changed, 677 insertions(+), 677 deletions(-)
> delete mode 100644
> drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> delete mode 100644
> drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c
> create mode 100644 drivers/staging/lustre/lustre/obdclass/module.c
> create mode 100644 drivers/staging/lustre/lustre/obdclass/sysctl.c
>
> diff --git a/drivers/staging/lustre/lustre/obdclass/Makefile
> b/drivers/staging/lustre/lustre/obdclass/Makefile
> index e3fa9acff4c4..e36ba2167d10 100644
> --- a/drivers/staging/lustre/lustre/obdclass/Makefile
> +++ b/drivers/staging/lustre/lustre/obdclass/Makefile
> @@ -4,7 +4,7 @@ subdir-ccflags-y +=
> -I$(srctree)/drivers/staging/lustre/lustre/include
>
> obj-$(CONFIG_LUSTRE_FS) += obdclass.o
>
> -obdclass-y := linux/linux-module.o linux/linux-sysctl.o \
> +obdclass-y := module.o sysctl.o \
> llog.o llog_cat.o llog_obd.o llog_swab.o class_obd.o debug.o \
> genops.o uuid.o lprocfs_status.o lprocfs_counters.o \
> lustre_handles.o lustre_peer.o statfs_pack.o linkea.o \
> diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> deleted file mode 100644
> index 9c800580053b..
> --- a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> +++ /dev/null
> @@ -1,514 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * GPL HEADER START
> - *
> - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 only,
> - * as published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but
> - * WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> - * General Public License version 2 for more details (a copy is included
> - * in the LICENSE file that accompanied this code).
> - *
> - * You should have received a copy of the GNU General Public License
> - * version 2 along with this program; If not, see
> - * http://www.gnu.org/licenses/gpl-2.0.html
> - *
> - * GPL HEADER END
> - */
> -/*
> - * Copyright (c) 2007, 2010, Oracle and/or its affiliates. All rights
> reserved.
> - * Use is subject to license terms.
> - *
> - * Copyright (c) 2011, 2012, Intel Corporation.
> - */
> -/*
> - * This file is part of Lustre, http://www.lustre.org/
> - * Lustre is a trademark of Sun Microsystems, Inc.
> - *
> - * lustre/obdclass/linux/linux-module.c
> - *
> - * Object Devices Class Driver
> - * These are the only exported functions, they provide some generic
> - * infrastructure for managing object devices
> - */
> -
> -#define DEBUG_SUBSYSTEM S_CLASS
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#define OBD_MAX_IOCTL_BUFFER 8192
> -
> -static int obd_ioctl_is_invalid(struct obd_ioctl_data *data)
> -{
> - if (data->ioc_len > BIT(30)) {
> - CERROR("OBD ioctl: ioc_len larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen1 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen1 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen2 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen2 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen3 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen3 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen4 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen4 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inlbuf1 && data->ioc_inllen1 == 0) {
> - CERROR("OBD ioctl: inlbuf1 pointer but 0 length\n");
> - return 1;
> - }
> -
> - if (data->ioc_inlbuf2 && data->ioc_inllen2 == 0) {
> - CERROR("OBD ioctl: inlbuf2 pointer but 0 length\n");
> -
Re: [PATCH 08/11] staging: lustre: obdclass: move linux/linux-foo.c to foo.c
> As lustre is now linux-only, having this linux sub-directory
> with files named "linux-something" is just noise. Move them
> to a more friendly name.
Reviewed-by: James Simmons
> Signed-off-by: NeilBrown
> ---
> drivers/staging/lustre/lustre/obdclass/Makefile|2
> .../lustre/lustre/obdclass/linux/linux-module.c| 514
>
> .../lustre/lustre/obdclass/linux/linux-sysctl.c| 162 --
> drivers/staging/lustre/lustre/obdclass/module.c| 514
>
> drivers/staging/lustre/lustre/obdclass/sysctl.c| 162 ++
> 5 files changed, 677 insertions(+), 677 deletions(-)
> delete mode 100644
> drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> delete mode 100644
> drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c
> create mode 100644 drivers/staging/lustre/lustre/obdclass/module.c
> create mode 100644 drivers/staging/lustre/lustre/obdclass/sysctl.c
>
> diff --git a/drivers/staging/lustre/lustre/obdclass/Makefile
> b/drivers/staging/lustre/lustre/obdclass/Makefile
> index e3fa9acff4c4..e36ba2167d10 100644
> --- a/drivers/staging/lustre/lustre/obdclass/Makefile
> +++ b/drivers/staging/lustre/lustre/obdclass/Makefile
> @@ -4,7 +4,7 @@ subdir-ccflags-y +=
> -I$(srctree)/drivers/staging/lustre/lustre/include
>
> obj-$(CONFIG_LUSTRE_FS) += obdclass.o
>
> -obdclass-y := linux/linux-module.o linux/linux-sysctl.o \
> +obdclass-y := module.o sysctl.o \
> llog.o llog_cat.o llog_obd.o llog_swab.o class_obd.o debug.o \
> genops.o uuid.o lprocfs_status.o lprocfs_counters.o \
> lustre_handles.o lustre_peer.o statfs_pack.o linkea.o \
> diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> deleted file mode 100644
> index 9c800580053b..
> --- a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
> +++ /dev/null
> @@ -1,514 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * GPL HEADER START
> - *
> - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 only,
> - * as published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but
> - * WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> - * General Public License version 2 for more details (a copy is included
> - * in the LICENSE file that accompanied this code).
> - *
> - * You should have received a copy of the GNU General Public License
> - * version 2 along with this program; If not, see
> - * http://www.gnu.org/licenses/gpl-2.0.html
> - *
> - * GPL HEADER END
> - */
> -/*
> - * Copyright (c) 2007, 2010, Oracle and/or its affiliates. All rights
> reserved.
> - * Use is subject to license terms.
> - *
> - * Copyright (c) 2011, 2012, Intel Corporation.
> - */
> -/*
> - * This file is part of Lustre, http://www.lustre.org/
> - * Lustre is a trademark of Sun Microsystems, Inc.
> - *
> - * lustre/obdclass/linux/linux-module.c
> - *
> - * Object Devices Class Driver
> - * These are the only exported functions, they provide some generic
> - * infrastructure for managing object devices
> - */
> -
> -#define DEBUG_SUBSYSTEM S_CLASS
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#define OBD_MAX_IOCTL_BUFFER 8192
> -
> -static int obd_ioctl_is_invalid(struct obd_ioctl_data *data)
> -{
> - if (data->ioc_len > BIT(30)) {
> - CERROR("OBD ioctl: ioc_len larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen1 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen1 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen2 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen2 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen3 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen3 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inllen4 > BIT(30)) {
> - CERROR("OBD ioctl: ioc_inllen4 larger than 1<<30\n");
> - return 1;
> - }
> -
> - if (data->ioc_inlbuf1 && data->ioc_inllen1 == 0) {
> - CERROR("OBD ioctl: inlbuf1 pointer but 0 length\n");
> - return 1;
> - }
> -
> - if (data->ioc_inlbuf2 && data->ioc_inllen2 == 0) {
> - CERROR("OBD ioctl: inlbuf2 pointer but 0 length\n");
> -
Re: [PATCH 09/11] staging: lustre: discard WIRE_ATTR
> This macro adds nothing of value, and make the code harder
> to read for new readers.
Reviewed-by: James Simmons
> Signed-off-by: NeilBrown
> ---
> .../staging/lustre/include/linux/lnet/socklnd.h|8 ++-
> .../lustre/include/uapi/linux/lnet/lnet-types.h| 28 +---
> .../lustre/include/uapi/linux/lnet/lnetst.h|4 +-
> .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 22 +
> drivers/staging/lustre/lnet/selftest/rpc.h | 48
> ++--
> 5 files changed, 54 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/staging/lustre/include/linux/lnet/socklnd.h
> b/drivers/staging/lustre/include/linux/lnet/socklnd.h
> index 6bd1bca190a3..9f69257e000b 100644
> --- a/drivers/staging/lustre/include/linux/lnet/socklnd.h
> +++ b/drivers/staging/lustre/include/linux/lnet/socklnd.h
> @@ -50,7 +50,7 @@ struct ksock_hello_msg {
> __u32 kshm_ctype; /* connection type */
> __u32 kshm_nips; /* # IP addrs */
> __u32 kshm_ips[0];/* IP addrs */
> -} WIRE_ATTR;
> +} __packed;
>
> struct ksock_lnet_msg {
> struct lnet_hdr ksnm_hdr; /* lnet hdr */
> @@ -61,7 +61,7 @@ struct ksock_lnet_msg {
>* structure definitions. lnet payload will be stored just after
>* the body of structure ksock_lnet_msg_t
>*/
> -} WIRE_ATTR;
> +} __packed;
>
> struct ksock_msg {
> __u32 ksm_type; /* type of socklnd message */
> @@ -71,8 +71,8 @@ struct ksock_msg {
> struct ksock_lnet_msg lnetmsg; /* lnet message, it's empty if
> * it's NOOP
> */
> - } WIRE_ATTR ksm_u;
> -} WIRE_ATTR;
> + } __packed ksm_u;
> +} __packed;
>
> #define KSOCK_MSG_NOOP 0xC0/* ksm_u empty */
> #define KSOCK_MSG_LNET 0xC1/* lnet msg */
> diff --git a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> index 1be9b7aa7326..f97e7d9d881f 100644
> --- a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> +++ b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> @@ -112,14 +112,12 @@ static inline __u32 LNET_MKNET(__u32 type, __u32 num)
> return (type << 16) | num;
> }
>
> -#define WIRE_ATTR__packed
> -
> /* Packed version of lnet_process_id to transfer via network */
> struct lnet_process_id_packed {
> /* node id / process id */
> lnet_nid_t nid;
> lnet_pid_t pid;
> -} WIRE_ATTR;
> +} __packed;
>
> /*
> * The wire handle's interface cookie only matches one network interface in
> @@ -130,7 +128,7 @@ struct lnet_process_id_packed {
> struct lnet_handle_wire {
> __u64 wh_interface_cookie;
> __u64 wh_object_cookie;
> -} WIRE_ATTR;
> +} __packed;
>
> enum lnet_msg_type {
> LNET_MSG_ACK = 0,
> @@ -150,7 +148,7 @@ struct lnet_ack {
> struct lnet_handle_wire dst_wmd;
> __u64 match_bits;
> __u32 mlength;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_put {
> struct lnet_handle_wire ack_wmd;
> @@ -158,7 +156,7 @@ struct lnet_put {
> __u64 hdr_data;
> __u32 ptl_index;
> __u32 offset;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_get {
> struct lnet_handle_wire return_wmd;
> @@ -166,16 +164,16 @@ struct lnet_get {
> __u32 ptl_index;
> __u32 src_offset;
> __u32 sink_length;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_reply {
> struct lnet_handle_wire dst_wmd;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_hello {
> __u64 incarnation;
> __u32 type;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_hdr {
> lnet_nid_t dest_nid;
> @@ -192,7 +190,7 @@ struct lnet_hdr {
> struct lnet_reply reply;
> struct lnet_hello hello;
> } msg;
> -} WIRE_ATTR;
> +} __packed;
>
> /*
> * A HELLO message contains a magic number and protocol version
> @@ -208,7 +206,7 @@ struct lnet_magicversion {
> __u32 magic; /* LNET_PROTO_TCP_MAGIC */
> __u16 version_major; /* increment on incompatible change */
> __u16 version_minor; /* increment on compatible change */
> -} WIRE_ATTR;
> +} __packed;
>
> /* PROTO MAGIC for LNDs */
> #define LNET_PROTO_IB_MAGIC 0x0be91b91
> @@ -232,7 +230,7 @@ struct lnet_acceptor_connreq {
> __u32 acr_magic; /* PTL_ACCEPTOR_PROTO_MAGIC */
> __u32 acr_version;/* protocol version */
> __u64 acr_nid;/* target NID */
> -} WIRE_ATTR;
> +} __packed;
>
> #define LNET_PROTO_ACCEPTOR_VERSION 1
>
> @@ -240,7 +238,7 @@ struct lnet_ni_status {
>
Re: [PATCH 09/11] staging: lustre: discard WIRE_ATTR
> This macro adds nothing of value, and make the code harder
> to read for new readers.
Reviewed-by: James Simmons
> Signed-off-by: NeilBrown
> ---
> .../staging/lustre/include/linux/lnet/socklnd.h|8 ++-
> .../lustre/include/uapi/linux/lnet/lnet-types.h| 28 +---
> .../lustre/include/uapi/linux/lnet/lnetst.h|4 +-
> .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 22 +
> drivers/staging/lustre/lnet/selftest/rpc.h | 48
> ++--
> 5 files changed, 54 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/staging/lustre/include/linux/lnet/socklnd.h
> b/drivers/staging/lustre/include/linux/lnet/socklnd.h
> index 6bd1bca190a3..9f69257e000b 100644
> --- a/drivers/staging/lustre/include/linux/lnet/socklnd.h
> +++ b/drivers/staging/lustre/include/linux/lnet/socklnd.h
> @@ -50,7 +50,7 @@ struct ksock_hello_msg {
> __u32 kshm_ctype; /* connection type */
> __u32 kshm_nips; /* # IP addrs */
> __u32 kshm_ips[0];/* IP addrs */
> -} WIRE_ATTR;
> +} __packed;
>
> struct ksock_lnet_msg {
> struct lnet_hdr ksnm_hdr; /* lnet hdr */
> @@ -61,7 +61,7 @@ struct ksock_lnet_msg {
>* structure definitions. lnet payload will be stored just after
>* the body of structure ksock_lnet_msg_t
>*/
> -} WIRE_ATTR;
> +} __packed;
>
> struct ksock_msg {
> __u32 ksm_type; /* type of socklnd message */
> @@ -71,8 +71,8 @@ struct ksock_msg {
> struct ksock_lnet_msg lnetmsg; /* lnet message, it's empty if
> * it's NOOP
> */
> - } WIRE_ATTR ksm_u;
> -} WIRE_ATTR;
> + } __packed ksm_u;
> +} __packed;
>
> #define KSOCK_MSG_NOOP 0xC0/* ksm_u empty */
> #define KSOCK_MSG_LNET 0xC1/* lnet msg */
> diff --git a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> index 1be9b7aa7326..f97e7d9d881f 100644
> --- a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> +++ b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-types.h
> @@ -112,14 +112,12 @@ static inline __u32 LNET_MKNET(__u32 type, __u32 num)
> return (type << 16) | num;
> }
>
> -#define WIRE_ATTR__packed
> -
> /* Packed version of lnet_process_id to transfer via network */
> struct lnet_process_id_packed {
> /* node id / process id */
> lnet_nid_t nid;
> lnet_pid_t pid;
> -} WIRE_ATTR;
> +} __packed;
>
> /*
> * The wire handle's interface cookie only matches one network interface in
> @@ -130,7 +128,7 @@ struct lnet_process_id_packed {
> struct lnet_handle_wire {
> __u64 wh_interface_cookie;
> __u64 wh_object_cookie;
> -} WIRE_ATTR;
> +} __packed;
>
> enum lnet_msg_type {
> LNET_MSG_ACK = 0,
> @@ -150,7 +148,7 @@ struct lnet_ack {
> struct lnet_handle_wire dst_wmd;
> __u64 match_bits;
> __u32 mlength;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_put {
> struct lnet_handle_wire ack_wmd;
> @@ -158,7 +156,7 @@ struct lnet_put {
> __u64 hdr_data;
> __u32 ptl_index;
> __u32 offset;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_get {
> struct lnet_handle_wire return_wmd;
> @@ -166,16 +164,16 @@ struct lnet_get {
> __u32 ptl_index;
> __u32 src_offset;
> __u32 sink_length;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_reply {
> struct lnet_handle_wire dst_wmd;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_hello {
> __u64 incarnation;
> __u32 type;
> -} WIRE_ATTR;
> +} __packed;
>
> struct lnet_hdr {
> lnet_nid_t dest_nid;
> @@ -192,7 +190,7 @@ struct lnet_hdr {
> struct lnet_reply reply;
> struct lnet_hello hello;
> } msg;
> -} WIRE_ATTR;
> +} __packed;
>
> /*
> * A HELLO message contains a magic number and protocol version
> @@ -208,7 +206,7 @@ struct lnet_magicversion {
> __u32 magic; /* LNET_PROTO_TCP_MAGIC */
> __u16 version_major; /* increment on incompatible change */
> __u16 version_minor; /* increment on compatible change */
> -} WIRE_ATTR;
> +} __packed;
>
> /* PROTO MAGIC for LNDs */
> #define LNET_PROTO_IB_MAGIC 0x0be91b91
> @@ -232,7 +230,7 @@ struct lnet_acceptor_connreq {
> __u32 acr_magic; /* PTL_ACCEPTOR_PROTO_MAGIC */
> __u32 acr_version;/* protocol version */
> __u64 acr_nid;/* target NID */
> -} WIRE_ATTR;
> +} __packed;
>
> #define LNET_PROTO_ACCEPTOR_VERSION 1
>
> @@ -240,7 +238,7 @@ struct lnet_ni_status {
>
Re: [PATCH 07/11] staging: lustre: fold lprocfs_call_handler functionality into lnet_debugfs_*
> The calling convention for ->proc_handler is rather clumsy,
> as a comment in fs/procfs/proc_sysctl.c confirms.
> lustre has copied this convention to lnet_debugfs_{read,write},
> and then provided a wrapper for handlers - lprocfs_call_handler -
> to work around the clumsiness.
>
> It is cleaner to just fold the functionality of lprocfs_call_handler()
> into lnet_debugfs_* and let them call the final handler directly.
>
> If these files were ever moved to /proc/sys (which seems unlikely) the
> handling in fs/procfs/proc_sysctl.c would need to be fixed to, but
> that would not be a bad thing.
>
> So modify all the functions that did use the wrapper to not need it
> now that a more sane calling convention is available.
Reviewed-by: James Simmons
> Signed-off-by: NeilBrown
> ---
> .../staging/lustre/include/linux/libcfs/libcfs.h |4 -
> drivers/staging/lustre/lnet/libcfs/module.c| 84
> +++-
> drivers/staging/lustre/lnet/lnet/router_proc.c | 41 +++---
> 3 files changed, 41 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> index edc7ed0dcb94..7ac609328256 100644
> --- a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> +++ b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> @@ -57,10 +57,6 @@ int libcfs_setup(void);
> extern struct workqueue_struct *cfs_rehash_wq;
>
> void lustre_insert_debugfs(struct ctl_table *table);
> -int lprocfs_call_handler(void *data, int write, loff_t *ppos,
> - void __user *buffer, size_t *lenp,
> - int (*handler)(void *data, int write, loff_t pos,
> - void __user *buffer, int len));
>
> /*
> * Memory
> diff --git a/drivers/staging/lustre/lnet/libcfs/module.c
> b/drivers/staging/lustre/lnet/libcfs/module.c
> index 5dc7de9e6478..02c404c6738e 100644
> --- a/drivers/staging/lustre/lnet/libcfs/module.c
> +++ b/drivers/staging/lustre/lnet/libcfs/module.c
> @@ -290,33 +290,15 @@ static struct miscdevice libcfs_dev = {
>
> static int libcfs_dev_registered;
>
> -int lprocfs_call_handler(void *data, int write, loff_t *ppos,
> - void __user *buffer, size_t *lenp,
> - int (*handler)(void *data, int write, loff_t pos,
> - void __user *buffer, int len))
> -{
> - int rc = handler(data, write, *ppos, buffer, *lenp);
> -
> - if (rc < 0)
> - return rc;
> -
> - if (write) {
> - *ppos += *lenp;
> - } else {
> - *lenp = rc;
> - *ppos += rc;
> - }
> - return 0;
> -}
> -EXPORT_SYMBOL(lprocfs_call_handler);
> -
> -static int __proc_dobitmasks(void *data, int write,
> - loff_t pos, void __user *buffer, int nob)
> +static int proc_dobitmasks(struct ctl_table *table, int write,
> +void __user *buffer, size_t *lenp, loff_t *ppos)
> {
> const int tmpstrlen = 512;
> char *tmpstr;
> int rc;
> - unsigned int *mask = data;
> + size_t nob = *lenp;
> + loff_t pos = *ppos;
> + unsigned int *mask = table->data;
> int is_subsys = (mask == _subsystem_debug) ? 1 : 0;
> int is_printk = (mask == _printk) ? 1 : 0;
>
> @@ -351,32 +333,23 @@ static int __proc_dobitmasks(void *data, int write,
> return rc;
> }
>
> -static int proc_dobitmasks(struct ctl_table *table, int write,
> -void __user *buffer, size_t *lenp, loff_t *ppos)
> +static int proc_dump_kernel(struct ctl_table *table, int write,
> + void __user *buffer, size_t *lenp, loff_t *ppos)
> {
> - return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
> - __proc_dobitmasks);
> -}
> + size_t nob = *lenp;
>
> -static int __proc_dump_kernel(void *data, int write,
> - loff_t pos, void __user *buffer, int nob)
> -{
> if (!write)
> return 0;
>
> return cfs_trace_dump_debug_buffer_usrstr(buffer, nob);
> }
>
> -static int proc_dump_kernel(struct ctl_table *table, int write,
> +static int proc_daemon_file(struct ctl_table *table, int write,
> void __user *buffer, size_t *lenp, loff_t *ppos)
> {
> - return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
> - __proc_dump_kernel);
> -}
> + size_t nob = *lenp;
> + loff_t pos = *ppos;
>
> -static int __proc_daemon_file(void *data, int write,
> - loff_t pos, void __user *buffer, int nob)
> -{
> if (!write) {
> int len = strlen(cfs_tracefile);
>
> @@ -390,13 +363,6 @@ static int __proc_daemon_file(void *data, int write,
> return cfs_trace_daemon_command_usrstr(buffer, nob);
> }
>
> -static int proc_daemon_file(struct
Re: [PATCH 07/11] staging: lustre: fold lprocfs_call_handler functionality into lnet_debugfs_*
> The calling convention for ->proc_handler is rather clumsy,
> as a comment in fs/procfs/proc_sysctl.c confirms.
> lustre has copied this convention to lnet_debugfs_{read,write},
> and then provided a wrapper for handlers - lprocfs_call_handler -
> to work around the clumsiness.
>
> It is cleaner to just fold the functionality of lprocfs_call_handler()
> into lnet_debugfs_* and let them call the final handler directly.
>
> If these files were ever moved to /proc/sys (which seems unlikely) the
> handling in fs/procfs/proc_sysctl.c would need to be fixed to, but
> that would not be a bad thing.
>
> So modify all the functions that did use the wrapper to not need it
> now that a more sane calling convention is available.
Reviewed-by: James Simmons
> Signed-off-by: NeilBrown
> ---
> .../staging/lustre/include/linux/libcfs/libcfs.h |4 -
> drivers/staging/lustre/lnet/libcfs/module.c| 84
> +++-
> drivers/staging/lustre/lnet/lnet/router_proc.c | 41 +++---
> 3 files changed, 41 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> index edc7ed0dcb94..7ac609328256 100644
> --- a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> +++ b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
> @@ -57,10 +57,6 @@ int libcfs_setup(void);
> extern struct workqueue_struct *cfs_rehash_wq;
>
> void lustre_insert_debugfs(struct ctl_table *table);
> -int lprocfs_call_handler(void *data, int write, loff_t *ppos,
> - void __user *buffer, size_t *lenp,
> - int (*handler)(void *data, int write, loff_t pos,
> - void __user *buffer, int len));
>
> /*
> * Memory
> diff --git a/drivers/staging/lustre/lnet/libcfs/module.c
> b/drivers/staging/lustre/lnet/libcfs/module.c
> index 5dc7de9e6478..02c404c6738e 100644
> --- a/drivers/staging/lustre/lnet/libcfs/module.c
> +++ b/drivers/staging/lustre/lnet/libcfs/module.c
> @@ -290,33 +290,15 @@ static struct miscdevice libcfs_dev = {
>
> static int libcfs_dev_registered;
>
> -int lprocfs_call_handler(void *data, int write, loff_t *ppos,
> - void __user *buffer, size_t *lenp,
> - int (*handler)(void *data, int write, loff_t pos,
> - void __user *buffer, int len))
> -{
> - int rc = handler(data, write, *ppos, buffer, *lenp);
> -
> - if (rc < 0)
> - return rc;
> -
> - if (write) {
> - *ppos += *lenp;
> - } else {
> - *lenp = rc;
> - *ppos += rc;
> - }
> - return 0;
> -}
> -EXPORT_SYMBOL(lprocfs_call_handler);
> -
> -static int __proc_dobitmasks(void *data, int write,
> - loff_t pos, void __user *buffer, int nob)
> +static int proc_dobitmasks(struct ctl_table *table, int write,
> +void __user *buffer, size_t *lenp, loff_t *ppos)
> {
> const int tmpstrlen = 512;
> char *tmpstr;
> int rc;
> - unsigned int *mask = data;
> + size_t nob = *lenp;
> + loff_t pos = *ppos;
> + unsigned int *mask = table->data;
> int is_subsys = (mask == _subsystem_debug) ? 1 : 0;
> int is_printk = (mask == _printk) ? 1 : 0;
>
> @@ -351,32 +333,23 @@ static int __proc_dobitmasks(void *data, int write,
> return rc;
> }
>
> -static int proc_dobitmasks(struct ctl_table *table, int write,
> -void __user *buffer, size_t *lenp, loff_t *ppos)
> +static int proc_dump_kernel(struct ctl_table *table, int write,
> + void __user *buffer, size_t *lenp, loff_t *ppos)
> {
> - return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
> - __proc_dobitmasks);
> -}
> + size_t nob = *lenp;
>
> -static int __proc_dump_kernel(void *data, int write,
> - loff_t pos, void __user *buffer, int nob)
> -{
> if (!write)
> return 0;
>
> return cfs_trace_dump_debug_buffer_usrstr(buffer, nob);
> }
>
> -static int proc_dump_kernel(struct ctl_table *table, int write,
> +static int proc_daemon_file(struct ctl_table *table, int write,
> void __user *buffer, size_t *lenp, loff_t *ppos)
> {
> - return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
> - __proc_dump_kernel);
> -}
> + size_t nob = *lenp;
> + loff_t pos = *ppos;
>
> -static int __proc_daemon_file(void *data, int write,
> - loff_t pos, void __user *buffer, int nob)
> -{
> if (!write) {
> int len = strlen(cfs_tracefile);
>
> @@ -390,13 +363,6 @@ static int __proc_daemon_file(void *data, int write,
> return cfs_trace_daemon_command_usrstr(buffer, nob);
> }
>
> -static int proc_daemon_file(struct
Re: [PATCH 4.4 00/24] 4.4.137-stable review
On 13 June 2018 at 18:08, Rafael David Tinoco
wrote:
> On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> wrote:
>> On Wed, Jun 13, 2018 at 05:47:49PM -0300, Rafael Tinoco wrote:
>>> Results from Linaro’s test farm.
>>> Regressions detected.
>>>
>>> NOTE:
>>>
>>> 1) LTP vma03 test (cve-2011-2496) broken on v4.4-137-rc1 because of:
>>>
>>> 6ea1dc96a03a mmap: relax file size limit for regular files
>>> bd2f9ce5bacb mmap: introduce sane default mmap limits
>>>
>>>discussion:
>>>
>>> https://github.com/linux-test-project/ltp/issues/341
>>>
>>>mainline commit (v4.13-rc7):
>>>
>>> 0cc3b0ec23ce Clarify (and fix) MAX_LFS_FILESIZE macros
>>>
>>>should be backported to 4.4.138-rc2 and fixes the issue.
>>
>> Really? That commit says it fixes c2a9737f45e2 ("vfs,mm: fix a dead
>> loop in truncate_inode_pages_range()") which is not in 4.4.y at all.
>>
>> Did you test this out?
>
> Yes, the LTP contains the tests (last comment is the final test for
> arm32, right before Jan tests i686).
>
> Fixing MAX_LFS_FILESIZE fixes the new limit for mmap() brought by
> those 2 commits (file_mmap_size_max()).
> offset tested by the LTP test is 0xfffe000.
> file_mmap_size_max gives: 0x000 as max value, but only after
> the mentioned patch.
>
> Original intent for this fix was other though.
To clarify this a bit further.
The LTP CVE test is breaking in the first call to mmap(), even before
trying to remap and test the security issue. That start happening in
this round because of those mmap() changes and the offset used in the
LTP test. Linus changed limit checks and made them to be related to
MAX_LFS_FILESIZE. Unfortunately, in 4.4 stable, we were missing the
fix for MAX_LFS_FILESIZE (which before commit 0cc3b0ec23ce was less
than the REAL 32 bit limit).
Commit 0cc3b0ec23ce was made because an user noticed the FS limit not
being what it should be. In our case, the 4.4 stable kernel, we are
facing this 32 bit lower limit (than the real 32 bit real limit),
because of the LTP CVE test, so we need this fix to have the real 32
bit limit set for that macro (mmap limits did not use that macro
before).
I have tested in arm32 and Jan Stancek, who first responded to LTP
issue, has tested this in i686 and both worked after that patch was
included to v4.4-137-rc1 (my last test was even with 4.4.138-rc1).
Hope that helps a bit.
Re: [PATCH 4.4 00/24] 4.4.137-stable review
On 13 June 2018 at 18:08, Rafael David Tinoco
wrote:
> On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> wrote:
>> On Wed, Jun 13, 2018 at 05:47:49PM -0300, Rafael Tinoco wrote:
>>> Results from Linaro’s test farm.
>>> Regressions detected.
>>>
>>> NOTE:
>>>
>>> 1) LTP vma03 test (cve-2011-2496) broken on v4.4-137-rc1 because of:
>>>
>>> 6ea1dc96a03a mmap: relax file size limit for regular files
>>> bd2f9ce5bacb mmap: introduce sane default mmap limits
>>>
>>>discussion:
>>>
>>> https://github.com/linux-test-project/ltp/issues/341
>>>
>>>mainline commit (v4.13-rc7):
>>>
>>> 0cc3b0ec23ce Clarify (and fix) MAX_LFS_FILESIZE macros
>>>
>>>should be backported to 4.4.138-rc2 and fixes the issue.
>>
>> Really? That commit says it fixes c2a9737f45e2 ("vfs,mm: fix a dead
>> loop in truncate_inode_pages_range()") which is not in 4.4.y at all.
>>
>> Did you test this out?
>
> Yes, the LTP contains the tests (last comment is the final test for
> arm32, right before Jan tests i686).
>
> Fixing MAX_LFS_FILESIZE fixes the new limit for mmap() brought by
> those 2 commits (file_mmap_size_max()).
> offset tested by the LTP test is 0xfffe000.
> file_mmap_size_max gives: 0x000 as max value, but only after
> the mentioned patch.
>
> Original intent for this fix was other though.
To clarify this a bit further.
The LTP CVE test is breaking in the first call to mmap(), even before
trying to remap and test the security issue. That start happening in
this round because of those mmap() changes and the offset used in the
LTP test. Linus changed limit checks and made them to be related to
MAX_LFS_FILESIZE. Unfortunately, in 4.4 stable, we were missing the
fix for MAX_LFS_FILESIZE (which before commit 0cc3b0ec23ce was less
than the REAL 32 bit limit).
Commit 0cc3b0ec23ce was made because an user noticed the FS limit not
being what it should be. In our case, the 4.4 stable kernel, we are
facing this 32 bit lower limit (than the real 32 bit real limit),
because of the LTP CVE test, so we need this fix to have the real 32
bit limit set for that macro (mmap limits did not use that macro
before).
I have tested in arm32 and Jan Stancek, who first responded to LTP
issue, has tested this in i686 and both worked after that patch was
included to v4.4-137-rc1 (my last test was even with 4.4.138-rc1).
Hope that helps a bit.
linux-next: manual merge of the akpm-current tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
fs/ocfs2/journal.c
between commit:
6396bb221514 ("treewide: kzalloc() -> kcalloc()")
from Linus' tree and commits:
18dc5b7810ff ("ocfs2: without quota support, avoid calling quota recovery")
aa935a9c155b
("ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery-checkpatch-fixes")
from the akpm-current tree.
I fixed it up (the latter akpm-current commit also did the kzalloc to
kcalloc conversion, so I just used that version) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpk9bBQ_v7M9.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
fs/ocfs2/journal.c
between commit:
6396bb221514 ("treewide: kzalloc() -> kcalloc()")
from Linus' tree and commits:
18dc5b7810ff ("ocfs2: without quota support, avoid calling quota recovery")
aa935a9c155b
("ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery-checkpatch-fixes")
from the akpm-current tree.
I fixed it up (the latter akpm-current commit also did the kzalloc to
kcalloc conversion, so I just used that version) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpk9bBQ_v7M9.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
fs/binfmt_elf.c
between commit:
42bc47b35320 ("treewide: Use array_size() in vmalloc()")
from Linus' tree and commit:
1d5239111f52 ("coredump: fix spam with zero VMA process")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/binfmt_elf.c
index 070b6184642d,8676bb01b5a9..
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@@ -2294,8 -2294,8 +2294,8 @@@ static int elf_core_dump(struct coredum
if (segs - 1 > ULONG_MAX / sizeof(*vma_filesz))
goto end_coredump;
- vma_filesz = vmalloc(array_size(sizeof(*vma_filesz), (segs - 1)));
- if (!vma_filesz)
- vma_filesz = kvmalloc((segs - 1) * sizeof(*vma_filesz), GFP_KERNEL);
++ vma_filesz = kvmalloc(array_size(sizeof(*vma_filesz), (segs - 1)),
GFP_KERNEL);
+ if (ZERO_OR_NULL_PTR(vma_filesz))
goto end_coredump;
for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;
pgpx94IIfqTpX.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
fs/binfmt_elf.c
between commit:
42bc47b35320 ("treewide: Use array_size() in vmalloc()")
from Linus' tree and commit:
1d5239111f52 ("coredump: fix spam with zero VMA process")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/binfmt_elf.c
index 070b6184642d,8676bb01b5a9..
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@@ -2294,8 -2294,8 +2294,8 @@@ static int elf_core_dump(struct coredum
if (segs - 1 > ULONG_MAX / sizeof(*vma_filesz))
goto end_coredump;
- vma_filesz = vmalloc(array_size(sizeof(*vma_filesz), (segs - 1)));
- if (!vma_filesz)
- vma_filesz = kvmalloc((segs - 1) * sizeof(*vma_filesz), GFP_KERNEL);
++ vma_filesz = kvmalloc(array_size(sizeof(*vma_filesz), (segs - 1)),
GFP_KERNEL);
+ if (ZERO_OR_NULL_PTR(vma_filesz))
goto end_coredump;
for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;
pgpx94IIfqTpX.pgp
Description: OpenPGP digital signature
[PATCH] selftests: kselftest_harness: return Kselftest Skip code for skipped tests
When a test is skipped because of unmet dependencies and/or unsupported
configuration, kselftest_harness exits with error which is treated as a
fail by the Kselftest framework. This leads to false negative result even
when the test could not be run.
Change it to return kselftest skip code when a test gets skipped to
clearly report that the test could not be run. This change add skip
handling to kselftest_harness with minimal changes adding a new skipped
field to struct __test_metadata and using it to recognize KSFT_SKIP exit
from the test function (t->fn) to __run_test() to the test_harness_run()
to return the right skip code to Kselftest framework.
Kselftest framework SKIP code is 4 and the framework prints appropriate
messages to indicate that the test is skipped.
This change is tested on uevent test and the results are as follows:
Before:
TAP version 13
selftests: uevent: uevent_filtering
[==] Running 1 tests from 1 test cases.
[ RUN ] global.uevent_filtering
uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
root privileges. Skipping test
global.uevent_filtering: Test skipped at step #4
[ FAIL ] global.uevent_filtering
[==] 0 / 1 tests passed.
[ FAILED ]
not ok 1..1 selftests: uevent: uevent_filtering [FAIL]
After:
TAP version 13
selftests: uevent: uevent_filtering
[==] Running 1 tests from 1 test cases.
[ RUN ] global.uevent_filtering
uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
root privileges. Skipping test
global.uevent_filtering: Test skipped at step #4
[ SKIP ] global.uevent_filtering
not ok 1..1 selftests: uevent: uevent_filtering [SKIP]
Signed-off-by: Shuah Khan (Samsung OSG)
---
tools/testing/selftests/kselftest_harness.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kselftest_harness.h
b/tools/testing/selftests/kselftest_harness.h
index 6ae3730c4ee3..7af9ab97b367 100644
--- a/tools/testing/selftests/kselftest_harness.h
+++ b/tools/testing/selftests/kselftest_harness.h
@@ -631,6 +631,7 @@ struct __test_metadata {
void (*fn)(struct __test_metadata *);
int termsig;
int passed;
+ int skipped;
int trigger; /* extra handler after the evaluation */
__u8 step;
bool no_print; /* manual trigger when TH_LOG_STREAM is not available */
@@ -694,6 +695,7 @@ void __run_test(struct __test_metadata *t)
int status;
t->passed = 1;
+ t->skipped = 0;
t->trigger = 0;
printf("[ RUN ] %s\n", t->name);
child_pid = fork();
@@ -716,9 +718,12 @@ void __run_test(struct __test_metadata *t)
t->name,
WEXITSTATUS(status));
} else if (!t->passed) {
+ if (WEXITSTATUS(status) == KSFT_SKIP)
+ t->skipped = 1;
fprintf(TH_LOG_STREAM,
- "%s: Test failed at step #%d\n",
+ "%s: Test %s at step #%d\n",
t->name,
+ (t->skipped ? "skipped" : "failed"),
WEXITSTATUS(status));
}
} else if (WIFSIGNALED(status)) {
@@ -743,7 +748,11 @@ void __run_test(struct __test_metadata *t)
status);
}
}
- printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"), t->name);
+ if (t->skipped)
+ printf("[ %4s ] %s\n", "SKIP", t->name);
+ else
+ printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"),
+ t->name);
}
static int test_harness_run(int __attribute__((unused)) argc,
@@ -762,6 +771,8 @@ static int test_harness_run(int __attribute__((unused))
argc,
__run_test(t);
if (t->passed)
pass_count++;
+ else if (t->skipped)
+ return KSFT_SKIP;
else
ret = 1;
}
--
2.17.0
[PATCH] selftests: kselftest_harness: return Kselftest Skip code for skipped tests
When a test is skipped because of unmet dependencies and/or unsupported
configuration, kselftest_harness exits with error which is treated as a
fail by the Kselftest framework. This leads to false negative result even
when the test could not be run.
Change it to return kselftest skip code when a test gets skipped to
clearly report that the test could not be run. This change add skip
handling to kselftest_harness with minimal changes adding a new skipped
field to struct __test_metadata and using it to recognize KSFT_SKIP exit
from the test function (t->fn) to __run_test() to the test_harness_run()
to return the right skip code to Kselftest framework.
Kselftest framework SKIP code is 4 and the framework prints appropriate
messages to indicate that the test is skipped.
This change is tested on uevent test and the results are as follows:
Before:
TAP version 13
selftests: uevent: uevent_filtering
[==] Running 1 tests from 1 test cases.
[ RUN ] global.uevent_filtering
uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
root privileges. Skipping test
global.uevent_filtering: Test skipped at step #4
[ FAIL ] global.uevent_filtering
[==] 0 / 1 tests passed.
[ FAILED ]
not ok 1..1 selftests: uevent: uevent_filtering [FAIL]
After:
TAP version 13
selftests: uevent: uevent_filtering
[==] Running 1 tests from 1 test cases.
[ RUN ] global.uevent_filtering
uevent_filtering.c:355:global.uevent_filtering:Uevent filtering tests require
root privileges. Skipping test
global.uevent_filtering: Test skipped at step #4
[ SKIP ] global.uevent_filtering
not ok 1..1 selftests: uevent: uevent_filtering [SKIP]
Signed-off-by: Shuah Khan (Samsung OSG)
---
tools/testing/selftests/kselftest_harness.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kselftest_harness.h
b/tools/testing/selftests/kselftest_harness.h
index 6ae3730c4ee3..7af9ab97b367 100644
--- a/tools/testing/selftests/kselftest_harness.h
+++ b/tools/testing/selftests/kselftest_harness.h
@@ -631,6 +631,7 @@ struct __test_metadata {
void (*fn)(struct __test_metadata *);
int termsig;
int passed;
+ int skipped;
int trigger; /* extra handler after the evaluation */
__u8 step;
bool no_print; /* manual trigger when TH_LOG_STREAM is not available */
@@ -694,6 +695,7 @@ void __run_test(struct __test_metadata *t)
int status;
t->passed = 1;
+ t->skipped = 0;
t->trigger = 0;
printf("[ RUN ] %s\n", t->name);
child_pid = fork();
@@ -716,9 +718,12 @@ void __run_test(struct __test_metadata *t)
t->name,
WEXITSTATUS(status));
} else if (!t->passed) {
+ if (WEXITSTATUS(status) == KSFT_SKIP)
+ t->skipped = 1;
fprintf(TH_LOG_STREAM,
- "%s: Test failed at step #%d\n",
+ "%s: Test %s at step #%d\n",
t->name,
+ (t->skipped ? "skipped" : "failed"),
WEXITSTATUS(status));
}
} else if (WIFSIGNALED(status)) {
@@ -743,7 +748,11 @@ void __run_test(struct __test_metadata *t)
status);
}
}
- printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"), t->name);
+ if (t->skipped)
+ printf("[ %4s ] %s\n", "SKIP", t->name);
+ else
+ printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"),
+ t->name);
}
static int test_harness_run(int __attribute__((unused)) argc,
@@ -762,6 +771,8 @@ static int test_harness_run(int __attribute__((unused))
argc,
__run_test(t);
if (t->passed)
pass_count++;
+ else if (t->skipped)
+ return KSFT_SKIP;
else
ret = 1;
}
--
2.17.0
Re: [PATCH 0/3] sched/swait: Convert to full exclusive mode
On Tue, Jun 12, 2018 at 10:34:49AM +0200, Peter Zijlstra wrote: > As mentioned by Linus, swait is exclusive mode and had better behave like it > and be named like it. > > Make it so. Cool! When I tried testing it on x86 against recent mainline, I got: "WARNING: WARNING: Bad or missing .orc_unwind table. Disabling unwinder." But when I tested on recent mainline without your patches: 4597fcff0704 "Merge tag 'for-4.18/dm-changes-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm" I get the same warning. Trying again on today's mainline, but in the meantime, is anyone else seeing this? Thanx, Paul > --- > arch/mips/kvm/mips.c | 4 ++-- > arch/powerpc/kvm/book3s_hv.c | 6 +++--- > arch/s390/kvm/interrupt.c| 2 +- > arch/x86/kernel/kvm.c| 4 ++-- > arch/x86/kvm/lapic.c | 2 +- > include/linux/swait.h| 36 ++-- > kernel/power/suspend.c | 4 ++-- > kernel/rcu/srcutiny.c| 4 ++-- > kernel/rcu/tree.c| 8 > kernel/rcu/tree_exp.h| 4 ++-- > kernel/rcu/tree_plugin.h | 12 ++-- > kernel/sched/swait.c | 32 ++-- > virt/kvm/arm/arm.c | 4 ++-- > virt/kvm/arm/psci.c | 2 +- > virt/kvm/async_pf.c | 2 +- > virt/kvm/kvm_main.c | 4 ++-- > 16 files changed, 71 insertions(+), 59 deletions(-) > >
Re: [PATCH 0/3] sched/swait: Convert to full exclusive mode
On Tue, Jun 12, 2018 at 10:34:49AM +0200, Peter Zijlstra wrote: > As mentioned by Linus, swait is exclusive mode and had better behave like it > and be named like it. > > Make it so. Cool! When I tried testing it on x86 against recent mainline, I got: "WARNING: WARNING: Bad or missing .orc_unwind table. Disabling unwinder." But when I tested on recent mainline without your patches: 4597fcff0704 "Merge tag 'for-4.18/dm-changes-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm" I get the same warning. Trying again on today's mainline, but in the meantime, is anyone else seeing this? Thanx, Paul > --- > arch/mips/kvm/mips.c | 4 ++-- > arch/powerpc/kvm/book3s_hv.c | 6 +++--- > arch/s390/kvm/interrupt.c| 2 +- > arch/x86/kernel/kvm.c| 4 ++-- > arch/x86/kvm/lapic.c | 2 +- > include/linux/swait.h| 36 ++-- > kernel/power/suspend.c | 4 ++-- > kernel/rcu/srcutiny.c| 4 ++-- > kernel/rcu/tree.c| 8 > kernel/rcu/tree_exp.h| 4 ++-- > kernel/rcu/tree_plugin.h | 12 ++-- > kernel/sched/swait.c | 32 ++-- > virt/kvm/arm/arm.c | 4 ++-- > virt/kvm/arm/psci.c | 2 +- > virt/kvm/async_pf.c | 2 +- > virt/kvm/kvm_main.c | 4 ++-- > 16 files changed, 71 insertions(+), 59 deletions(-) > >
Re: Bug with dwc3 id detect and regulators
Hi Roger, On 2018년 06월 11일 17:53, Roger Quadros wrote: > Chanwoo, > > On 11/06/18 11:33, H. Nikolaus Schaller wrote: >> Hi Tony, >> another bug... >> >> [ 174.540313] BUG: scheduling while atomic: kworker/0:4/1327/0x0002 >> [ 174.547353] Modules linked in: omapdrm drm_kms_helper syscopyarea >> sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks bnep >> bluetooth ecdh_generic usb_f_ecm g_ether usb_f_rndis u_ether libcomposite >> configfs ipv6 arc4 wl18xx wlcore mac80211 panel_boe_w677l >> snd_soc_omap_hdmi_audio snd_soc_dmic cfg80211 dwc3 snd_soc_omap_abe_twl6040 >> snd_soc_twl6040 leds_gpio wwan_on_off connector_hdmi omapdss >> encoder_tpd12s015 cec pwm_omap_dmtimer omapdss_base pwm_bl >> generic_adc_battery ehci_omap wlcore_sdio dwc3_omap bmp280_spi >> snd_soc_ts3a227e crtouch_mt leds_is31fl319x tsc2007 bq2429x_charger >> bq27xxx_battery_i2c bq27xxx_battery ina2xx as5013 tca8418_keypad >> twl6040_vibra palmas_pwrbutton gpio_twl6040 palmas_gpadc usb3503 bmp280_i2c >> bmc150_accel_i2c w2cbw003_bluetooth bmc150_magn_i2c bmp280 bmc150_accel_core >> [ 174.624601] bmc150_magn bno055 industrialio_triggered_buffer kfifo_buf >> industrialio snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap >> snd_pcm_dmaengine [last unloaded: syscopyarea] >> [ 174.642327] CPU: 0 PID: 1327 Comm: kworker/0:4 Tainted: GW >> 4.17.0-letux+ #2408 >> [ 174.651541] Hardware name: Generic OMAP5 (Flattened Device Tree) >> [ 174.658004] Workqueue: events_power_efficient palmas_gpio_id_detect >> [ 174.664780] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [ 174.673109] [] (show_stack) from [] >> (dump_stack+0x7c/0x9c) >> [ 174.680881] [] (dump_stack) from [] >> (__schedule_bug+0x60/0x84) >> [ 174.689006] [] (__schedule_bug) from [] >> (__schedule+0x50/0x694) >> [ 174.697217] [] (__schedule) from [] >> (schedule+0xb0/0xcc) >> [ 174.704790] [] (schedule) from [] >> (schedule_timeout+0x354/0x3d4) >> [ 174.713100] [] (schedule_timeout) from [] >> (wait_for_common+0x118/0x158) >> [ 174.722064] [] (wait_for_common) from [] >> (omap_i2c_xfer+0x354/0x48c) >> [ 174.730749] [] (omap_i2c_xfer) from [] >> (__i2c_transfer+0x238/0x550) >> [ 174.739350] [] (__i2c_transfer) from [] >> (i2c_transfer+0x84/0xb4) >> [ 174.747685] [] (i2c_transfer) from [] >> (bq24296_i2c_reg8_read.constprop.8+0x54/0x64 [bq2429x_charger]) >> [ 174.759465] [] (bq24296_i2c_reg8_read.constprop.8 >> [bq2429x_charger]) from [] (bq24296_update_reg+0x28/0xf8 >> [bq2429x_charger]) >> [ 174.773437] [] (bq24296_update_reg [bq2429x_charger]) from >> [] (_regulator_do_disable+0x100/0x238) >> [ 174.784804] [] (_regulator_do_disable) from [] >> (_regulator_disable+0x88/0x120) >> [ 174.794404] [] (_regulator_disable) from [] >> (regulator_disable+0x30/0x60) >> [ 174.803556] [] (regulator_disable) from [] >> (dwc3_omap_set_mailbox+0x84/0xf8 [dwc3_omap]) >> [ 174.814124] [] (dwc3_omap_set_mailbox [dwc3_omap]) from >> [] (dwc3_omap_id_notifier+0x14/0x1c [dwc3_omap]) >> [ 174.826149] [] (dwc3_omap_id_notifier [dwc3_omap]) from >> [] (notifier_call_chain+0x40/0x68) >> [ 174.836867] [] (notifier_call_chain) from [] >> (raw_notifier_call_chain+0x14/0x1c) >> [ 174.846661] [] (raw_notifier_call_chain) from [] >> (extcon_sync+0x54/0x19c) >> [ 174.855804] [] (extcon_sync) from [] >> (process_one_work+0x244/0x464) >> [ 174.864386] [] (process_one_work) from [] >> (worker_thread+0x2c0/0x3ec) >> [ 174.873156] [] (worker_thread) from [] >> (kthread+0x134/0x150) >> [ 174.881087] [] (kthread) from [] >> (ret_from_fork+0x14/0x2c) >> >> It turns out that extcon_sync() holds a spinlock while sending its notifiers >> and this >> is ending up in our regulator.en/disable() which wants to use blocking i2c. >> >> Do you see similar things on the OMAP5EVM when using OTG mode? >> The Palmas SMPS10 is also handled through i2c. Or is this magically hidden >> by regmap? >> >> Well, as a workaround, I can make the regulator.en/disable() in the bq2429x >> driver >> just trigger a worker, but IMHO it is not expected for regulator ops to be >> spinlock safe. >> >> So I think extcon should not spinlock (which might be against the extcon >> design) or > > I think this something that should be addressed in the Extcon layer. > Do you really need to call the raw_notifier_call_chain() function with > spinlock held in extcon_sync()? > if yes why? To reduce the latency of notification is important of extcon. So, extcon used the spinlock before calling the notifier_call_chain to prevent the scheduled out for a moment. Also, the notifier_call calls the registered notifier function sequentially. It means that if some registered notifier function spends a lot of time, the next registered notifier might receive the notification with a delay. So, extcon used the spinlock. Unitl now, But, as you commented and previously, sometimes it caused the similar issues. (To fix similar issues, the consumer device used the
Re: Bug with dwc3 id detect and regulators
Hi Roger, On 2018년 06월 11일 17:53, Roger Quadros wrote: > Chanwoo, > > On 11/06/18 11:33, H. Nikolaus Schaller wrote: >> Hi Tony, >> another bug... >> >> [ 174.540313] BUG: scheduling while atomic: kworker/0:4/1327/0x0002 >> [ 174.547353] Modules linked in: omapdrm drm_kms_helper syscopyarea >> sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks bnep >> bluetooth ecdh_generic usb_f_ecm g_ether usb_f_rndis u_ether libcomposite >> configfs ipv6 arc4 wl18xx wlcore mac80211 panel_boe_w677l >> snd_soc_omap_hdmi_audio snd_soc_dmic cfg80211 dwc3 snd_soc_omap_abe_twl6040 >> snd_soc_twl6040 leds_gpio wwan_on_off connector_hdmi omapdss >> encoder_tpd12s015 cec pwm_omap_dmtimer omapdss_base pwm_bl >> generic_adc_battery ehci_omap wlcore_sdio dwc3_omap bmp280_spi >> snd_soc_ts3a227e crtouch_mt leds_is31fl319x tsc2007 bq2429x_charger >> bq27xxx_battery_i2c bq27xxx_battery ina2xx as5013 tca8418_keypad >> twl6040_vibra palmas_pwrbutton gpio_twl6040 palmas_gpadc usb3503 bmp280_i2c >> bmc150_accel_i2c w2cbw003_bluetooth bmc150_magn_i2c bmp280 bmc150_accel_core >> [ 174.624601] bmc150_magn bno055 industrialio_triggered_buffer kfifo_buf >> industrialio snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap >> snd_pcm_dmaengine [last unloaded: syscopyarea] >> [ 174.642327] CPU: 0 PID: 1327 Comm: kworker/0:4 Tainted: GW >> 4.17.0-letux+ #2408 >> [ 174.651541] Hardware name: Generic OMAP5 (Flattened Device Tree) >> [ 174.658004] Workqueue: events_power_efficient palmas_gpio_id_detect >> [ 174.664780] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [ 174.673109] [] (show_stack) from [] >> (dump_stack+0x7c/0x9c) >> [ 174.680881] [] (dump_stack) from [] >> (__schedule_bug+0x60/0x84) >> [ 174.689006] [] (__schedule_bug) from [] >> (__schedule+0x50/0x694) >> [ 174.697217] [] (__schedule) from [] >> (schedule+0xb0/0xcc) >> [ 174.704790] [] (schedule) from [] >> (schedule_timeout+0x354/0x3d4) >> [ 174.713100] [] (schedule_timeout) from [] >> (wait_for_common+0x118/0x158) >> [ 174.722064] [] (wait_for_common) from [] >> (omap_i2c_xfer+0x354/0x48c) >> [ 174.730749] [] (omap_i2c_xfer) from [] >> (__i2c_transfer+0x238/0x550) >> [ 174.739350] [] (__i2c_transfer) from [] >> (i2c_transfer+0x84/0xb4) >> [ 174.747685] [] (i2c_transfer) from [] >> (bq24296_i2c_reg8_read.constprop.8+0x54/0x64 [bq2429x_charger]) >> [ 174.759465] [] (bq24296_i2c_reg8_read.constprop.8 >> [bq2429x_charger]) from [] (bq24296_update_reg+0x28/0xf8 >> [bq2429x_charger]) >> [ 174.773437] [] (bq24296_update_reg [bq2429x_charger]) from >> [] (_regulator_do_disable+0x100/0x238) >> [ 174.784804] [] (_regulator_do_disable) from [] >> (_regulator_disable+0x88/0x120) >> [ 174.794404] [] (_regulator_disable) from [] >> (regulator_disable+0x30/0x60) >> [ 174.803556] [] (regulator_disable) from [] >> (dwc3_omap_set_mailbox+0x84/0xf8 [dwc3_omap]) >> [ 174.814124] [] (dwc3_omap_set_mailbox [dwc3_omap]) from >> [] (dwc3_omap_id_notifier+0x14/0x1c [dwc3_omap]) >> [ 174.826149] [] (dwc3_omap_id_notifier [dwc3_omap]) from >> [] (notifier_call_chain+0x40/0x68) >> [ 174.836867] [] (notifier_call_chain) from [] >> (raw_notifier_call_chain+0x14/0x1c) >> [ 174.846661] [] (raw_notifier_call_chain) from [] >> (extcon_sync+0x54/0x19c) >> [ 174.855804] [] (extcon_sync) from [] >> (process_one_work+0x244/0x464) >> [ 174.864386] [] (process_one_work) from [] >> (worker_thread+0x2c0/0x3ec) >> [ 174.873156] [] (worker_thread) from [] >> (kthread+0x134/0x150) >> [ 174.881087] [] (kthread) from [] >> (ret_from_fork+0x14/0x2c) >> >> It turns out that extcon_sync() holds a spinlock while sending its notifiers >> and this >> is ending up in our regulator.en/disable() which wants to use blocking i2c. >> >> Do you see similar things on the OMAP5EVM when using OTG mode? >> The Palmas SMPS10 is also handled through i2c. Or is this magically hidden >> by regmap? >> >> Well, as a workaround, I can make the regulator.en/disable() in the bq2429x >> driver >> just trigger a worker, but IMHO it is not expected for regulator ops to be >> spinlock safe. >> >> So I think extcon should not spinlock (which might be against the extcon >> design) or > > I think this something that should be addressed in the Extcon layer. > Do you really need to call the raw_notifier_call_chain() function with > spinlock held in extcon_sync()? > if yes why? To reduce the latency of notification is important of extcon. So, extcon used the spinlock before calling the notifier_call_chain to prevent the scheduled out for a moment. Also, the notifier_call calls the registered notifier function sequentially. It means that if some registered notifier function spends a lot of time, the next registered notifier might receive the notification with a delay. So, extcon used the spinlock. Unitl now, But, as you commented and previously, sometimes it caused the similar issues. (To fix similar issues, the consumer device used the
Re: [PATCH v6 18/29] fpga: dfl: add fpga manager platform driver for FME
Hi Hao, small nit below, looks good otherwise. On Tue, Jun 12, 2018 at 06:10:32PM +0800, Wu Hao wrote: > This patch adds fpga manager driver for FPGA Management Engine (FME). It > implements fpga_manager_ops for FPGA Partial Reconfiguration function. > > Signed-off-by: Tim Whisonant > Signed-off-by: Enno Luebbers > Signed-off-by: Shiva Rao > Signed-off-by: Christopher Rauer > Signed-off-by: Kang Luwei > Signed-off-by: Xiao Guangrong > Signed-off-by: Wu Hao > Acked-by: Alan Tull > --- > v3: rename driver to dfl-fpga-fme-mgr > implemented status callback for fpga manager > rebased due to fpga api changes > v4: rename to dfl-fme-mgr, and fix SPDX license issue > add pr_credit comments and improve dev_err message > remove interface_id sysfs interface > include dfl-fme-pr.h instead of dfl.h > v5: move related register definition from dfl-fme-pr.h to dfl-fme-mgr.c > use mapped ioaddr passed via pdata for register access. > rebase due to fpga manager API changes. > include header file for readq/writeq. > v6: rebase, fix copyright time and add Acked-by from Alan. > --- > drivers/fpga/Kconfig | 6 + > drivers/fpga/Makefile | 1 + > drivers/fpga/dfl-fme-mgr.c | 334 > + > 3 files changed, 341 insertions(+) > create mode 100644 drivers/fpga/dfl-fme-mgr.c > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > index 45e9220..ca97f3c 100644 > --- a/drivers/fpga/Kconfig > +++ b/drivers/fpga/Kconfig > @@ -156,6 +156,12 @@ config FPGA_DFL_FME > FPGA platform level management features. There shall be 1 FME > per DFL based FPGA device. > > +config FPGA_DFL_FME_MGR > + tristate "FPGA DFL FME Manager Driver" > + depends on FPGA_DFL_FME > + help > + Say Y to enable FPGA Manager driver for FPGA Management Engine. > + > config FPGA_DFL_PCI > tristate "FPGA DFL PCIe Device Driver" > depends on PCI && FPGA_DFL > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile > index fd334d40..23f41b0 100644 > --- a/drivers/fpga/Makefile > +++ b/drivers/fpga/Makefile > @@ -32,6 +32,7 @@ obj-$(CONFIG_OF_FPGA_REGION)+= > of-fpga-region.o > # FPGA Device Feature List Support > obj-$(CONFIG_FPGA_DFL) += dfl.o > obj-$(CONFIG_FPGA_DFL_FME) += dfl-fme.o > +obj-$(CONFIG_FPGA_DFL_FME_MGR) += dfl-fme-mgr.o > > dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o > > diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c > new file mode 100644 > index 000..be0060a > --- /dev/null > +++ b/drivers/fpga/dfl-fme-mgr.c > @@ -0,0 +1,334 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * FPGA Manager Driver for FPGA Management Engine (FME) > + * > + * Copyright (C) 2017-2018 Intel Corporation, Inc. > + * > + * Authors: > + * Kang Luwei > + * Xiao Guangrong > + * Wu Hao > + * Joseph Grecco > + * Enno Luebbers > + * Tim Whisonant > + * Ananda Ravuri > + * Christopher Rauer > + * Henry Mitchel > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#include "dfl-fme-pr.h" > + > +/* FME Partial Reconfiguration Sub Feature Register Set */ > +#define FME_PR_DFH 0x0 > +#define FME_PR_CTRL 0x8 > +#define FME_PR_STS 0x10 > +#define FME_PR_DATA 0x18 > +#define FME_PR_ERR 0x20 > +#define FME_PR_INTFC_ID_H0xA8 > +#define FME_PR_INTFC_ID_L0xB0 > + > +/* FME PR Control Register Bitfield */ > +#define FME_PR_CTRL_PR_RST BIT_ULL(0) /* Reset PR engine */ > +#define FME_PR_CTRL_PR_RSTACKBIT_ULL(4) /* Ack for PR engine reset > */ > +#define FME_PR_CTRL_PR_RGN_IDGENMASK_ULL(9, 7) /* PR Region ID > */ > +#define FME_PR_CTRL_PR_START BIT_ULL(12) /* Start to request PR service */ > +#define FME_PR_CTRL_PR_COMPLETE BIT_ULL(13) /* PR data push completion > */ > + > +/* FME PR Status Register Bitfield */ > +/* Number of available entries in HW queue inside the PR engine. */ > +#define FME_PR_STS_PR_CREDIT GENMASK_ULL(8, 0) > +#define FME_PR_STS_PR_STSBIT_ULL(16) /* PR operation status */ > +#define FME_PR_STS_PR_STS_IDLE 0 > +#define FME_PR_STS_PR_CTRLR_STS GENMASK_ULL(22, 20) /* Controller > status */ > +#define FME_PR_STS_PR_HOST_STS GENMASK_ULL(27, 24) /* PR host > status */ > + > +/* FME PR Data Register Bitfield */ > +/* PR data from the raw-binary file. */ > +#define FME_PR_DATA_PR_DATA_RAW GENMASK_ULL(32, 0) > + > +/* FME PR Error Register */ > +/* PR Operation errors detected. */ > +#define FME_PR_ERR_OPERATION_ERR BIT_ULL(0) > +/* CRC error detected. */ > +#define FME_PR_ERR_CRC_ERR BIT_ULL(1) > +/* Incompatible PR bitstream detected. */ > +#define FME_PR_ERR_INCOMPATIBLE_BS BIT_ULL(2) > +/* PR data push protocol violated. */ > +#define FME_PR_ERR_PROTOCOL_ERR BIT_ULL(3) > +/* PR data fifo overflow error detected */ >
Re: [PATCH v6 18/29] fpga: dfl: add fpga manager platform driver for FME
Hi Hao, small nit below, looks good otherwise. On Tue, Jun 12, 2018 at 06:10:32PM +0800, Wu Hao wrote: > This patch adds fpga manager driver for FPGA Management Engine (FME). It > implements fpga_manager_ops for FPGA Partial Reconfiguration function. > > Signed-off-by: Tim Whisonant > Signed-off-by: Enno Luebbers > Signed-off-by: Shiva Rao > Signed-off-by: Christopher Rauer > Signed-off-by: Kang Luwei > Signed-off-by: Xiao Guangrong > Signed-off-by: Wu Hao > Acked-by: Alan Tull > --- > v3: rename driver to dfl-fpga-fme-mgr > implemented status callback for fpga manager > rebased due to fpga api changes > v4: rename to dfl-fme-mgr, and fix SPDX license issue > add pr_credit comments and improve dev_err message > remove interface_id sysfs interface > include dfl-fme-pr.h instead of dfl.h > v5: move related register definition from dfl-fme-pr.h to dfl-fme-mgr.c > use mapped ioaddr passed via pdata for register access. > rebase due to fpga manager API changes. > include header file for readq/writeq. > v6: rebase, fix copyright time and add Acked-by from Alan. > --- > drivers/fpga/Kconfig | 6 + > drivers/fpga/Makefile | 1 + > drivers/fpga/dfl-fme-mgr.c | 334 > + > 3 files changed, 341 insertions(+) > create mode 100644 drivers/fpga/dfl-fme-mgr.c > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > index 45e9220..ca97f3c 100644 > --- a/drivers/fpga/Kconfig > +++ b/drivers/fpga/Kconfig > @@ -156,6 +156,12 @@ config FPGA_DFL_FME > FPGA platform level management features. There shall be 1 FME > per DFL based FPGA device. > > +config FPGA_DFL_FME_MGR > + tristate "FPGA DFL FME Manager Driver" > + depends on FPGA_DFL_FME > + help > + Say Y to enable FPGA Manager driver for FPGA Management Engine. > + > config FPGA_DFL_PCI > tristate "FPGA DFL PCIe Device Driver" > depends on PCI && FPGA_DFL > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile > index fd334d40..23f41b0 100644 > --- a/drivers/fpga/Makefile > +++ b/drivers/fpga/Makefile > @@ -32,6 +32,7 @@ obj-$(CONFIG_OF_FPGA_REGION)+= > of-fpga-region.o > # FPGA Device Feature List Support > obj-$(CONFIG_FPGA_DFL) += dfl.o > obj-$(CONFIG_FPGA_DFL_FME) += dfl-fme.o > +obj-$(CONFIG_FPGA_DFL_FME_MGR) += dfl-fme-mgr.o > > dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o > > diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c > new file mode 100644 > index 000..be0060a > --- /dev/null > +++ b/drivers/fpga/dfl-fme-mgr.c > @@ -0,0 +1,334 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * FPGA Manager Driver for FPGA Management Engine (FME) > + * > + * Copyright (C) 2017-2018 Intel Corporation, Inc. > + * > + * Authors: > + * Kang Luwei > + * Xiao Guangrong > + * Wu Hao > + * Joseph Grecco > + * Enno Luebbers > + * Tim Whisonant > + * Ananda Ravuri > + * Christopher Rauer > + * Henry Mitchel > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#include "dfl-fme-pr.h" > + > +/* FME Partial Reconfiguration Sub Feature Register Set */ > +#define FME_PR_DFH 0x0 > +#define FME_PR_CTRL 0x8 > +#define FME_PR_STS 0x10 > +#define FME_PR_DATA 0x18 > +#define FME_PR_ERR 0x20 > +#define FME_PR_INTFC_ID_H0xA8 > +#define FME_PR_INTFC_ID_L0xB0 > + > +/* FME PR Control Register Bitfield */ > +#define FME_PR_CTRL_PR_RST BIT_ULL(0) /* Reset PR engine */ > +#define FME_PR_CTRL_PR_RSTACKBIT_ULL(4) /* Ack for PR engine reset > */ > +#define FME_PR_CTRL_PR_RGN_IDGENMASK_ULL(9, 7) /* PR Region ID > */ > +#define FME_PR_CTRL_PR_START BIT_ULL(12) /* Start to request PR service */ > +#define FME_PR_CTRL_PR_COMPLETE BIT_ULL(13) /* PR data push completion > */ > + > +/* FME PR Status Register Bitfield */ > +/* Number of available entries in HW queue inside the PR engine. */ > +#define FME_PR_STS_PR_CREDIT GENMASK_ULL(8, 0) > +#define FME_PR_STS_PR_STSBIT_ULL(16) /* PR operation status */ > +#define FME_PR_STS_PR_STS_IDLE 0 > +#define FME_PR_STS_PR_CTRLR_STS GENMASK_ULL(22, 20) /* Controller > status */ > +#define FME_PR_STS_PR_HOST_STS GENMASK_ULL(27, 24) /* PR host > status */ > + > +/* FME PR Data Register Bitfield */ > +/* PR data from the raw-binary file. */ > +#define FME_PR_DATA_PR_DATA_RAW GENMASK_ULL(32, 0) > + > +/* FME PR Error Register */ > +/* PR Operation errors detected. */ > +#define FME_PR_ERR_OPERATION_ERR BIT_ULL(0) > +/* CRC error detected. */ > +#define FME_PR_ERR_CRC_ERR BIT_ULL(1) > +/* Incompatible PR bitstream detected. */ > +#define FME_PR_ERR_INCOMPATIBLE_BS BIT_ULL(2) > +/* PR data push protocol violated. */ > +#define FME_PR_ERR_PROTOCOL_ERR BIT_ULL(3) > +/* PR data fifo overflow error detected */ >
