Re: [PATCH 0/3] ARM, hexagon, c6x: build: fix usage of CFLAGS_MODULE, LDFLAGS_MODULE

2017-10-15 Thread Masahiro Yamada
2017-10-09 23:35 GMT+09:00 Masahiro Yamada :
> CFLAGS_MODULE, AFLAGS_MODULE, and LDFLAGS_MODULE are supposed
> to be set by users.
>
> In-kernel Makefile must use KBUILD_ prefixed variables.
>
> This is explained in Documentation/kbuild/{kbuild.txt, makefiles.txt}
>
> Most of architectures follow the rule, but I found violations
> in ARM, hexagone, and c6x.
>
> Fix them.
>
>
>
> Masahiro Yamada (3):
>   ARM: add KBUILD_ prefix to CFLAGS_MODULE, LDFLAGS_MODULE
>   hexagon: add KBUILD_ prefix to CFLAGS_MODULE, LDFLAGS_MODULE
>   c6x: add KBUILD_ prefix to CFLAGS_MODULE
>
>  arch/arm/Makefile | 6 +++---
>  arch/c6x/Makefile | 2 +-
>  arch/hexagon/Makefile | 6 +++---
>  3 files changed, 7 insertions(+), 7 deletions(-)
>

Series, applied to linux-kbuild/kbuild.



-- 
Best Regards
Masahiro Yamada


[GIT PULL 3/4] ARM: dts: exynos: Pull for v4.15

2017-10-15 Thread Krzysztof Kozlowski
Hi,

New board and a some improvements/cleanups.

Best regards,
Krzysztof


The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-dt-4.15

for you to fetch changes up to 3991e054832e52119b238b397e5e510d7fee5bb4:

  dt-bindings: samsung: Document binding for new Odroid HC1 board (2017-10-15 
09:31:22 +0200)


Samsung DTS ARM changes for 4.15

1. Add new board: Hardkernel Odroid HC1.
2. Fix incomplete Odroid-XU3/4 thermal-zones definition leading to
   possible overheat if first pair of A7+A15 cores is idle but rest of
   CPUs are busy.
3. Add capacity-dmips-mhz properties for CPUs of octa-core SoCs.
4. Add power button to Odroid XU3/4.
5. Improvements in Gscaler, HDMI and Mixer blocks on Exynos5.
6. Add suspend quirk to DWC3 USB controller to fix enumeration of
   SuperSpeed devices on Odroid XU4.
7. Add HDMI and MHL to Trats2.
8. Cleanups (redundant properties and nodes).


Andrzej Pietrasiewicz (1):
  ARM: dts: exynos: Add dwc3 SUSPHY quirk

Brian Kim (1):
  ARM: dts: exynos: Add power button for Odroid XU3/4

Dietmar Eggemann (2):
  ARM: dts: exynos: add exynos5420 cpu capacity-dmips-mhz information
  ARM: dts: exynos: add exynos5422 cpu capacity-dmips-mhz information

Hoegeun Kwon (2):
  ARM: dts: exynos: Remove the display-timing and delay from Rinato
  ARM: dts: exynos: Use specific compatibles for proper Gscaler limits on 
Exynos5250 and Exynos5420

Krzysztof Kozlowski (1):
  dt-bindings: samsung: Document binding for new Odroid HC1 board

Maciej Purski (1):
  ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board

Marek Szyprowski (7):
  ARM: dts: exynos: Remove redundant interrupt properties in gpio-keys on 
Odroid boards
  ARM: dts: exynos: Move HDMI PHY node from boards to exynos5250.dtsi
  ARM: dts: exynos: Cleanup HDMI DCC definitions on Exynos5250 and 
Exynos542x boards
  ARM: dts: exynos: Add status property to Exynos 5250 HDMI and Mixer nodes
  ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes
  ARM: dts: exynos: Move audio clocks configuration to odroidxu3-audio.dtsi
  ARM: dts: exynos: Add support for Hardkernel's Odroid HC1 board

Willy Wolff (1):
  ARM: dts: exynos: fix incomplete Odroid-XU3/4 thermal-zones definition

 .../bindings/arm/samsung/samsung-boards.txt|   1 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|   2 -
 arch/arm/boot/dts/exynos4412-odroidx.dts   |   2 -
 arch/arm/boot/dts/exynos4412-trats2.dts| 111 
 arch/arm/boot/dts/exynos5250-arndale.dts   |  22 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |  18 +-
 arch/arm/boot/dts/exynos5250-snow-common.dtsi  |  18 +-
 arch/arm/boot/dts/exynos5250-spring.dts|  18 +-
 arch/arm/boot/dts/exynos5250.dtsi  |  18 +-
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  |   4 +
 arch/arm/boot/dts/exynos5420-cpus.dtsi |   8 +
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   4 +
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |   9 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   5 +-
 arch/arm/boot/dts/exynos5422-cpus.dtsi |   8 +
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi  | 443 +
 arch/arm/boot/dts/exynos5422-odroidhc1.dts | 213 ++
 arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi  |  13 +
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 711 -
 arch/arm/boot/dts/exynos54xx.dtsi  |   2 +
 22 files changed, 1110 insertions(+), 543 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos5422-odroid-core.dtsi
 create mode 100644 arch/arm/boot/dts/exynos5422-odroidhc1.dts


[GIT PULL 1/4] ARM: exynos: mach/soc for v4.15

2017-10-15 Thread Krzysztof Kozlowski

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-soc-4.15

for you to fetch changes up to 9e43eca3c87476f75680f472ff3ebcd85f357b86:

  ARM: EXYNOS: Remove Exynos4212 related dead code (2017-10-08 13:52:09 +0200)


Samsung mach/soc changes for v4.15

1. Cleanups for s3c24xx and s3c64xx (memory allocation printks, code
   style).
2. Remove of Exynos4212 related dead code (no more support for this
   SoC).


Marek Szyprowski (1):
  ARM: EXYNOS: Remove Exynos4212 related dead code

Markus Elfring (7):
  ARM: s3c24xx: Remove printk for failed memory allocation in iotiming get
  ARM: s3c24xx: Simplify size used for kzalloc in iotiming get
  ARM: s3c2410: Fix typos in a comments
  ARM: s3c64xx: Remove printk for failed memory allocation in samsung_bl_set
  ARM: s3c64xx: Delete an unnecessary return statement in samsung_bl_set
  ARM: SAMSUNG: Remove printk for failed memory allocation
  ARM: SAMSUNG: Simplify size used for kzalloc

 arch/arm/mach-exynos/Kconfig |  5 -
 arch/arm/mach-exynos/common.h| 11 +--
 arch/arm/mach-exynos/exynos.c|  2 --
 arch/arm/mach-exynos/firmware.c  |  5 -
 arch/arm/mach-exynos/pm.c|  3 +--
 arch/arm/mach-exynos/suspend.c   |  4 
 arch/arm/mach-s3c24xx/iotiming-s3c2410.c |  8 +++-
 arch/arm/mach-s3c24xx/iotiming-s3c2412.c |  8 +++-
 arch/arm/mach-s3c64xx/dev-backlight.c| 10 +++---
 arch/arm/plat-samsung/adc.c  | 12 
 arch/arm/plat-samsung/devs.c | 33 +++-
 arch/arm/plat-samsung/platformdata.c |  4 +---
 12 files changed, 27 insertions(+), 78 deletions(-)


[GIT PULL 0/4] ARM: exynos: Pull for v4.15

2017-10-15 Thread Krzysztof Kozlowski
Hi,

Please find here changes for v4.15. No dependencies, no specific order, nothing
particularly worrying.

I put descriptions of pulls in tag-msg.

Best regards,
Krzysztof



Re: [PATCH v3 0/2] kbuild: Cache exploratory calls to the compiler

2017-10-15 Thread Masahiro Yamada
2017-10-12 1:19 GMT+09:00 Douglas Anderson :
> This two-patch series attempts to speed incremental builds of the
> kernel up by a bit.  How much of a speedup you get depends a lot on
> your environment, specifically the speed of your workstation and how
> fast it takes to invoke the compiler.
>
> In the Chrome OS build environment you get a really big win.  For an
> incremental build (via emerge) I measured a speedup from ~1 minute to
> ~35 seconds.  ...but Chrome OS calls the compiler through a number of
> wrapper scripts and also calls the kernel make at least twice for an
> emerge (during compile stage and install stage), so it's a bit of a
> worst case.
>
> Perhaps a more realistic measure of the speedup others might see is
> running "time make help > /dev/null" outside of the Chrome OS build
> environment on my system.  When I do this I see that it took more than
> 1.0 seconds before and less than 0.2 seconds after.  So presumably
> this has the ability to shave ~0.8 seconds off an incremental build
> for most folks out there.  While 0.8 seconds savings isn't huge, it
> does make incremental builds feel a lot snappier.
>
> Ingo Molnar also did some testing of this in his environment and found
> that an incremental build of his subsystem sped up from ~.44 seconds
> before to ~.15 seconds after.  Clean builds also sped up by a marginal
> amount.  :)
>
> Changes in v3:
> - Rule to prevent make from trying to generate the cache
> - Rule to clean .cache.mk
> - No more doc changes
> - Moved cache stuff below cc-cross-prefix
> - Removed duplicate documentation of try-run (oops)
> - Add Tested-by for Ingo and Guenter since v2 and v3 are very similar
>
> Changes in v2:
> - Abstract at a different level (like shell-cached) per Masahiro Yamada
> - Include ld-version, which I missed the first time
>
> Douglas Anderson (2):
>   kbuild: Add a cache for generated variables
>   kbuild: Cache a few more calls to the compiler
>
>  Makefile   |  5 +--
>  scripts/Kbuild.include | 87 
> ++
>  2 files changed, 76 insertions(+), 16 deletions(-)


Series, applied to linux-kbuild/kbuild.


-- 
Best Regards
Masahiro Yamada


[GIT PULL 4/4] ARM: deffconfig: Pull for v4.15

2017-10-15 Thread Krzysztof Kozlowski

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-defconfig-4.15

for you to fetch changes up to a7620b2dff23409bb5a906e19814021e8dec00e5:

  ARM: multi_v7_defconfig: Enable UAS support for Odroid HC1 board (2017-10-04 
19:20:20 +0200)


Samsung defconfig changes for v4.15

1. Enable USB3503 on multi_v7 for Odroid U3.
2. Enable USB Attached SCSI for Odroid HC1.


Linus Lüssing (1):
  ARM: multi_v7_defconfig: Enable USB3503 driver

Marek Szyprowski (2):
  ARM: exynos_defconfig: Enable UAS support for Odroid HC1 board
  ARM: multi_v7_defconfig: Enable UAS support for Odroid HC1 board

 arch/arm/configs/exynos_defconfig   | 2 +-
 arch/arm/configs/multi_v7_defconfig | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)


[GIT PULL 2/4] soc: samsung: Pull for v4.15

2017-10-15 Thread Krzysztof Kozlowski

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
tags/samsung-drivers-4.15

for you to fetch changes up to c40610198f35e8264f9175dafe74db6288a07eda:

  soc: samsung: Remove Exynos4212 related dead code (2017-10-08 14:17:13 +0200)


Samsung soc drivers changes for v4.15

Remove of Exynos4212 related dead code (no more support for this SoC).


Marek Szyprowski (1):
  soc: samsung: Remove Exynos4212 related dead code

 Documentation/devicetree/bindings/arm/samsung/pmu.txt |  1 -
 drivers/soc/samsung/exynos-pmu.c  |  9 -
 drivers/soc/samsung/exynos-pmu.h  |  2 --
 drivers/soc/samsung/exynos4-pmu.c | 13 ++---
 4 files changed, 2 insertions(+), 23 deletions(-)


Re: [RFC PATCH 3/3] mm/map_contig: Add mmap(MAP_CONTIG) support

2017-10-15 Thread Guy Shattah



On 13/10/2017 19:17, Michal Hocko wrote:

On Fri 13-10-17 10:56:13, Cristopher Lameter wrote:

On Fri, 13 Oct 2017, Michal Hocko wrote:


There is a generic posix interface that could we used for a variety of
specific hardware dependent use cases.

Yes you wrote that already and my counter argument was that this generic
posix interface shouldn't bypass virtual memory abstraction.

It does do that? In what way?

availability of the virtual address space depends on the availability of
the same sized contiguous physical memory range. That sounds like the
abstraction is gone to large part to me.

In what way? userspace users will still be working with virtual memory.




There are numerous RDMA devices that would all need the mmap
implementation. And this covers only the needs of one subsystem. There are
other use cases.

That doesn't prevent providing a library function which could be reused
by all those drivers. Nothing really too much different from
remap_pfn_range.

And then in all the other use cases as well. It would be much easier if
mmap could give you the memory you need instead of havig numerous drivers
improvise on their own. This is in particular also useful
for numerous embedded use cases where you need contiguous memory.

But a generic implementation would have to deal with many issues as
already mentioned. If you make this driver specific you can have access
control based on fd etc... I really fail to see how this is any
different from remap_pfn_range.
Why have several driver specific implementation if you can generalize 
the idea and implement

an already existing POSIX standard?
--
Guy


Re: [PATCH] kbuild: remove KBUILD_SUBDIR_ASFLAGS and KBUILD_SUBDIR_CCFLAGS

2017-10-15 Thread Masahiro Yamada
2017-10-10 20:43 GMT+09:00 Masahiro Yamada :
> Accumulate subdir-{cc,as}flags-y directly to KBUILD_{A,C}FLAGS.
> Remove KBUILD_SUBDIR_{AS,CC}FLAGS.
>
> Signed-off-by: Masahiro Yamada 
> ---
>

Applied to linux-kbuild/kbuild.

Best Regards
Masahiro Yamada


Re: [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

2017-10-15 Thread Geert Uytterhoeven
On Sat, Oct 14, 2017 at 4:14 PM, Russell King - ARM Linux
 wrote:
> On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
>> On Thu, 12 Oct 2017, Russell King - ARM Linux wrote:
>>
>> > On Tue, Oct 10, 2017 at 01:33:25PM -0700, Tony Lindgren wrote:
>> > > * Geert Uytterhoeven  [171003 11:32]:
>> > > > On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven 
>> > > >  wrote:
>> > > > > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven 
>> > > > >  wrote:
>> > > > >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre 
>> > > > >>  wrote:
>> > > > >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
>> > > > >>> Please send it to RMK's patch system.
>> > > > >>
>> > > > >> Done (I hope so ;-)
>> > > > >
>> > > > > Failed. Retrying.
>> > > >
>> > > > Yiha ;-)
>> > > >
>> > > > http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1
>> > >
>> > > This also fixes the spamming I started seeing with next-20171009:
>> > >
>> > > Tested-by: Tony Lindgren 
>> >
>> > It's all nice and good that people are testing this patch, but I can't
>> > apply it to -rc1, nor my "misc" branch.  It appears that this is due
>> > to patches going through other trees.
>> >
>> > Sorry, I can't take this patch.
>>
>> It should go into your devel-testing branch as this must be applied on
>> top of my xip_zdata branch that you merged there.
>
> Thanks, it would've been good to have known that ahead of time.
>
> It's why the patch system has the KernelVersion: tag:
>
>  6. Kernel version.
> On a separate line, add a tag "KernelVersion: " followed by the kernel
> version that the patch was generated against. This should be formatted
> as "KernelVersion: 2.6.0-rmk1"
>
> This is because that information is relevant for knowing where it should
> be applied, and to which branch.  Having it be something else means I
> have to guess, and that can result in the patch being discarded in this
> manner if I don't find where it's supposed to be applied.

That's why we have the standard Fixes tag, which was included
Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")

It's trivial for the repo maintainer to know which branch the fix to apply to,
given the Fixes tag.
It's non-trivial to know the branch for the patch submitter, who is forced to
use a non-standard patch submission system.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v2 1/3] dt-bindings: nvmem: add description for UniPhier eFuse

2017-10-15 Thread Masahiro Yamada
2017-10-14 3:42 GMT+09:00 Rob Herring :
> On Fri, Oct 13, 2017 at 11:04 AM, Masahiro Yamada
>  wrote:
>> Hi Rob,
>>
>>
>> 2017-10-13 22:49 GMT+09:00 Rob Herring :
>>> On Fri, Oct 06, 2017 at 02:02:58PM +0900, Keiji Hayashibara wrote:
 Add uniphier-efuse dt-bindings documentation.

 Signed-off-by: Keiji Hayashibara 
 ---
  .../devicetree/bindings/nvmem/uniphier-efuse.txt   | 49 
 ++
  1 file changed, 49 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt

 diff --git a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt 
 b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
 new file mode 100644
 index 000..1a394e5
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
 @@ -0,0 +1,49 @@
 += UniPhier eFuse device tree bindings =
 +
 +This UniPhier eFuse must be under soc-glue.
 +
 +Required properties:
 +- compatible: should be "socionext,uniphier-efuse"
 +- reg: should contain the register location and length
 +
 += Data cells =
 +Are child nodes of efuse, bindings of which as described in
 +bindings/nvmem/nvmem.txt
 +
 +Example:
 +
 + soc-glue@5f90 {
 + compatible = "socionext,uniphier-ld20-soc-glue-debug",
 +  "simple-mfd";
 + #address-cells = <1>;
 + #size-cells = <1>;
 + ranges = <0x0 0x5f90 0x2000>;
 +
 + efuse@100 {
 + compatible = "socionext,uniphier-efuse";
 + reg = <0x100 0x28>;
 + };
 +
 + efuse@200 {
 + compatible = "socionext,uniphier-efuse";
 + reg = <0x200 0x68>;
 + #address-cells = <1>;
 + #size-cells = <1>;
 +
 + /* Data cells */
 + usb_mon: usb_mon {
>>>
>>> Don't use '_' and needs a unit-address. Build your dtb with W=2 option
>>> and you'll get these warnings.
>>
>>
>> Do you mean "usb_mon: usb-mon@54" ?
>
> Yes.
>
>> DT files in kernel sprinkle tons of warnings even with W=1.
>>
>> I always eliminate W=1, so I agree with "@54".
>>
>> I do not care W=2 much.
>> If you see arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi,
>> yeah, I generally use '-' for node names, but I see some exceptions.
>>
>> You admitted -Wnode_name_chars_strict is "subjective"
>> in commit 8654cb8d0371.
>
> Yes, meaning fixing existing cases is questionable and I'd put doing
> so at a lower priority. I didn't mean it is up to each person to
> decide whether they like to use '_' or not.
>
>> If you are unhappy about it, we can fix,
>> but I am not sure how picky we should be.
>
> Let me put it clearly: Don't add new warnings with W=2.


OK.

usb_mon: usb_mon {

should be fixed.

Srinivas forwarded this to Greg,
but I guess Greg has not applied this yet.

The author can do re-spin,
or a follow-up patch will do if it is too late.



-- 
Best Regards
Masahiro Yamada


RE: [RFC PATCH 3/3] mm/map_contig: Add mmap(MAP_CONTIG) support

2017-10-15 Thread Guy Shattah


On 13/10/2017 19:17, Michal Hocko wrote:
> On Fri 13-10-17 10:56:13, Cristopher Lameter wrote:
>> On Fri, 13 Oct 2017, Michal Hocko wrote:
>>
 There is a generic posix interface that could we used for a variety 
 of specific hardware dependent use cases.
>>> Yes you wrote that already and my counter argument was that this 
>>> generic posix interface shouldn't bypass virtual memory abstraction.
>> It does do that? In what way?
> availability of the virtual address space depends on the availability 
> of the same sized contiguous physical memory range. That sounds like 
> the abstraction is gone to large part to me.

In what way? userspace users will still be working with virtual memory.

>
 There are numerous RDMA devices that would all need the mmap 
 implementation. And this covers only the needs of one subsystem. 
 There are other use cases.
>>> That doesn't prevent providing a library function which could be 
>>> reused by all those drivers. Nothing really too much different from 
>>> remap_pfn_range.
>> And then in all the other use cases as well. It would be much easier 
>> if mmap could give you the memory you need instead of havig numerous 
>> drivers improvise on their own. This is in particular also useful for 
>> numerous embedded use cases where you need contiguous memory.
> But a generic implementation would have to deal with many issues as 
> already mentioned. If you make this driver specific you can have 
> access control based on fd etc... I really fail to see how this is any 
> different from remap_pfn_range.

Why have several driver specific implementation if you can generalize the idea 
and implement an already existing POSIX standard?
--
Guy


Re: [PATCH] ACPI: configfs: make config_item_type const

2017-10-15 Thread kbuild test robot
Hi Bhumika,

[auto build test WARNING on pm/linux-next]
[also build test WARNING on v4.14-rc4 next-20171013]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Bhumika-Goyal/ACPI-configfs-make-config_item_type-const/20171015-153321
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: x86_64-randconfig-x018-201742 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/acpi/acpi_configfs.c: In function 'acpi_table_make_item':
>> drivers/acpi/acpi_configfs.c:222:48: warning: passing argument 3 of 
>> 'config_item_init_type_name' discards 'const' qualifier from pointer target 
>> type [-Wdiscarded-qualifiers]
 config_item_init_type_name(&table->cfg, name, &acpi_table_type);
   ^
   In file included from drivers/acpi/acpi_configfs.c:15:0:
   include/linux/configfs.h:73:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_item_init_type_name(struct config_item *item,
^~
   drivers/acpi/acpi_configfs.c: At top level:
>> drivers/acpi/acpi_configfs.c:253:15: warning: initialization discards 
>> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
   .ci_type = &acpi_root_group_type,
  ^
   drivers/acpi/acpi_configfs.c: In function 'acpi_configfs_init':
>> drivers/acpi/acpi_configfs.c:271:11: warning: passing argument 3 of 
>> 'configfs_register_default_group' discards 'const' qualifier from pointer 
>> target type [-Wdiscarded-qualifiers]
  &acpi_tables_type);
  ^
   In file included from drivers/acpi/acpi_configfs.c:15:0:
   include/linux/configfs.h:262:1: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
configfs_register_default_group(struct config_group *parent_group,
^~~

vim +222 drivers/acpi/acpi_configfs.c

612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  212  
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  213  static 
struct config_item *acpi_table_make_item(struct config_group *group,
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  214  
const char *name)
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  215  {
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  216  
struct acpi_table *table;
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  217  
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  218  
table = kzalloc(sizeof(*table), GFP_KERNEL);
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  219  
if (!table)
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  220  
return ERR_PTR(-ENOMEM);
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  221  
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08 @222  
config_item_init_type_name(&table->cfg, name, &acpi_table_type);
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  223  
return &table->cfg;
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  224  }
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  225  
772bf1e2 drivers/acpi/acpi_configfs.c Jan Kiszka   2017-06-09  226  static 
void acpi_table_drop_item(struct config_group *group,
772bf1e2 drivers/acpi/acpi_configfs.c Jan Kiszka   2017-06-09  227  
 struct config_item *cfg)
772bf1e2 drivers/acpi/acpi_configfs.c Jan Kiszka   2017-06-09  228  {
772bf1e2 drivers/acpi/acpi_configfs.c Jan Kiszka   2017-06-09  229  
struct acpi_table *table = container_of(cfg, struct acpi_table, cfg);
772bf1e2 drivers/acpi/acpi_configfs.c Jan Kiszka   2017-06-09  230  
772bf1e2 drivers/acpi/acpi_configfs.c Jan Kiszka   2017-06-09  231  
ACPI_INFO(("Host-directed Dynamic ACPI Table Unload"));
772bf1e2 drivers/acpi/acpi_configfs.c Jan Kiszka   2017-06-09  232  
acpi_tb_unload_table(table->index);
772bf1e2 drivers/acpi/acpi_configfs.c Jan Kiszka   2017-06-09  233  }
772bf1e2 drivers/acpi/acpi_configfs.c Jan Kiszka   2017-06-09  234  
612bd01f drivers/acpi/configfs.c  Octavian Purdila 2016-07-08  235  struct 
configfs_group_operations acpi_table_group_ops = {
612bd01f drivers

Re: [PATCH v5 02/12] mmc: mediatek: add support of mt2701/mt2712

2017-10-15 Thread CK Hu
Hi, Chaotian:

On Wed, 2017-10-11 at 10:41 +0800, Chaotian Jing wrote:
> mt2701/mt2712 has 12bit clock div, which is not compatible with
> mt8135/mt8173. and, some additional features will be added in
> mt2701/mt2712, so that need distinguish it by comatibale name.
> 
> Signed-off-by: Chaotian Jing 
> ---
>  drivers/mmc/host/mtk-sd.c | 82 
> +++
>  1 file changed, 69 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index 267f7ab..643c795 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -95,6 +95,9 @@
>  #define MSDC_CFG_CKDIV  (0xff << 8)  /* RW */
>  #define MSDC_CFG_CKMOD  (0x3 << 16)  /* RW */
>  #define MSDC_CFG_HS400_CK_MODE  (0x1 << 18)  /* RW */
> +#define MSDC_CFG_HS400_CK_MODE_EXTRA  (0x1 << 22)/* RW */
> +#define MSDC_CFG_CKDIV_EXTRA(0xfff << 8) /* RW */
> +#define MSDC_CFG_CKMOD_EXTRA(0x3 << 20)  /* RW */
>  
>  /* MSDC_IOCON mask */
>  #define MSDC_IOCON_SDR104CKS(0x1 << 0)   /* RW */
> @@ -295,6 +298,10 @@ struct msdc_save_para {
>   u32 emmc50_cfg0;
>  };
>  
> +struct mtk_mmc_compatible {
> + u8 clk_div_bits;
> +};
> +
>  struct msdc_tune_para {
>   u32 iocon;
>   u32 pad_tune;
> @@ -309,6 +316,7 @@ struct msdc_delay_phase {
>  
>  struct msdc_host {
>   struct device *dev;
> + const struct mtk_mmc_compatible *dev_comp;
>   struct mmc_host *mmc;   /* mmc structure */
>   int cmd_rsp;
>  
> @@ -350,6 +358,31 @@ struct msdc_host {
>   struct msdc_tune_para saved_tune_para; /* tune result of CMD21/CMD19 */
>  };
>  
> +static const struct mtk_mmc_compatible mt8135_compat = {
> + .clk_div_bits = 8,
> +};
> +
> +static const struct mtk_mmc_compatible mt8173_compat = {
> + .clk_div_bits = 8,
> +};
> +
> +static const struct mtk_mmc_compatible mt2701_compat = {
> + .clk_div_bits = 12,
> +};
> +
> +static const struct mtk_mmc_compatible mt2712_compat = {
> + .clk_div_bits = 12,
> +};
> +
> +static const struct of_device_id msdc_of_ids[] = {
> + { .compatible = "mediatek,mt8135-mmc", .data = &mt8135_compat},
> + { .compatible = "mediatek,mt8173-mmc", .data = &mt8173_compat},

Because mt8135_compat is equal to mt8173_compat, so I think the
compatible of "mediatek,mt8173-mmc" is redundant. You could just keep
compatible of "mediatek,mt8135-mmc" in driver, and use
"mediatek,mt8135-mmc" for both mt8135.dtsi and mt8173.dtsi.

> + { .compatible = "mediatek,mt2701-mmc", .data = &mt2701_compat},
> + { .compatible = "mediatek,mt2712-mmc", .data = &mt2712_compat},

Ditto.

Regards,
CK

> + {}
> +};
> +MODULE_DEVICE_TABLE(of, msdc_of_ids);
> +
>  static void sdr_set_bits(void __iomem *reg, u32 bs)
>  {
>   u32 val = readl(reg);
> @@ -509,7 +542,12 @@ static void msdc_set_timeout(struct msdc_host *host, u32 
> ns, u32 clks)
>   timeout = (ns + clk_ns - 1) / clk_ns + clks;
>   /* in 1048576 sclk cycle unit */
>   timeout = (timeout + (0x1 << 20) - 1) >> 20;
> - sdr_get_field(host->base + MSDC_CFG, MSDC_CFG_CKMOD, &mode);
> + if (host->dev_comp->clk_div_bits == 8)
> + sdr_get_field(host->base + MSDC_CFG,
> +   MSDC_CFG_CKMOD, &mode);
> + else
> + sdr_get_field(host->base + MSDC_CFG,
> +   MSDC_CFG_CKMOD_EXTRA, &mode);
>   /*DDR mode will double the clk cycles for data timeout */
>   timeout = mode >= 2 ? timeout * 2 : timeout;
>   timeout = timeout > 1 ? timeout - 1 : 0;
> @@ -548,7 +586,11 @@ static void msdc_set_mclk(struct msdc_host *host, 
> unsigned char timing, u32 hz)
>  
>   flags = readl(host->base + MSDC_INTEN);
>   sdr_clr_bits(host->base + MSDC_INTEN, flags);
> - sdr_clr_bits(host->base + MSDC_CFG, MSDC_CFG_HS400_CK_MODE);
> + if (host->dev_comp->clk_div_bits == 8)
> + sdr_clr_bits(host->base + MSDC_CFG, MSDC_CFG_HS400_CK_MODE);
> + else
> + sdr_clr_bits(host->base + MSDC_CFG,
> +  MSDC_CFG_HS400_CK_MODE_EXTRA);
>   if (timing == MMC_TIMING_UHS_DDR50 ||
>   timing == MMC_TIMING_MMC_DDR52 ||
>   timing == MMC_TIMING_MMC_HS400) {
> @@ -568,8 +610,12 @@ static void msdc_set_mclk(struct msdc_host *host, 
> unsigned char timing, u32 hz)
>  
>   if (timing == MMC_TIMING_MMC_HS400 &&
>   hz >= (host->src_clk_freq >> 1)) {
> - sdr_set_bits(host->base + MSDC_CFG,
> -  MSDC_CFG_HS400_CK_MODE);
> + if (host->dev_comp->clk_div_bits == 8)
> + sdr_set_bits(host->base + MSDC_CFG,
> +  MSDC_CFG_HS400_CK_MODE);
> + else
> + sdr_set_bits(host->base + MSDC_CFG,
> +

[PATCH v3 1/2] acpi: apei: remove the unused dead-code for SEA/NMI notification type

2017-10-15 Thread Dongjiu Geng
For the SEA notification, the two functions ghes_sea_add() and
ghes_sea_remove() are only called when CONFIG_ACPI_APEI_SEA
is defined. If not, it will return errors in the ghes_probe()
and not continue. If the probe is failed, the ghes_sea_remove()
also has no chance to be called. Hence, remove the unnecessary
handling when CONFIG_ACPI_APEI_SEA is not defined.

For the NMI notification, it has the same issue as SEA notification,
so also remove the unused dead-code for it.

Cc: Borislav Petkov 
Cc: Tyler Baicar 
Cc: James Morse 
Signed-off-by: Dongjiu Geng 
---
 drivers/acpi/apei/ghes.c | 33 +
 1 file changed, 5 insertions(+), 28 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index d661d45..3eee30a 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -849,17 +849,8 @@ static void ghes_sea_remove(struct ghes *ghes)
synchronize_rcu();
 }
 #else /* CONFIG_ACPI_APEI_SEA */
-static inline void ghes_sea_add(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not 
supported\n",
-  ghes->generic->header.source_id);
-}
-
-static inline void ghes_sea_remove(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not 
supported\n",
-  ghes->generic->header.source_id);
-}
+static inline void ghes_sea_add(struct ghes *ghes) { }
+static inline void ghes_sea_remove(struct ghes *ghes) { }
 #endif /* CONFIG_ACPI_APEI_SEA */
 
 #ifdef CONFIG_HAVE_ACPI_APEI_NMI
@@ -1061,23 +1052,9 @@ static void ghes_nmi_init_cxt(void)
init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
 }
 #else /* CONFIG_HAVE_ACPI_APEI_NMI */
-static inline void ghes_nmi_add(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to add NMI notification which is not 
supported!\n",
-  ghes->generic->header.source_id);
-   BUG();
-}
-
-static inline void ghes_nmi_remove(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to remove NMI notification which is not 
supported!\n",
-  ghes->generic->header.source_id);
-   BUG();
-}
-
-static inline void ghes_nmi_init_cxt(void)
-{
-}
+static inline void ghes_nmi_add(struct ghes *ghes) { }
+static inline void ghes_nmi_remove(struct ghes *ghes) { }
+static inline void ghes_nmi_init_cxt(void) { }
 #endif /* CONFIG_HAVE_ACPI_APEI_NMI */
 
 static int ghes_probe(struct platform_device *ghes_dev)
-- 
2.10.1



[PATCH v3 2/2] acpi: apei: Add SEI notification type support for ARMv8

2017-10-15 Thread Dongjiu Geng
ARMv8.2 requires implementation of the RAS extension, in
this extension it adds SEI(SError Interrupt) notification
type, this patch adds new GHES error source SEI handling
functions. Because this error source parsing and handling
methods are similar with the SEA. So share some SEA handling
functions with the SEI

Expose one API ghes_notify_abort() to external users. External
modules can call this exposed API to parse and handle the
SEA or SEI.

Note: For the SEI(SError Interrupt), it is asynchronous external
abort, the error address recorded by firmware may be not accurate.
If not accurate, EL3 firmware needs to identify the address to a
invalid value.

Cc: Borislav Petkov 
Cc: James Morse 
Signed-off-by: Dongjiu Geng 
Tested-by: Tyler Baicar 
Tested-by: Dongjiu Geng 
---
 arch/arm64/mm/fault.c |  4 +--
 drivers/acpi/apei/Kconfig | 15 +++
 drivers/acpi/apei/ghes.c  | 63 ---
 include/acpi/ghes.h   |  2 +-
 4 files changed, 66 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 2509e4f..c98c1b3 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -585,7 +585,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
if (interrupts_enabled(regs))
nmi_enter();
 
-   ret = ghes_notify_sea();
+   ret = ghes_notify_abort(ACPI_HEST_NOTIFY_SEA);
 
if (interrupts_enabled(regs))
nmi_exit();
@@ -682,7 +682,7 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr)
int ret = -ENOENT;
 
if (IS_ENABLED(CONFIG_ACPI_APEI_SEA))
-   ret = ghes_notify_sea();
+   ret = ghes_notify_abort(ACPI_HEST_NOTIFY_SEA);
 
return ret;
 }
diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index de14d49..47fcb0c 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -54,6 +54,21 @@ config ACPI_APEI_SEA
  option allows the OS to look for such hardware error record, and
  take appropriate action.
 
+config ACPI_APEI_SEI
+   bool "APEI Asynchronous SError Interrupt logging/recovering support"
+   depends on ARM64 && ACPI_APEI_GHES
+   default y
+   help
+ This option should be enabled if the system supports
+ firmware first handling of SEI (asynchronous SError interrupt).
+
+ SEI happens with asynchronous external abort for errors on device
+ memory reads on ARMv8 systems. If a system supports firmware first
+ handling of SEI, the platform analyzes and handles hardware error
+ notifications from SEI, and it may then form a HW error record for
+ the OS to parse and handle. This option allows the OS to look for
+ such hardware error record, and take appropriate action.
+
 config ACPI_APEI_MEMORY_FAILURE
bool "APEI memory error recovering support"
depends on ACPI_APEI && MEMORY_FAILURE
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 3eee30a..66a2953 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -815,33 +815,57 @@ static struct notifier_block ghes_notifier_hed = {
 
 #ifdef CONFIG_ACPI_APEI_SEA
 static LIST_HEAD(ghes_sea);
+#endif
+
+#ifdef CONFIG_ACPI_APEI_SEI
+static LIST_HEAD(ghes_sei);
+#endif
 
+#if defined(CONFIG_ACPI_APEI_SEA) || defined(CONFIG_ACPI_APEI_SEI)
 /*
- * Return 0 only if one of the SEA error sources successfully reported an error
- * record sent from the firmware.
+ * Return 0 only if one of the SEA or SEI error sources successfully
+ * reported an error record sent from the firmware.
  */
-int ghes_notify_sea(void)
+int ghes_notify_abort(u8 type)
 {
struct ghes *ghes;
+   struct list_head *head = NULL;
int ret = -ENOENT;
 
-   rcu_read_lock();
-   list_for_each_entry_rcu(ghes, &ghes_sea, list) {
-   if (!ghes_proc(ghes))
-   ret = 0;
+   if (type == ACPI_HEST_NOTIFY_SEA)
+   head = &ghes_sea;
+   else if (type == ACPI_HEST_NOTIFY_SEI)
+   head = &ghes_sei;
+
+   if (head) {
+   rcu_read_lock();
+   list_for_each_entry_rcu(ghes, head, list) {
+   if (!ghes_proc(ghes))
+   ret = 0;
+   }
+   rcu_read_unlock();
}
-   rcu_read_unlock();
return ret;
 }
 
-static void ghes_sea_add(struct ghes *ghes)
+static void ghes_abort_add(struct ghes *ghes)
 {
-   mutex_lock(&ghes_list_mutex);
-   list_add_rcu(&ghes->list, &ghes_sea);
-   mutex_unlock(&ghes_list_mutex);
+   struct list_head *head = NULL;
+   u8 notify_type = ghes->generic->notify.type;
+
+   if (notify_type == ACPI_HEST_NOTIFY_SEA)
+   head = &ghes_sea;
+   else if (notify_type == ACPI_HEST_NOTIFY_SEI)
+   head = &ghes_sei;
+
+   

[PATCH v4 1/2] acpi: apei: remove the unused dead-code for SEA/NMI notification type

2017-10-15 Thread Dongjiu Geng
For the SEA notification, the two functions ghes_sea_add() and
ghes_sea_remove() are only called when CONFIG_ACPI_APEI_SEA
is defined. If not, it will return errors in the ghes_probe()
and not continue. If the probe is failed, the ghes_sea_remove()
also has no chance to be called. Hence, remove the unnecessary
handling when CONFIG_ACPI_APEI_SEA is not defined.

For the NMI notification, it has the same issue as SEA notification,
so also remove the unused dead-code for it.

Cc: Borislav Petkov 
Cc: Tyler Baicar 
Cc: James Morse 
Signed-off-by: Dongjiu Geng 
---
 drivers/acpi/apei/ghes.c | 33 +
 1 file changed, 5 insertions(+), 28 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index d661d45..3eee30a 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -849,17 +849,8 @@ static void ghes_sea_remove(struct ghes *ghes)
synchronize_rcu();
 }
 #else /* CONFIG_ACPI_APEI_SEA */
-static inline void ghes_sea_add(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not 
supported\n",
-  ghes->generic->header.source_id);
-}
-
-static inline void ghes_sea_remove(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not 
supported\n",
-  ghes->generic->header.source_id);
-}
+static inline void ghes_sea_add(struct ghes *ghes) { }
+static inline void ghes_sea_remove(struct ghes *ghes) { }
 #endif /* CONFIG_ACPI_APEI_SEA */
 
 #ifdef CONFIG_HAVE_ACPI_APEI_NMI
@@ -1061,23 +1052,9 @@ static void ghes_nmi_init_cxt(void)
init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
 }
 #else /* CONFIG_HAVE_ACPI_APEI_NMI */
-static inline void ghes_nmi_add(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to add NMI notification which is not 
supported!\n",
-  ghes->generic->header.source_id);
-   BUG();
-}
-
-static inline void ghes_nmi_remove(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to remove NMI notification which is not 
supported!\n",
-  ghes->generic->header.source_id);
-   BUG();
-}
-
-static inline void ghes_nmi_init_cxt(void)
-{
-}
+static inline void ghes_nmi_add(struct ghes *ghes) { }
+static inline void ghes_nmi_remove(struct ghes *ghes) { }
+static inline void ghes_nmi_init_cxt(void) { }
 #endif /* CONFIG_HAVE_ACPI_APEI_NMI */
 
 static int ghes_probe(struct platform_device *ghes_dev)
-- 
2.10.1



[PATCH v4 2/2] acpi: apei: Add SEI notification type support for ARMv8

2017-10-15 Thread Dongjiu Geng
ARMv8.2 requires implementation of the RAS extension, in
this extension it adds SEI(SError Interrupt) notification
type, this patch adds new GHES error source SEI handling
functions. Because this error source parsing and handling
methods are similar with the SEA. So share some SEA handling
functions with the SEI

Expose one API ghes_notify_abort() to external users. External
modules can call this exposed API to parse and handle the
SEA or SEI.

Note: For the SEI(SError Interrupt), it is asynchronous external
abort, the error address recorded by firmware may be not accurate.
If not accurate, EL3 firmware needs to identify the address to a
invalid value.

Cc: Borislav Petkov 
Cc: James Morse 
Signed-off-by: Dongjiu Geng 
Tested-by: Tyler Baicar 
Tested-by: Dongjiu Geng 
---
 arch/arm64/mm/fault.c |  4 +--
 drivers/acpi/apei/Kconfig | 15 +++
 drivers/acpi/apei/ghes.c  | 63 ---
 include/acpi/ghes.h   |  2 +-
 4 files changed, 66 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 2509e4f..c98c1b3 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -585,7 +585,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
if (interrupts_enabled(regs))
nmi_enter();
 
-   ret = ghes_notify_sea();
+   ret = ghes_notify_abort(ACPI_HEST_NOTIFY_SEA);
 
if (interrupts_enabled(regs))
nmi_exit();
@@ -682,7 +682,7 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr)
int ret = -ENOENT;
 
if (IS_ENABLED(CONFIG_ACPI_APEI_SEA))
-   ret = ghes_notify_sea();
+   ret = ghes_notify_abort(ACPI_HEST_NOTIFY_SEA);
 
return ret;
 }
diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index de14d49..47fcb0c 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -54,6 +54,21 @@ config ACPI_APEI_SEA
  option allows the OS to look for such hardware error record, and
  take appropriate action.
 
+config ACPI_APEI_SEI
+   bool "APEI Asynchronous SError Interrupt logging/recovering support"
+   depends on ARM64 && ACPI_APEI_GHES
+   default y
+   help
+ This option should be enabled if the system supports
+ firmware first handling of SEI (asynchronous SError interrupt).
+
+ SEI happens with asynchronous external abort for errors on device
+ memory reads on ARMv8 systems. If a system supports firmware first
+ handling of SEI, the platform analyzes and handles hardware error
+ notifications from SEI, and it may then form a HW error record for
+ the OS to parse and handle. This option allows the OS to look for
+ such hardware error record, and take appropriate action.
+
 config ACPI_APEI_MEMORY_FAILURE
bool "APEI memory error recovering support"
depends on ACPI_APEI && MEMORY_FAILURE
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 3eee30a..66a2953 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -815,33 +815,57 @@ static struct notifier_block ghes_notifier_hed = {
 
 #ifdef CONFIG_ACPI_APEI_SEA
 static LIST_HEAD(ghes_sea);
+#endif
+
+#ifdef CONFIG_ACPI_APEI_SEI
+static LIST_HEAD(ghes_sei);
+#endif
 
+#if defined(CONFIG_ACPI_APEI_SEA) || defined(CONFIG_ACPI_APEI_SEI)
 /*
- * Return 0 only if one of the SEA error sources successfully reported an error
- * record sent from the firmware.
+ * Return 0 only if one of the SEA or SEI error sources successfully
+ * reported an error record sent from the firmware.
  */
-int ghes_notify_sea(void)
+int ghes_notify_abort(u8 type)
 {
struct ghes *ghes;
+   struct list_head *head = NULL;
int ret = -ENOENT;
 
-   rcu_read_lock();
-   list_for_each_entry_rcu(ghes, &ghes_sea, list) {
-   if (!ghes_proc(ghes))
-   ret = 0;
+   if (type == ACPI_HEST_NOTIFY_SEA)
+   head = &ghes_sea;
+   else if (type == ACPI_HEST_NOTIFY_SEI)
+   head = &ghes_sei;
+
+   if (head) {
+   rcu_read_lock();
+   list_for_each_entry_rcu(ghes, head, list) {
+   if (!ghes_proc(ghes))
+   ret = 0;
+   }
+   rcu_read_unlock();
}
-   rcu_read_unlock();
return ret;
 }
 
-static void ghes_sea_add(struct ghes *ghes)
+static void ghes_abort_add(struct ghes *ghes)
 {
-   mutex_lock(&ghes_list_mutex);
-   list_add_rcu(&ghes->list, &ghes_sea);
-   mutex_unlock(&ghes_list_mutex);
+   struct list_head *head = NULL;
+   u8 notify_type = ghes->generic->notify.type;
+
+   if (notify_type == ACPI_HEST_NOTIFY_SEA)
+   head = &ghes_sea;
+   else if (notify_type == ACPI_HEST_NOTIFY_SEI)
+   head = &ghes_sei;
+
+   

Re: [PATCH v3 1/2] acpi: apei: remove the unused dead-code for SEA notification type

2017-10-15 Thread gengdongjiu
Borislav,
  Thank you for your time to review it.

On 2017/10/13 21:21, Borislav Petkov wrote:
>>  .notifier_call = ghes_notify_hed,
>>  };
>>  
>> -#ifdef CONFIG_ACPI_APEI_SEA
>>  static LIST_HEAD(ghes_sea);
> But now those get compiled in on x86 where there's no SEA and where we
> don't need them. So no, I don't think this patch is correct.

If have updated the patch for the x86, you can review the version 4 patches.
thanks.




RE: [PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver

2017-10-15 Thread Yuval Mintz
> > >> This patchset adds a new hardware offload type in mqprio before
> adding
> > >> mqprio hardware offload support in hns3 driver.

Apparently Dave has already acceptedAmirtha's changes to mqprio:
https://marc.info/?l=linux-netdev&m=150803219824053&w=2 
so I guess you need to revise your patchs to align to the new conventions.

> > >
> > > I think one of the biggest issues in tying this to DCB configuration is 
> > > the
> > > non-immediate [and possibly non persistent] configuration.
> > >
> > > Scenario #1:
> > > User is configuring mqprio offloaded with 3 TCs while device is in willing
> > mode.
> > > Would you expect the driver to immediately respond with a success or
> > instead
> > > delay the return until the DCBx negotiation is complete and the
> operational
> > > num of TCs is actually 3?
> >
> > Well, when user requsts the mqprio offloaded by a hardware shared by
> DCB,
> > I expect
> > the user is not using the dcb tool.
> > If user is still using dcb tool, then result is undefined.
> >
> > The scenario you mention maybe can be enforced by setting willing to zero
> > when user
> > is requesting the mqprio offload, and restore the willing bit when unloaded
> > the mqprio
> > offload.
> 
> Sounds a bit harsh but would probably work.
> 
> > But I think the real issue is that dcb and mqprio shares the tc system in 
> > the
> > stack,
> > the problem may be better to be fixed in the stack rather than in the
> driver,
> > as you
> > suggested in the DCB patchset. What do you think?
> 
> What did you have in mind?
> 
> >
> > >
> > > Scenario #2:
> > > Assume user explicitly offloaded mqprio with 3 TCs, but now DCB
> > configuration
> > > has changed on the peer side and 4 TCs is the new negotiated operational
> > value.
> > > Your current driver logic would change the number of TCs underneath
> the
> > user
> > > configuration [and it would actually probably work due to mqprio being a
> > crappy
> > > qdisc]. But was that the user actual intention?
> > > [I think the likely answer in this scenario is 'yes' since the 
> > > alternative is no
> > better.
> > > But I still thought it was worth mentioning]
> >
> > You are right, the problem also have something to do with mqprio and dcb
> > sharing
> > the tc in the stack.
> >
> > Druing testing, when user explicitly offloaded mqprio with 3 TCs, all
> > queue has a default pfifo mqprio attached, after DCB changes the tc num
> to
> > 4,
> > using tc qdisc shows some queue does not have a default pfifo mqprio
> > attached.
> 
> Really? Then what did it show?
> [I assume it has some pfifo attached, and it's an mqprio dump kind of an
> issue]
> 
> >
> > Maybe we can add a callback to notify mqprio the configuration has
> changed.
> >
> 
> Which would do what?
> You already have the notifications available for monitoring using dcbnl logic 
> if
> the
> configuration change [for user]; So user can re-configure whatever it wants.
> But other than dropping all the qdisc configurations and going back to the
> default
> qdiscs, what default action would mqprio be able to do when configuration
> changes
> that actually makes sense?
> 
> > Thanks
> > Yunsheng Lin
> >
> > >
> > > Cheers,
> > > Yuval
> > >
> > >>
> > >> Yunsheng Lin (2):
> > >>   mqprio: Add a new hardware offload type in mqprio
> > >>   net: hns3: Add mqprio hardware offload support in hns3 driver
> > >>
> > >>  drivers/net/ethernet/hisilicon/hns3/hnae3.h|  1 +
> > >>  .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++
> > >>  .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46
> > ++-
> > >> ---
> > >>  include/uapi/linux/pkt_sched.h |  1 +
> > >>  4 files changed, 55 insertions(+), 16 deletions(-)
> > >>
> > >> --
> > >> 1.9.1
> > >
> > >
> > >



[PATCH] regulator: axp20x: Simplify axp20x_is_polyphase_slave implementation

2017-10-15 Thread Axel Lin
The code to handle AXP803_ID and AXP813_ID cases are exactly the same.
Make the switch-case fall through to avoid duplicate code.

Signed-off-by: Axel Lin 
---
 drivers/regulator/axp20x-regulator.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index e1761df4cbfd..181622b2813d 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -657,6 +657,7 @@ static bool axp20x_is_polyphase_slave(struct axp20x_dev 
*axp20x, int id)
 */
switch (axp20x->variant) {
case AXP803_ID:
+   case AXP813_ID:
regmap_read(axp20x->regmap, AXP803_POLYPHASE_CTRL, ®);
 
switch (id) {
@@ -681,17 +682,6 @@ static bool axp20x_is_polyphase_slave(struct axp20x_dev 
*axp20x, int id)
}
break;
 
-   case AXP813_ID:
-   regmap_read(axp20x->regmap, AXP803_POLYPHASE_CTRL, ®);
-
-   switch (id) {
-   case AXP803_DCDC3:
-   return !!(reg & BIT(6));
-   case AXP803_DCDC6:
-   return !!(reg & BIT(5));
-   }
-   break;
-
default:
return false;
}
-- 
2.11.0



Re: [PATCH] Makefile: Another fix for stackprotector _AUTO mode

2017-10-15 Thread Robert Jarzmik
Kees Cook  writes:

> If the compiler didn't support a build mode, the second empty test would
> still trip. This moves it to an "else" test for the non-AUTO modes.
>
> Reported-by: Robert Jarzmik 
> Signed-off-by: Kees Cook 
> ---
> Robert, can you test this fix?
Sure, tested and it works perfectly.

Tested-by: Robert Jarzmik 

And just to be more complete, what happened yesterday was that I wrongly wrote
"CROSS_COMPILER=arm-linux-gnueabi-" and not "CROSS_COMPILE=arm-linux-gnueabi-".

Normally when I do that kind of mistake, I get a gcc error that my architecture
options (-mabi, ...) are not supported. This time I got the stackprotector
thing. The good part is that with your patch I see again the gcc warnings I was
used too :)

Cheers.

--
Robert

PS:
rj@belgarion:~/mio_linux/kernel$ arm-linux-gnueabi-gcc -fstack-protector
arm-linux-gnueabi-gcc: fatal error: no input files
compilation terminated.


[PATCH v9 00/20] simplify crypto wait for async op

2017-10-15 Thread Gilad Ben-Yossef
Many users of kernel async. crypto services have a pattern of
starting an async. crypto op and than using a completion
to wait for it to end.

This patch set simplifies this common use case in two ways:

First, by separating the return codes of the case where a
request is queued to a backlog due to the provider being
busy (-EBUSY) from the case the request has failed due
to the provider being busy and backlogging is not enabled
(-EAGAIN).

Next, this change is than built on to create a generic API
to wait for a async. crypto operation to complete.

The end result is a smaller code base and an API that is
easier to use and more difficult to get wrong.

The patch set was boot tested on x86_64 and arm64 which
at the very least tests the crypto users via testmgr and
tcrypt but I do note that I do not have access to some
of the HW whose drivers are modified nor do I claim I was
able to test all of the corner cases.

The patch set is based upon linux-next release tagged
next-20171013.

Changes from v8:
- Remove the translation of EAGAIN return code to the
  previous return code of EBUSY for the user space
  interface of algif as no one seems to rely on it as
  requested by Herbert Xu.

Changes from v7:
- Turn -EBUSY to -EAGAIN also in crypto using net
  code which I missed before, as has been pointed
  out by Harsh Jain.

Changes from v6:
- Fix brown paper bag compile error on marvell/cesa
  code.

Changes from v5:
- Remove redundant new line as spotted by Jonathan
  Cameron.
- Reworded dm-verity change commit message to better
  clarify potential issue averted by change as
  pointed out by Mikulas Patocka.

Changes from v4:
- Rebase on top of latest algif changes from Stephan
  Mueller.
- Fix typo in ccp patch title.

Changes from v3:
- Instead of changing the return code to indicate
  backlog queueing, change the return code to indicate
  transient busy state, as suggested by Herbert Xu.

Changes from v2:
- Patch title changed from "introduce crypto wait for
  async op" to better reflect the current state.
- Rebase on top of latest linux-next.
- Add a new return code of -EIOCBQUEUED for backlog
  queueing, as suggested by Herbert Xu.
- Transform more users to the new API.
- Update the drbg change to account for new init as
  indicated by Stephan Muller.

Changes from v1:
- Address review comments from Eric Biggers.
- Separated out bug fixes of existing code and rebase
  on top of that patch set.
- Rename 'ecr' to 'wait' in fscrypto code.
- Split patch introducing the new API from the change
  moving over the algif code which it originated from
  to the new API.
- Inline crypto_wait_req().
- Some code indentation fixes.

Gilad Ben-Yossef (20):
  crypto: change transient busy return code to -EAGAIN
  crypto: ccp: use -EAGAIN for transient busy indication
  net: use -EAGAIN for transient busy indication
  crypto: remove redundant backlog checks on EBUSY
  crypto: marvell/cesa: remove redundant backlog checks on EBUSY
  crypto: introduce crypto wait for async op
  crypto: move algif to generic async completion
  crypto: move pub key to generic async completion
  crypto: move drbg to generic async completion
  crypto: move gcm to generic async completion
  crypto: move testmgr to generic async completion
  fscrypt: move to generic async completion
  dm: move dm-verity to generic async completion
  cifs: move to generic async completion
  ima: move to generic async completion
  crypto: tcrypt: move to generic async completion
  crypto: talitos: move to generic async completion
  crypto: qce: move to generic async completion
  crypto: mediatek: move to generic async completion
  crypto: adapt api sample to use async. op wait

 Documentation/crypto/api-samples.rst |  52 ++---
 crypto/af_alg.c  |  27 -
 crypto/ahash.c   |  12 +--
 crypto/algapi.c  |   6 +-
 crypto/algif_aead.c  |   8 +-
 crypto/algif_hash.c  |  30 +++---
 crypto/algif_skcipher.c  |   9 +-
 crypto/api.c |  13 +++
 crypto/asymmetric_keys/public_key.c  |  28 +
 crypto/cryptd.c  |   4 +-
 crypto/cts.c |   6 +-
 crypto/drbg.c|  36 ++-
 crypto/gcm.c |  32 ++
 crypto/lrw.c |   8 +-
 crypto/rsa-pkcs1pad.c|  16 +--
 crypto/tcrypt.c  |  84 +--
 crypto/testmgr.c | 204 ---
 crypto/xts.c |   8 +-
 drivers/crypto/ccp/ccp-crypto-main.c |   8 +-
 drivers/crypto/ccp/ccp-dev.c |   7 +-
 drivers/crypto/marvell/cesa.c|   3 +-
 drivers/crypto/marvell/cesa.h|   2 +-
 drivers/crypto/mediatek/mtk-aes.c|  31 +-
 drivers/crypto/qce/sha.c |  30 +-
 drivers/crypto/talitos.c |  38 +--
 drivers/md/dm-verity-target.c|  81 -

[PATCH v9 03/20] net: use -EAGAIN for transient busy indication

2017-10-15 Thread Gilad Ben-Yossef
Replace -EBUSY with -EAGAIN when handling transient busy
indication in the absence of backlog.

Signed-off-by: Gilad Ben-Yossef 

---

Please squash this patch with the previous one when merging upstream.

 net/ipv4/ah4.c  | 2 +-
 net/ipv4/esp4.c | 2 +-
 net/ipv6/ah6.c  | 2 +-
 net/ipv6/esp6.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 37db44f..049cb0a 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -240,7 +240,7 @@ static int ah_output(struct xfrm_state *x, struct sk_buff 
*skb)
if (err == -EINPROGRESS)
goto out;
 
-   if (err == -EBUSY)
+   if (err == -EAGAIN)
err = NET_XMIT_DROP;
goto out_free;
}
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index b00e4a4..ff8e088 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -432,7 +432,7 @@ int esp_output_tail(struct xfrm_state *x, struct sk_buff 
*skb, struct esp_info *
case -EINPROGRESS:
goto error;
 
-   case -EBUSY:
+   case -EAGAIN:
err = NET_XMIT_DROP;
break;
 
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index 7802b72..ba0c145 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -443,7 +443,7 @@ static int ah6_output(struct xfrm_state *x, struct sk_buff 
*skb)
if (err == -EINPROGRESS)
goto out;
 
-   if (err == -EBUSY)
+   if (err == -EAGAIN)
err = NET_XMIT_DROP;
goto out_free;
}
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 89910e2..1a71ee5 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -396,7 +396,7 @@ int esp6_output_tail(struct xfrm_state *x, struct sk_buff 
*skb, struct esp_info
case -EINPROGRESS:
goto error;
 
-   case -EBUSY:
+   case -EAGAIN:
err = NET_XMIT_DROP;
break;
 
-- 
2.7.4



[PATCH v9 05/20] crypto: marvell/cesa: remove redundant backlog checks on EBUSY

2017-10-15 Thread Gilad Ben-Yossef
Now that -EBUSY return code only indicates backlog queueing
we can safely remove the now redundant check for the
CRYPTO_TFM_REQ_MAY_BACKLOG flag when -EBUSY is returned.

Signed-off-by: Gilad Ben-Yossef 
Acked-by: Boris Brezillon 
---
 drivers/crypto/marvell/cesa.c | 3 +--
 drivers/crypto/marvell/cesa.h | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index b657e7c..ff73aa5 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -181,8 +181,7 @@ int mv_cesa_queue_req(struct crypto_async_request *req,
spin_lock_bh(&engine->lock);
ret = crypto_enqueue_request(&engine->queue, req);
if ((mv_cesa_req_get_type(creq) == CESA_DMA_REQ) &&
-   (ret == -EINPROGRESS ||
-   (ret == -EBUSY && req->flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
+   (ret == -EINPROGRESS || ret == -EBUSY))
mv_cesa_tdma_chain(engine, creq);
spin_unlock_bh(&engine->lock);
 
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index b7872f6..63c8457 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -763,7 +763,7 @@ static inline int mv_cesa_req_needs_cleanup(struct 
crypto_async_request *req,
 * the backlog and will be processed later. There's no need to
 * clean it up.
 */
-   if (ret == -EBUSY && req->flags & CRYPTO_TFM_REQ_MAY_BACKLOG)
+   if (ret == -EBUSY)
return false;
 
/* Request wasn't queued, we need to clean it up */
-- 
2.7.4



[PATCH v9 04/20] crypto: remove redundant backlog checks on EBUSY

2017-10-15 Thread Gilad Ben-Yossef
Now that -EBUSY return code only indicates backlog queueing
we can safely remove the now redundant check for the
CRYPTO_TFM_REQ_MAY_BACKLOG flag when -EBUSY is returned.

Signed-off-by: Gilad Ben-Yossef 
---
 crypto/ahash.c| 12 +++-
 crypto/cts.c  |  6 ++
 crypto/lrw.c  |  8 ++--
 crypto/rsa-pkcs1pad.c | 16 
 crypto/xts.c  |  8 ++--
 5 files changed, 13 insertions(+), 37 deletions(-)

diff --git a/crypto/ahash.c b/crypto/ahash.c
index 5e8666e..3a35d67 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -334,9 +334,7 @@ static int ahash_op_unaligned(struct ahash_request *req,
return err;
 
err = op(req);
-   if (err == -EINPROGRESS ||
-   (err == -EBUSY && (ahash_request_flags(req) &
-  CRYPTO_TFM_REQ_MAY_BACKLOG)))
+   if (err == -EINPROGRESS || err == -EBUSY)
return err;
 
ahash_restore_req(req, err);
@@ -394,9 +392,7 @@ static int ahash_def_finup_finish1(struct ahash_request 
*req, int err)
req->base.complete = ahash_def_finup_done2;
 
err = crypto_ahash_reqtfm(req)->final(req);
-   if (err == -EINPROGRESS ||
-   (err == -EBUSY && (ahash_request_flags(req) &
-  CRYPTO_TFM_REQ_MAY_BACKLOG)))
+   if (err == -EINPROGRESS || err == -EBUSY)
return err;
 
 out:
@@ -432,9 +428,7 @@ static int ahash_def_finup(struct ahash_request *req)
return err;
 
err = tfm->update(req);
-   if (err == -EINPROGRESS ||
-   (err == -EBUSY && (ahash_request_flags(req) &
-  CRYPTO_TFM_REQ_MAY_BACKLOG)))
+   if (err == -EINPROGRESS || err == -EBUSY)
return err;
 
return ahash_def_finup_finish1(req, err);
diff --git a/crypto/cts.c b/crypto/cts.c
index 243f591..4773c18 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -136,8 +136,7 @@ static void crypto_cts_encrypt_done(struct 
crypto_async_request *areq, int err)
goto out;
 
err = cts_cbc_encrypt(req);
-   if (err == -EINPROGRESS ||
-   (err == -EBUSY && req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+   if (err == -EINPROGRESS || err == -EBUSY)
return;
 
 out:
@@ -229,8 +228,7 @@ static void crypto_cts_decrypt_done(struct 
crypto_async_request *areq, int err)
goto out;
 
err = cts_cbc_decrypt(req);
-   if (err == -EINPROGRESS ||
-   (err == -EBUSY && req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+   if (err == -EINPROGRESS || err == -EBUSY)
return;
 
 out:
diff --git a/crypto/lrw.c b/crypto/lrw.c
index 92df312..cbbd7c5 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -328,9 +328,7 @@ static int do_encrypt(struct skcipher_request *req, int err)
  crypto_skcipher_encrypt(subreq) ?:
  post_crypt(req);
 
-   if (err == -EINPROGRESS ||
-   (err == -EBUSY &&
-req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+   if (err == -EINPROGRESS || err == -EBUSY)
return err;
}
 
@@ -380,9 +378,7 @@ static int do_decrypt(struct skcipher_request *req, int err)
  crypto_skcipher_decrypt(subreq) ?:
  post_crypt(req);
 
-   if (err == -EINPROGRESS ||
-   (err == -EBUSY &&
-req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+   if (err == -EINPROGRESS || err == -EBUSY)
return err;
}
 
diff --git a/crypto/rsa-pkcs1pad.c b/crypto/rsa-pkcs1pad.c
index 407c64b..2908f93 100644
--- a/crypto/rsa-pkcs1pad.c
+++ b/crypto/rsa-pkcs1pad.c
@@ -279,9 +279,7 @@ static int pkcs1pad_encrypt(struct akcipher_request *req)
   req->dst, ctx->key_size - 1, req->dst_len);
 
err = crypto_akcipher_encrypt(&req_ctx->child_req);
-   if (err != -EINPROGRESS &&
-   (err != -EBUSY ||
-!(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
+   if (err != -EINPROGRESS && err != -EBUSY)
return pkcs1pad_encrypt_sign_complete(req, err);
 
return err;
@@ -383,9 +381,7 @@ static int pkcs1pad_decrypt(struct akcipher_request *req)
   ctx->key_size);
 
err = crypto_akcipher_decrypt(&req_ctx->child_req);
-   if (err != -EINPROGRESS &&
-   (err != -EBUSY ||
-!(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
+   if (err != -EINPROGRESS && err != -EBUSY)
return pkcs1pad_decrypt_complete(req, err);
 
return err;
@@ -440,9 +436,7 @@ static int pkcs1pad_sign(struct akcipher_request *req)
   req->dst, ctx->key_size - 1, req->dst_len);
 
err = crypto_akcipher_sign(&req_ctx->child_req);
-   if (err != -EI

[PATCH v9 01/20] crypto: change transient busy return code to -EAGAIN

2017-10-15 Thread Gilad Ben-Yossef
The crypto API was using the -EBUSY return value to indicate
both a hard failure to submit a crypto operation into a
transformation provider when the latter was busy and the backlog
mechanism was not enabled as well as a notification that the
operation was queued into the backlog when the backlog mechanism
was enabled.

Having the same return code indicate two very different conditions
depending on a flag is both error prone and requires extra runtime
check like the following to discern between the cases:

if (err == -EINPROGRESS ||
(err == -EBUSY && (ahash_request_flags(req) &
   CRYPTO_TFM_REQ_MAY_BACKLOG)))

This patch changes the return code used to indicate a crypto op
failed due to the transformation provider being transiently busy
to -EAGAIN.

Signed-off-by: Gilad Ben-Yossef 
---
 crypto/algapi.c | 6 --
 crypto/cryptd.c | 4 +---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/crypto/algapi.c b/crypto/algapi.c
index aa699ff..916bee3 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -897,9 +897,11 @@ int crypto_enqueue_request(struct crypto_queue *queue,
int err = -EINPROGRESS;
 
if (unlikely(queue->qlen >= queue->max_qlen)) {
-   err = -EBUSY;
-   if (!(request->flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+   if (!(request->flags & CRYPTO_TFM_REQ_MAY_BACKLOG)) {
+   err = -EAGAIN;
goto out;
+   }
+   err = -EBUSY;
if (queue->backlog == &queue->list)
queue->backlog = &request->list;
}
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index 0508c48..d1dbdce 100644
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -137,16 +137,14 @@ static int cryptd_enqueue_request(struct cryptd_queue 
*queue,
int cpu, err;
struct cryptd_cpu_queue *cpu_queue;
atomic_t *refcnt;
-   bool may_backlog;
 
cpu = get_cpu();
cpu_queue = this_cpu_ptr(queue->cpu_queue);
err = crypto_enqueue_request(&cpu_queue->queue, request);
 
refcnt = crypto_tfm_ctx(request->tfm);
-   may_backlog = request->flags & CRYPTO_TFM_REQ_MAY_BACKLOG;
 
-   if (err == -EBUSY && !may_backlog)
+   if (err == -EAGAIN)
goto out_put_cpu;
 
queue_work_on(cpu, kcrypto_wq, &cpu_queue->work);
-- 
2.7.4



[PATCH v9 02/20] crypto: ccp: use -EAGAIN for transient busy indication

2017-10-15 Thread Gilad Ben-Yossef
Replace -EBUSY with -EAGAIN when reporting transient busy
indication in the absence of backlog.

Signed-off-by: Gilad Ben-Yossef 
Reviewed-by: Gary R Hook 

---

Please squash this patch with the previous one when merging upstream.

 drivers/crypto/ccp/ccp-crypto-main.c | 8 +++-
 drivers/crypto/ccp/ccp-dev.c | 7 +--
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-crypto-main.c 
b/drivers/crypto/ccp/ccp-crypto-main.c
index 35a9de7..403ff0a 100644
--- a/drivers/crypto/ccp/ccp-crypto-main.c
+++ b/drivers/crypto/ccp/ccp-crypto-main.c
@@ -222,9 +222,10 @@ static int ccp_crypto_enqueue_cmd(struct ccp_crypto_cmd 
*crypto_cmd)
 
/* Check if the cmd can/should be queued */
if (req_queue.cmd_count >= CCP_CRYPTO_MAX_QLEN) {
-   ret = -EBUSY;
-   if (!(crypto_cmd->cmd->flags & CCP_CMD_MAY_BACKLOG))
+   if (!(crypto_cmd->cmd->flags & CCP_CMD_MAY_BACKLOG)) {
+   ret = -EAGAIN;
goto e_lock;
+   }
}
 
/* Look for an entry with the same tfm.  If there is a cmd
@@ -243,9 +244,6 @@ static int ccp_crypto_enqueue_cmd(struct ccp_crypto_cmd 
*crypto_cmd)
ret = ccp_enqueue_cmd(crypto_cmd->cmd);
if (!ccp_crypto_success(ret))
goto e_lock;/* Error, don't queue it */
-   if ((ret == -EBUSY) &&
-   !(crypto_cmd->cmd->flags & CCP_CMD_MAY_BACKLOG))
-   goto e_lock;/* Not backlogging, don't queue it */
}
 
if (req_queue.cmd_count >= CCP_CRYPTO_MAX_QLEN) {
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 4e029b1..3d637e3 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -292,9 +292,12 @@ int ccp_enqueue_cmd(struct ccp_cmd *cmd)
i = ccp->cmd_q_count;
 
if (ccp->cmd_count >= MAX_CMD_QLEN) {
-   ret = -EBUSY;
-   if (cmd->flags & CCP_CMD_MAY_BACKLOG)
+   if (cmd->flags & CCP_CMD_MAY_BACKLOG) {
+   ret = -EBUSY;
list_add_tail(&cmd->entry, &ccp->backlog);
+   } else {
+   ret = -EAGAIN;
+   }
} else {
ret = -EINPROGRESS;
ccp->cmd_count++;
-- 
2.7.4



[PATCH v9 09/20] crypto: move drbg to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
DRBG is starting an async. crypto op and waiting for it complete.
Move it over to generic code doing the same.

The code now also passes CRYPTO_TFM_REQ_MAY_SLEEP flag indicating
crypto request memory allocation may use GFP_KERNEL which should
be perfectly fine as the code is obviously sleeping for the
completion of the request any way.

Signed-off-by: Gilad Ben-Yossef 
---
 crypto/drbg.c | 36 +---
 include/crypto/drbg.h |  3 +--
 2 files changed, 10 insertions(+), 29 deletions(-)

diff --git a/crypto/drbg.c b/crypto/drbg.c
index 7001839..4faa278 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1651,16 +1651,6 @@ static int drbg_fini_sym_kernel(struct drbg_state *drbg)
return 0;
 }
 
-static void drbg_skcipher_cb(struct crypto_async_request *req, int error)
-{
-   struct drbg_state *drbg = req->data;
-
-   if (error == -EINPROGRESS)
-   return;
-   drbg->ctr_async_err = error;
-   complete(&drbg->ctr_completion);
-}
-
 static int drbg_init_sym_kernel(struct drbg_state *drbg)
 {
struct crypto_cipher *tfm;
@@ -1691,7 +1681,7 @@ static int drbg_init_sym_kernel(struct drbg_state *drbg)
return PTR_ERR(sk_tfm);
}
drbg->ctr_handle = sk_tfm;
-   init_completion(&drbg->ctr_completion);
+   crypto_init_wait(&drbg->ctr_wait);
 
req = skcipher_request_alloc(sk_tfm, GFP_KERNEL);
if (!req) {
@@ -1700,8 +1690,9 @@ static int drbg_init_sym_kernel(struct drbg_state *drbg)
return -ENOMEM;
}
drbg->ctr_req = req;
-   skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
-   drbg_skcipher_cb, drbg);
+   skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG |
+   CRYPTO_TFM_REQ_MAY_SLEEP,
+   crypto_req_done, &drbg->ctr_wait);
 
alignmask = crypto_skcipher_alignmask(sk_tfm);
drbg->ctr_null_value_buf = kzalloc(DRBG_CTR_NULL_LEN + alignmask,
@@ -1762,21 +1753,12 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
/* Output buffer may not be valid for SGL, use scratchpad */
skcipher_request_set_crypt(drbg->ctr_req, &sg_in, &sg_out,
   cryptlen, drbg->V);
-   ret = crypto_skcipher_encrypt(drbg->ctr_req);
-   switch (ret) {
-   case 0:
-   break;
-   case -EINPROGRESS:
-   case -EBUSY:
-   wait_for_completion(&drbg->ctr_completion);
-   if (!drbg->ctr_async_err) {
-   reinit_completion(&drbg->ctr_completion);
-   break;
-   }
-   default:
+   ret = crypto_wait_req(crypto_skcipher_encrypt(drbg->ctr_req),
+   &drbg->ctr_wait);
+   if (ret)
goto out;
-   }
-   init_completion(&drbg->ctr_completion);
+
+   crypto_init_wait(&drbg->ctr_wait);
 
memcpy(outbuf, drbg->outscratchpad, cryptlen);
 
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index 22f884c..8f94110 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -126,8 +126,7 @@ struct drbg_state {
__u8 *ctr_null_value;   /* CTR mode aligned zero buf */
__u8 *outscratchpadbuf; /* CTR mode output scratchpad */
 __u8 *outscratchpad;   /* CTR mode aligned outbuf */
-   struct completion ctr_completion;   /* CTR mode async handler */
-   int ctr_async_err;  /* CTR mode async error */
+   struct crypto_wait ctr_wait;/* CTR mode async wait obj */
 
bool seeded;/* DRBG fully seeded? */
bool pr;/* Prediction resistance enabled? */
-- 
2.7.4



[PATCH v9 06/20] crypto: introduce crypto wait for async op

2017-10-15 Thread Gilad Ben-Yossef
Invoking a possibly async. crypto op and waiting for completion
while correctly handling backlog processing is a common task
in the crypto API implementation and outside users of it.

This patch adds a generic implementation for doing so in
preparation for using it across the board instead of hand
rolled versions.

Signed-off-by: Gilad Ben-Yossef 
CC: Eric Biggers 
CC: Jonathan Cameron 
---
 crypto/api.c   | 13 +
 include/linux/crypto.h | 40 
 2 files changed, 53 insertions(+)

diff --git a/crypto/api.c b/crypto/api.c
index 941cd4c..2a2479d 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "internal.h"
 
 LIST_HEAD(crypto_alg_list);
@@ -595,5 +596,17 @@ int crypto_has_alg(const char *name, u32 type, u32 mask)
 }
 EXPORT_SYMBOL_GPL(crypto_has_alg);
 
+void crypto_req_done(struct crypto_async_request *req, int err)
+{
+   struct crypto_wait *wait = req->data;
+
+   if (err == -EINPROGRESS)
+   return;
+
+   wait->err = err;
+   complete(&wait->completion);
+}
+EXPORT_SYMBOL_GPL(crypto_req_done);
+
 MODULE_DESCRIPTION("Cryptographic core API");
 MODULE_LICENSE("GPL");
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 84da997..78508ca 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Autoloaded crypto modules should only use a prefixed name to avoid allowing
@@ -468,6 +469,45 @@ struct crypto_alg {
 } CRYPTO_MINALIGN_ATTR;
 
 /*
+ * A helper struct for waiting for completion of async crypto ops
+ */
+struct crypto_wait {
+   struct completion completion;
+   int err;
+};
+
+/*
+ * Macro for declaring a crypto op async wait object on stack
+ */
+#define DECLARE_CRYPTO_WAIT(_wait) \
+   struct crypto_wait _wait = { \
+   COMPLETION_INITIALIZER_ONSTACK((_wait).completion), 0 }
+
+/*
+ * Async ops completion helper functioons
+ */
+void crypto_req_done(struct crypto_async_request *req, int err);
+
+static inline int crypto_wait_req(int err, struct crypto_wait *wait)
+{
+   switch (err) {
+   case -EINPROGRESS:
+   case -EBUSY:
+   wait_for_completion(&wait->completion);
+   reinit_completion(&wait->completion);
+   err = wait->err;
+   break;
+   };
+
+   return err;
+}
+
+static inline void crypto_init_wait(struct crypto_wait *wait)
+{
+   init_completion(&wait->completion);
+}
+
+/*
  * Algorithm registration interface.
  */
 int crypto_register_alg(struct crypto_alg *alg);
-- 
2.7.4



[PATCH v9 07/20] crypto: move algif to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
algif starts several async crypto ops and waits for their completion.
Move it over to generic code doing the same.

Signed-off-by: Gilad Ben-Yossef 
---
 crypto/af_alg.c | 27 ---
 crypto/algif_aead.c |  8 
 crypto/algif_hash.c | 30 ++
 crypto/algif_skcipher.c |  9 -
 include/crypto/if_alg.h | 15 +--
 5 files changed, 23 insertions(+), 66 deletions(-)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 337cf38..85cea9d 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -481,33 +481,6 @@ int af_alg_cmsg_send(struct msghdr *msg, struct 
af_alg_control *con)
 }
 EXPORT_SYMBOL_GPL(af_alg_cmsg_send);
 
-int af_alg_wait_for_completion(int err, struct af_alg_completion *completion)
-{
-   switch (err) {
-   case -EINPROGRESS:
-   case -EBUSY:
-   wait_for_completion(&completion->completion);
-   reinit_completion(&completion->completion);
-   err = completion->err;
-   break;
-   };
-
-   return err;
-}
-EXPORT_SYMBOL_GPL(af_alg_wait_for_completion);
-
-void af_alg_complete(struct crypto_async_request *req, int err)
-{
-   struct af_alg_completion *completion = req->data;
-
-   if (err == -EINPROGRESS)
-   return;
-
-   completion->err = err;
-   complete(&completion->completion);
-}
-EXPORT_SYMBOL_GPL(af_alg_complete);
-
 /**
  * af_alg_alloc_tsgl - allocate the TX SGL
  *
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 516b38c..aacae08 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -278,11 +278,11 @@ static int _aead_recvmsg(struct socket *sock, struct 
msghdr *msg,
/* Synchronous operation */
aead_request_set_callback(&areq->cra_u.aead_req,
  CRYPTO_TFM_REQ_MAY_BACKLOG,
- af_alg_complete, &ctx->completion);
-   err = af_alg_wait_for_completion(ctx->enc ?
+ crypto_req_done, &ctx->wait);
+   err = crypto_wait_req(ctx->enc ?
crypto_aead_encrypt(&areq->cra_u.aead_req) :
crypto_aead_decrypt(&areq->cra_u.aead_req),
-&ctx->completion);
+   &ctx->wait);
}
 
/* AIO operation in progress */
@@ -554,7 +554,7 @@ static int aead_accept_parent_nokey(void *private, struct 
sock *sk)
ctx->merge = 0;
ctx->enc = 0;
ctx->aead_assoclen = 0;
-   af_alg_init_completion(&ctx->completion);
+   crypto_init_wait(&ctx->wait);
 
ask->private = ctx;
 
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 5e92bd2..76d2e71 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -26,7 +26,7 @@ struct hash_ctx {
 
u8 *result;
 
-   struct af_alg_completion completion;
+   struct crypto_wait wait;
 
unsigned int len;
bool more;
@@ -88,8 +88,7 @@ static int hash_sendmsg(struct socket *sock, struct msghdr 
*msg,
if ((msg->msg_flags & MSG_MORE))
hash_free_result(sk, ctx);
 
-   err = af_alg_wait_for_completion(crypto_ahash_init(&ctx->req),
-   &ctx->completion);
+   err = crypto_wait_req(crypto_ahash_init(&ctx->req), &ctx->wait);
if (err)
goto unlock;
}
@@ -110,8 +109,8 @@ static int hash_sendmsg(struct socket *sock, struct msghdr 
*msg,
 
ahash_request_set_crypt(&ctx->req, ctx->sgl.sg, NULL, len);
 
-   err = af_alg_wait_for_completion(crypto_ahash_update(&ctx->req),
-&ctx->completion);
+   err = crypto_wait_req(crypto_ahash_update(&ctx->req),
+ &ctx->wait);
af_alg_free_sg(&ctx->sgl);
if (err)
goto unlock;
@@ -129,8 +128,8 @@ static int hash_sendmsg(struct socket *sock, struct msghdr 
*msg,
goto unlock;
 
ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
-   err = af_alg_wait_for_completion(crypto_ahash_final(&ctx->req),
-&ctx->completion);
+   err = crypto_wait_req(crypto_ahash_final(&ctx->req),
+ &ctx->wait);
}
 
 unlock:
@@ -171,7 +170,7 @@ static ssize_t hash_sendpage(struct socket *sock, struct 
page *page,
} else {
if (!ctx->more) {
err = crypto_ahash_init(&ctx->req);
-   err = af_alg_wait_for_completion(err, &ctx->completion);
+   err = crypto_wait_req(err, &ctx->wait);
if (err)
   

[PATCH v9 08/20] crypto: move pub key to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
public_key_verify_signature() is starting an async crypto op and
waiting for it to complete. Move it over to generic code doing
the same.

Signed-off-by: Gilad Ben-Yossef 
---
 crypto/asymmetric_keys/public_key.c | 28 
 1 file changed, 4 insertions(+), 24 deletions(-)

diff --git a/crypto/asymmetric_keys/public_key.c 
b/crypto/asymmetric_keys/public_key.c
index 3cd6e12..d916235 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -57,29 +57,13 @@ static void public_key_destroy(void *payload0, void 
*payload3)
public_key_signature_free(payload3);
 }
 
-struct public_key_completion {
-   struct completion completion;
-   int err;
-};
-
-static void public_key_verify_done(struct crypto_async_request *req, int err)
-{
-   struct public_key_completion *compl = req->data;
-
-   if (err == -EINPROGRESS)
-   return;
-
-   compl->err = err;
-   complete(&compl->completion);
-}
-
 /*
  * Verify a signature using a public key.
  */
 int public_key_verify_signature(const struct public_key *pkey,
const struct public_key_signature *sig)
 {
-   struct public_key_completion compl;
+   struct crypto_wait cwait;
struct crypto_akcipher *tfm;
struct akcipher_request *req;
struct scatterlist sig_sg, digest_sg;
@@ -131,20 +115,16 @@ int public_key_verify_signature(const struct public_key 
*pkey,
sg_init_one(&digest_sg, output, outlen);
akcipher_request_set_crypt(req, &sig_sg, &digest_sg, sig->s_size,
   outlen);
-   init_completion(&compl.completion);
+   crypto_init_wait(&cwait);
akcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG |
  CRYPTO_TFM_REQ_MAY_SLEEP,
- public_key_verify_done, &compl);
+ crypto_req_done, &cwait);
 
/* Perform the verification calculation.  This doesn't actually do the
 * verification, but rather calculates the hash expected by the
 * signature and returns that to us.
 */
-   ret = crypto_akcipher_verify(req);
-   if ((ret == -EINPROGRESS) || (ret == -EBUSY)) {
-   wait_for_completion(&compl.completion);
-   ret = compl.err;
-   }
+   ret = crypto_wait_req(crypto_akcipher_verify(req), &cwait);
if (ret < 0)
goto out_free_output;
 
-- 
2.7.4



[PATCH v9 10/20] crypto: move gcm to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
gcm is starting an async. crypto op and waiting for it complete.
Move it over to generic code doing the same.

Signed-off-by: Gilad Ben-Yossef 
---
 crypto/gcm.c | 32 ++--
 1 file changed, 6 insertions(+), 26 deletions(-)

diff --git a/crypto/gcm.c b/crypto/gcm.c
index 80cf6cf..8589681 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include "internal.h"
-#include 
 #include 
 #include 
 #include 
@@ -79,11 +78,6 @@ struct crypto_gcm_req_priv_ctx {
} u;
 };
 
-struct crypto_gcm_setkey_result {
-   int err;
-   struct completion completion;
-};
-
 static struct {
u8 buf[16];
struct scatterlist sg;
@@ -99,17 +93,6 @@ static inline struct crypto_gcm_req_priv_ctx 
*crypto_gcm_reqctx(
return (void *)PTR_ALIGN((u8 *)aead_request_ctx(req), align + 1);
 }
 
-static void crypto_gcm_setkey_done(struct crypto_async_request *req, int err)
-{
-   struct crypto_gcm_setkey_result *result = req->data;
-
-   if (err == -EINPROGRESS)
-   return;
-
-   result->err = err;
-   complete(&result->completion);
-}
-
 static int crypto_gcm_setkey(struct crypto_aead *aead, const u8 *key,
 unsigned int keylen)
 {
@@ -120,7 +103,7 @@ static int crypto_gcm_setkey(struct crypto_aead *aead, 
const u8 *key,
be128 hash;
u8 iv[16];
 
-   struct crypto_gcm_setkey_result result;
+   struct crypto_wait wait;
 
struct scatterlist sg[1];
struct skcipher_request req;
@@ -141,21 +124,18 @@ static int crypto_gcm_setkey(struct crypto_aead *aead, 
const u8 *key,
if (!data)
return -ENOMEM;
 
-   init_completion(&data->result.completion);
+   crypto_init_wait(&data->wait);
sg_init_one(data->sg, &data->hash, sizeof(data->hash));
skcipher_request_set_tfm(&data->req, ctr);
skcipher_request_set_callback(&data->req, CRYPTO_TFM_REQ_MAY_SLEEP |
  CRYPTO_TFM_REQ_MAY_BACKLOG,
- crypto_gcm_setkey_done,
- &data->result);
+ crypto_req_done,
+ &data->wait);
skcipher_request_set_crypt(&data->req, data->sg, data->sg,
   sizeof(data->hash), data->iv);
 
-   err = crypto_skcipher_encrypt(&data->req);
-   if (err == -EINPROGRESS || err == -EBUSY) {
-   wait_for_completion(&data->result.completion);
-   err = data->result.err;
-   }
+   err = crypto_wait_req(crypto_skcipher_encrypt(&data->req),
+   &data->wait);
 
if (err)
goto out;
-- 
2.7.4



[PATCH v9 11/20] crypto: move testmgr to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
testmgr is starting async. crypto ops and waiting for them to complete.
Move it over to generic code doing the same.

This also provides a test of the generic crypto async. wait code.

Signed-off-by: Gilad Ben-Yossef 
---
 crypto/testmgr.c | 204 ++-
 1 file changed, 66 insertions(+), 138 deletions(-)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index dd9c7f1..3996fd5 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -76,11 +76,6 @@ int alg_test(const char *driver, const char *alg, u32 type, 
u32 mask)
 #define ENCRYPT 1
 #define DECRYPT 0
 
-struct tcrypt_result {
-   struct completion completion;
-   int err;
-};
-
 struct aead_test_suite {
struct {
const struct aead_testvec *vecs;
@@ -155,17 +150,6 @@ static void hexdump(unsigned char *buf, unsigned int len)
buf, len, false);
 }
 
-static void tcrypt_complete(struct crypto_async_request *req, int err)
-{
-   struct tcrypt_result *res = req->data;
-
-   if (err == -EINPROGRESS)
-   return;
-
-   res->err = err;
-   complete(&res->completion);
-}
-
 static int testmgr_alloc_buf(char *buf[XBUFSIZE])
 {
int i;
@@ -193,20 +177,10 @@ static void testmgr_free_buf(char *buf[XBUFSIZE])
free_page((unsigned long)buf[i]);
 }
 
-static int wait_async_op(struct tcrypt_result *tr, int ret)
-{
-   if (ret == -EINPROGRESS || ret == -EBUSY) {
-   wait_for_completion(&tr->completion);
-   reinit_completion(&tr->completion);
-   ret = tr->err;
-   }
-   return ret;
-}
-
 static int ahash_partial_update(struct ahash_request **preq,
struct crypto_ahash *tfm, const struct hash_testvec *template,
void *hash_buff, int k, int temp, struct scatterlist *sg,
-   const char *algo, char *result, struct tcrypt_result *tresult)
+   const char *algo, char *result, struct crypto_wait *wait)
 {
char *state;
struct ahash_request *req;
@@ -236,7 +210,7 @@ static int ahash_partial_update(struct ahash_request **preq,
}
ahash_request_set_callback(req,
CRYPTO_TFM_REQ_MAY_BACKLOG,
-   tcrypt_complete, tresult);
+   crypto_req_done, wait);
 
memcpy(hash_buff, template->plaintext + temp,
template->tap[k]);
@@ -247,7 +221,7 @@ static int ahash_partial_update(struct ahash_request **preq,
pr_err("alg: hash: Failed to import() for %s\n", algo);
goto out;
}
-   ret = wait_async_op(tresult, crypto_ahash_update(req));
+   ret = crypto_wait_req(crypto_ahash_update(req), wait);
if (ret)
goto out;
*preq = req;
@@ -272,7 +246,7 @@ static int __test_hash(struct crypto_ahash *tfm,
char *result;
char *key;
struct ahash_request *req;
-   struct tcrypt_result tresult;
+   struct crypto_wait wait;
void *hash_buff;
char *xbuf[XBUFSIZE];
int ret = -ENOMEM;
@@ -286,7 +260,7 @@ static int __test_hash(struct crypto_ahash *tfm,
if (testmgr_alloc_buf(xbuf))
goto out_nobuf;
 
-   init_completion(&tresult.completion);
+   crypto_init_wait(&wait);
 
req = ahash_request_alloc(tfm, GFP_KERNEL);
if (!req) {
@@ -295,7 +269,7 @@ static int __test_hash(struct crypto_ahash *tfm,
goto out_noreq;
}
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
-  tcrypt_complete, &tresult);
+  crypto_req_done, &wait);
 
j = 0;
for (i = 0; i < tcount; i++) {
@@ -335,26 +309,26 @@ static int __test_hash(struct crypto_ahash *tfm,
 
ahash_request_set_crypt(req, sg, result, template[i].psize);
if (use_digest) {
-   ret = wait_async_op(&tresult, crypto_ahash_digest(req));
+   ret = crypto_wait_req(crypto_ahash_digest(req), &wait);
if (ret) {
pr_err("alg: hash: digest failed on test %d "
   "for %s: ret=%d\n", j, algo, -ret);
goto out;
}
} else {
-   ret = wait_async_op(&tresult, crypto_ahash_init(req));
+   ret = crypto_wait_req(crypto_ahash_init(req), &wait);
if (ret) {
pr_err("alg: hash: init failed on test %d "
   "for %s: ret=%d\n", j, algo, -ret);
goto out;
}
-   ret = wait_async_op(&tresult, crypto_ahash_update(req));
+   ret = crypto_wait_req(crypto_ahash_update(req), &wait);
if (ret) {
pr_err("alg: has

[PATCH v9 13/20] dm: move dm-verity to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
dm-verity is starting async. crypto ops and waiting for them to complete.
Move it over to generic code doing the same.

This also avoids a future potential data coruption bug created
by the use of wait_for_completion_interruptible() without dealing
correctly with an interrupt aborting the wait prior to the
async op finishing, should this code ever move to a context
where signals are not masked.

Signed-off-by: Gilad Ben-Yossef 
CC: Mikulas Patocka 
---
 drivers/md/dm-verity-target.c | 81 +++
 drivers/md/dm-verity.h|  5 ---
 2 files changed, 20 insertions(+), 66 deletions(-)

diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
index bda3cac..811ad28 100644
--- a/drivers/md/dm-verity-target.c
+++ b/drivers/md/dm-verity-target.c
@@ -92,74 +92,33 @@ static sector_t verity_position_at_level(struct dm_verity 
*v, sector_t block,
return block >> (level * v->hash_per_block_bits);
 }
 
-/*
- * Callback function for asynchrnous crypto API completion notification
- */
-static void verity_op_done(struct crypto_async_request *base, int err)
-{
-   struct verity_result *res = (struct verity_result *)base->data;
-
-   if (err == -EINPROGRESS)
-   return;
-
-   res->err = err;
-   complete(&res->completion);
-}
-
-/*
- * Wait for async crypto API callback
- */
-static inline int verity_complete_op(struct verity_result *res, int ret)
-{
-   switch (ret) {
-   case 0:
-   break;
-
-   case -EINPROGRESS:
-   case -EBUSY:
-   ret = wait_for_completion_interruptible(&res->completion);
-   if (!ret)
-   ret = res->err;
-   reinit_completion(&res->completion);
-   break;
-
-   default:
-   DMERR("verity_wait_hash: crypto op submission failed: %d", ret);
-   }
-
-   if (unlikely(ret < 0))
-   DMERR("verity_wait_hash: crypto op failed: %d", ret);
-
-   return ret;
-}
-
 static int verity_hash_update(struct dm_verity *v, struct ahash_request *req,
const u8 *data, size_t len,
-   struct verity_result *res)
+   struct crypto_wait *wait)
 {
struct scatterlist sg;
 
sg_init_one(&sg, data, len);
ahash_request_set_crypt(req, &sg, NULL, len);
 
-   return verity_complete_op(res, crypto_ahash_update(req));
+   return crypto_wait_req(crypto_ahash_update(req), wait);
 }
 
 /*
  * Wrapper for crypto_ahash_init, which handles verity salting.
  */
 static int verity_hash_init(struct dm_verity *v, struct ahash_request *req,
-   struct verity_result *res)
+   struct crypto_wait *wait)
 {
int r;
 
ahash_request_set_tfm(req, v->tfm);
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP |
CRYPTO_TFM_REQ_MAY_BACKLOG,
-   verity_op_done, (void *)res);
-   init_completion(&res->completion);
+   crypto_req_done, (void *)wait);
+   crypto_init_wait(wait);
 
-   r = verity_complete_op(res, crypto_ahash_init(req));
+   r = crypto_wait_req(crypto_ahash_init(req), wait);
 
if (unlikely(r < 0)) {
DMERR("crypto_ahash_init failed: %d", r);
@@ -167,18 +126,18 @@ static int verity_hash_init(struct dm_verity *v, struct 
ahash_request *req,
}
 
if (likely(v->salt_size && (v->version >= 1)))
-   r = verity_hash_update(v, req, v->salt, v->salt_size, res);
+   r = verity_hash_update(v, req, v->salt, v->salt_size, wait);
 
return r;
 }
 
 static int verity_hash_final(struct dm_verity *v, struct ahash_request *req,
-u8 *digest, struct verity_result *res)
+u8 *digest, struct crypto_wait *wait)
 {
int r;
 
if (unlikely(v->salt_size && (!v->version))) {
-   r = verity_hash_update(v, req, v->salt, v->salt_size, res);
+   r = verity_hash_update(v, req, v->salt, v->salt_size, wait);
 
if (r < 0) {
DMERR("verity_hash_final failed updating salt: %d", r);
@@ -187,7 +146,7 @@ static int verity_hash_final(struct dm_verity *v, struct 
ahash_request *req,
}
 
ahash_request_set_crypt(req, NULL, digest, 0);
-   r = verity_complete_op(res, crypto_ahash_final(req));
+   r = crypto_wait_req(crypto_ahash_final(req), wait);
 out:
return r;
 }
@@ -196,17 +155,17 @@ int verity_hash(struct dm_verity *v, struct ahash_request 
*req,
const u8 *data, size_t len, u8 *digest)
 {
int r;
-   struct verity_result res;
+   struct crypto_wait wait;
 
-   r = verity_hash_init(v, req, &res);
+   r = verity_hash_init(v, req, &wait);
if (unlikely(r < 0))
  

[PATCH v9 12/20] fscrypt: move to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
fscrypt starts several async. crypto ops and waiting for them to
complete. Move it over to generic code doing the same.

Signed-off-by: Gilad Ben-Yossef 
---
 fs/crypto/crypto.c  | 28 
 fs/crypto/fname.c   | 36 ++--
 fs/crypto/fscrypt_private.h | 10 --
 fs/crypto/keyinfo.c | 21 +++--
 4 files changed, 13 insertions(+), 82 deletions(-)

diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c
index c7835df..80a3cad 100644
--- a/fs/crypto/crypto.c
+++ b/fs/crypto/crypto.c
@@ -126,21 +126,6 @@ struct fscrypt_ctx *fscrypt_get_ctx(const struct inode 
*inode, gfp_t gfp_flags)
 }
 EXPORT_SYMBOL(fscrypt_get_ctx);
 
-/**
- * page_crypt_complete() - completion callback for page crypto
- * @req: The asynchronous cipher request context
- * @res: The result of the cipher operation
- */
-static void page_crypt_complete(struct crypto_async_request *req, int res)
-{
-   struct fscrypt_completion_result *ecr = req->data;
-
-   if (res == -EINPROGRESS)
-   return;
-   ecr->res = res;
-   complete(&ecr->completion);
-}
-
 int fscrypt_do_page_crypto(const struct inode *inode, fscrypt_direction_t rw,
   u64 lblk_num, struct page *src_page,
   struct page *dest_page, unsigned int len,
@@ -151,7 +136,7 @@ int fscrypt_do_page_crypto(const struct inode *inode, 
fscrypt_direction_t rw,
u8 padding[FS_IV_SIZE - sizeof(__le64)];
} iv;
struct skcipher_request *req = NULL;
-   DECLARE_FS_COMPLETION_RESULT(ecr);
+   DECLARE_CRYPTO_WAIT(wait);
struct scatterlist dst, src;
struct fscrypt_info *ci = inode->i_crypt_info;
struct crypto_skcipher *tfm = ci->ci_ctfm;
@@ -179,7 +164,7 @@ int fscrypt_do_page_crypto(const struct inode *inode, 
fscrypt_direction_t rw,
 
skcipher_request_set_callback(
req, CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP,
-   page_crypt_complete, &ecr);
+   crypto_req_done, &wait);
 
sg_init_table(&dst, 1);
sg_set_page(&dst, dest_page, len, offs);
@@ -187,14 +172,9 @@ int fscrypt_do_page_crypto(const struct inode *inode, 
fscrypt_direction_t rw,
sg_set_page(&src, src_page, len, offs);
skcipher_request_set_crypt(req, &src, &dst, len, &iv);
if (rw == FS_DECRYPT)
-   res = crypto_skcipher_decrypt(req);
+   res = crypto_wait_req(crypto_skcipher_decrypt(req), &wait);
else
-   res = crypto_skcipher_encrypt(req);
-   if (res == -EINPROGRESS || res == -EBUSY) {
-   BUG_ON(req->base.data != &ecr);
-   wait_for_completion(&ecr.completion);
-   res = ecr.res;
-   }
+   res = crypto_wait_req(crypto_skcipher_encrypt(req), &wait);
skcipher_request_free(req);
if (res) {
printk_ratelimited(KERN_ERR
diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c
index ad9f814..a80a0d3 100644
--- a/fs/crypto/fname.c
+++ b/fs/crypto/fname.c
@@ -15,21 +15,6 @@
 #include "fscrypt_private.h"
 
 /**
- * fname_crypt_complete() - completion callback for filename crypto
- * @req: The asynchronous cipher request context
- * @res: The result of the cipher operation
- */
-static void fname_crypt_complete(struct crypto_async_request *req, int res)
-{
-   struct fscrypt_completion_result *ecr = req->data;
-
-   if (res == -EINPROGRESS)
-   return;
-   ecr->res = res;
-   complete(&ecr->completion);
-}
-
-/**
  * fname_encrypt() - encrypt a filename
  *
  * The caller must have allocated sufficient memory for the @oname string.
@@ -40,7 +25,7 @@ static int fname_encrypt(struct inode *inode,
const struct qstr *iname, struct fscrypt_str *oname)
 {
struct skcipher_request *req = NULL;
-   DECLARE_FS_COMPLETION_RESULT(ecr);
+   DECLARE_CRYPTO_WAIT(wait);
struct fscrypt_info *ci = inode->i_crypt_info;
struct crypto_skcipher *tfm = ci->ci_ctfm;
int res = 0;
@@ -76,17 +61,12 @@ static int fname_encrypt(struct inode *inode,
}
skcipher_request_set_callback(req,
CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP,
-   fname_crypt_complete, &ecr);
+   crypto_req_done, &wait);
sg_init_one(&sg, oname->name, cryptlen);
skcipher_request_set_crypt(req, &sg, &sg, cryptlen, iv);
 
/* Do the encryption */
-   res = crypto_skcipher_encrypt(req);
-   if (res == -EINPROGRESS || res == -EBUSY) {
-   /* Request is being completed asynchronously; wait for it */
-   wait_for_completion(&ecr.completion);
-   res = ecr.res;
-   }
+   res = crypto_wait_req(crypto_skcipher_encrypt(req), &wait);
skcipher_request_free(req);
if (res < 0) {
printk_ratelimite

[PATCH v9 17/20] crypto: talitos: move to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
The talitos driver starts several async crypto ops and  waits for their
completions. Move it over to generic code doing the same.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/crypto/talitos.c | 38 +-
 1 file changed, 5 insertions(+), 33 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 5bd8191..9c80e0c 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2160,22 +2160,6 @@ static int ahash_import(struct ahash_request *areq, 
const void *in)
return 0;
 }
 
-struct keyhash_result {
-   struct completion completion;
-   int err;
-};
-
-static void keyhash_complete(struct crypto_async_request *req, int err)
-{
-   struct keyhash_result *res = req->data;
-
-   if (err == -EINPROGRESS)
-   return;
-
-   res->err = err;
-   complete(&res->completion);
-}
-
 static int keyhash(struct crypto_ahash *tfm, const u8 *key, unsigned int 
keylen,
   u8 *hash)
 {
@@ -2183,10 +2167,10 @@ static int keyhash(struct crypto_ahash *tfm, const u8 
*key, unsigned int keylen,
 
struct scatterlist sg[1];
struct ahash_request *req;
-   struct keyhash_result hresult;
+   struct crypto_wait wait;
int ret;
 
-   init_completion(&hresult.completion);
+   crypto_init_wait(&wait);
 
req = ahash_request_alloc(tfm, GFP_KERNEL);
if (!req)
@@ -2195,25 +2179,13 @@ static int keyhash(struct crypto_ahash *tfm, const u8 
*key, unsigned int keylen,
/* Keep tfm keylen == 0 during hash of the long key */
ctx->keylen = 0;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
-  keyhash_complete, &hresult);
+  crypto_req_done, &wait);
 
sg_init_one(&sg[0], key, keylen);
 
ahash_request_set_crypt(req, sg, hash, keylen);
-   ret = crypto_ahash_digest(req);
-   switch (ret) {
-   case 0:
-   break;
-   case -EINPROGRESS:
-   case -EBUSY:
-   ret = wait_for_completion_interruptible(
-   &hresult.completion);
-   if (!ret)
-   ret = hresult.err;
-   break;
-   default:
-   break;
-   }
+   ret = crypto_wait_req(crypto_ahash_digest(req), &wait);
+
ahash_request_free(req);
 
return ret;
-- 
2.7.4



[PATCH v9 18/20] crypto: qce: move to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
The qce driver starts several async crypto ops and  waits for their
completions. Move it over to generic code doing the same.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/crypto/qce/sha.c | 30 --
 1 file changed, 4 insertions(+), 26 deletions(-)

diff --git a/drivers/crypto/qce/sha.c b/drivers/crypto/qce/sha.c
index 47e114a..53227d7 100644
--- a/drivers/crypto/qce/sha.c
+++ b/drivers/crypto/qce/sha.c
@@ -349,28 +349,12 @@ static int qce_ahash_digest(struct ahash_request *req)
return qce->async_req_enqueue(tmpl->qce, &req->base);
 }
 
-struct qce_ahash_result {
-   struct completion completion;
-   int error;
-};
-
-static void qce_digest_complete(struct crypto_async_request *req, int error)
-{
-   struct qce_ahash_result *result = req->data;
-
-   if (error == -EINPROGRESS)
-   return;
-
-   result->error = error;
-   complete(&result->completion);
-}
-
 static int qce_ahash_hmac_setkey(struct crypto_ahash *tfm, const u8 *key,
 unsigned int keylen)
 {
unsigned int digestsize = crypto_ahash_digestsize(tfm);
struct qce_sha_ctx *ctx = crypto_tfm_ctx(&tfm->base);
-   struct qce_ahash_result result;
+   struct crypto_wait wait;
struct ahash_request *req;
struct scatterlist sg;
unsigned int blocksize;
@@ -405,9 +389,9 @@ static int qce_ahash_hmac_setkey(struct crypto_ahash *tfm, 
const u8 *key,
goto err_free_ahash;
}
 
-   init_completion(&result.completion);
+   crypto_init_wait(&wait);
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
-  qce_digest_complete, &result);
+  crypto_req_done, &wait);
crypto_ahash_clear_flags(ahash_tfm, ~0);
 
buf = kzalloc(keylen + QCE_MAX_ALIGN_SIZE, GFP_KERNEL);
@@ -420,13 +404,7 @@ static int qce_ahash_hmac_setkey(struct crypto_ahash *tfm, 
const u8 *key,
sg_init_one(&sg, buf, keylen);
ahash_request_set_crypt(req, &sg, ctx->authkey, keylen);
 
-   ret = crypto_ahash_digest(req);
-   if (ret == -EINPROGRESS || ret == -EBUSY) {
-   ret = wait_for_completion_interruptible(&result.completion);
-   if (!ret)
-   ret = result.error;
-   }
-
+   ret = crypto_wait_req(crypto_ahash_digest(req), &wait);
if (ret)
crypto_ahash_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
 
-- 
2.7.4



[PATCH v9 16/20] crypto: tcrypt: move to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
tcrypt starts several async crypto ops and  waits for their completions.
Move it over to generic code doing the same.

Signed-off-by: Gilad Ben-Yossef 
---
 crypto/tcrypt.c | 84 +
 1 file changed, 25 insertions(+), 59 deletions(-)

diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index a371c072..7fa7047 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -79,34 +79,11 @@ static char *check[] = {
NULL
 };
 
-struct tcrypt_result {
-   struct completion completion;
-   int err;
-};
-
-static void tcrypt_complete(struct crypto_async_request *req, int err)
-{
-   struct tcrypt_result *res = req->data;
-
-   if (err == -EINPROGRESS)
-   return;
-
-   res->err = err;
-   complete(&res->completion);
-}
-
 static inline int do_one_aead_op(struct aead_request *req, int ret)
 {
-   if (ret == -EINPROGRESS || ret == -EBUSY) {
-   struct tcrypt_result *tr = req->base.data;
+   struct crypto_wait *wait = req->base.data;
 
-   ret = wait_for_completion_interruptible(&tr->completion);
-   if (!ret)
-   ret = tr->err;
-   reinit_completion(&tr->completion);
-   }
-
-   return ret;
+   return crypto_wait_req(ret, wait);
 }
 
 static int test_aead_jiffies(struct aead_request *req, int enc,
@@ -248,7 +225,7 @@ static void test_aead_speed(const char *algo, int enc, 
unsigned int secs,
char *axbuf[XBUFSIZE];
unsigned int *b_size;
unsigned int iv_len;
-   struct tcrypt_result result;
+   struct crypto_wait wait;
 
iv = kzalloc(MAX_IVLEN, GFP_KERNEL);
if (!iv)
@@ -284,7 +261,7 @@ static void test_aead_speed(const char *algo, int enc, 
unsigned int secs,
goto out_notfm;
}
 
-   init_completion(&result.completion);
+   crypto_init_wait(&wait);
printk(KERN_INFO "\ntesting speed of %s (%s) %s\n", algo,
get_driver_name(crypto_aead, tfm), e);
 
@@ -296,7 +273,7 @@ static void test_aead_speed(const char *algo, int enc, 
unsigned int secs,
}
 
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- tcrypt_complete, &result);
+ crypto_req_done, &wait);
 
i = 0;
do {
@@ -396,21 +373,16 @@ static void test_hash_sg_init(struct scatterlist *sg)
 
 static inline int do_one_ahash_op(struct ahash_request *req, int ret)
 {
-   if (ret == -EINPROGRESS || ret == -EBUSY) {
-   struct tcrypt_result *tr = req->base.data;
+   struct crypto_wait *wait = req->base.data;
 
-   wait_for_completion(&tr->completion);
-   reinit_completion(&tr->completion);
-   ret = tr->err;
-   }
-   return ret;
+   return crypto_wait_req(ret, wait);
 }
 
 struct test_mb_ahash_data {
struct scatterlist sg[TVMEMSIZE];
char result[64];
struct ahash_request *req;
-   struct tcrypt_result tresult;
+   struct crypto_wait wait;
char *xbuf[XBUFSIZE];
 };
 
@@ -439,7 +411,7 @@ static void test_mb_ahash_speed(const char *algo, unsigned 
int sec,
if (testmgr_alloc_buf(data[i].xbuf))
goto out;
 
-   init_completion(&data[i].tresult.completion);
+   crypto_init_wait(&data[i].wait);
 
data[i].req = ahash_request_alloc(tfm, GFP_KERNEL);
if (!data[i].req) {
@@ -448,8 +420,8 @@ static void test_mb_ahash_speed(const char *algo, unsigned 
int sec,
goto out;
}
 
-   ahash_request_set_callback(data[i].req, 0,
-  tcrypt_complete, &data[i].tresult);
+   ahash_request_set_callback(data[i].req, 0, crypto_req_done,
+  &data[i].wait);
test_hash_sg_init(data[i].sg);
}
 
@@ -491,16 +463,16 @@ static void test_mb_ahash_speed(const char *algo, 
unsigned int sec,
if (ret)
break;
 
-   complete(&data[k].tresult.completion);
-   data[k].tresult.err = 0;
+   crypto_req_done(&data[k].req->base, 0);
}
 
for (j = 0; j < k; j++) {
-   struct tcrypt_result *tr = &data[j].tresult;
+   struct crypto_wait *wait = &data[j].wait;
+   int wait_ret;
 
-   wait_for_completion(&tr->completion);
-   if (tr->err)
-   ret = tr->err;
+   wait_ret = crypto_wait_req(-EINPROGRESS, wait);
+   if (wait_ret)
+   ret = wait_ret;
}
 
end = get_cycles();
@@ -678,7 +650,7 @@ static void test_ahash_speed_com

[PATCH v9 15/20] ima: move to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
ima starts several async crypto ops and  waits for their completions.
Move it over to generic code doing the same.

Signed-off-by: Gilad Ben-Yossef 
Acked-by: Mimi Zohar 
---
 security/integrity/ima/ima_crypto.c | 56 +++--
 1 file changed, 17 insertions(+), 39 deletions(-)

diff --git a/security/integrity/ima/ima_crypto.c 
b/security/integrity/ima/ima_crypto.c
index a856d8c..9057b16 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -27,11 +27,6 @@
 
 #include "ima.h"
 
-struct ahash_completion {
-   struct completion completion;
-   int err;
-};
-
 /* minimum file size for ahash use */
 static unsigned long ima_ahash_minsize;
 module_param_named(ahash_minsize, ima_ahash_minsize, ulong, 0644);
@@ -196,30 +191,13 @@ static void ima_free_atfm(struct crypto_ahash *tfm)
crypto_free_ahash(tfm);
 }
 
-static void ahash_complete(struct crypto_async_request *req, int err)
+static inline int ahash_wait(int err, struct crypto_wait *wait)
 {
-   struct ahash_completion *res = req->data;
 
-   if (err == -EINPROGRESS)
-   return;
-   res->err = err;
-   complete(&res->completion);
-}
+   err = crypto_wait_req(err, wait);
 
-static int ahash_wait(int err, struct ahash_completion *res)
-{
-   switch (err) {
-   case 0:
-   break;
-   case -EINPROGRESS:
-   case -EBUSY:
-   wait_for_completion(&res->completion);
-   reinit_completion(&res->completion);
-   err = res->err;
-   /* fall through */
-   default:
+   if (err)
pr_crit_ratelimited("ahash calculation failed: err: %d\n", err);
-   }
 
return err;
 }
@@ -233,7 +211,7 @@ static int ima_calc_file_hash_atfm(struct file *file,
int rc, read = 0, rbuf_len, active = 0, ahash_rc = 0;
struct ahash_request *req;
struct scatterlist sg[1];
-   struct ahash_completion res;
+   struct crypto_wait wait;
size_t rbuf_size[2];
 
hash->length = crypto_ahash_digestsize(tfm);
@@ -242,12 +220,12 @@ static int ima_calc_file_hash_atfm(struct file *file,
if (!req)
return -ENOMEM;
 
-   init_completion(&res.completion);
+   crypto_init_wait(&wait);
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG |
   CRYPTO_TFM_REQ_MAY_SLEEP,
-  ahash_complete, &res);
+  crypto_req_done, &wait);
 
-   rc = ahash_wait(crypto_ahash_init(req), &res);
+   rc = ahash_wait(crypto_ahash_init(req), &wait);
if (rc)
goto out1;
 
@@ -288,7 +266,7 @@ static int ima_calc_file_hash_atfm(struct file *file,
 * read/request, wait for the completion of the
 * previous ahash_update() request.
 */
-   rc = ahash_wait(ahash_rc, &res);
+   rc = ahash_wait(ahash_rc, &wait);
if (rc)
goto out3;
}
@@ -304,7 +282,7 @@ static int ima_calc_file_hash_atfm(struct file *file,
 * read/request, wait for the completion of the
 * previous ahash_update() request.
 */
-   rc = ahash_wait(ahash_rc, &res);
+   rc = ahash_wait(ahash_rc, &wait);
if (rc)
goto out3;
}
@@ -318,7 +296,7 @@ static int ima_calc_file_hash_atfm(struct file *file,
active = !active; /* swap buffers, if we use two */
}
/* wait for the last update request to complete */
-   rc = ahash_wait(ahash_rc, &res);
+   rc = ahash_wait(ahash_rc, &wait);
 out3:
if (read)
file->f_mode &= ~FMODE_READ;
@@ -327,7 +305,7 @@ static int ima_calc_file_hash_atfm(struct file *file,
 out2:
if (!rc) {
ahash_request_set_crypt(req, NULL, hash->digest, 0);
-   rc = ahash_wait(crypto_ahash_final(req), &res);
+   rc = ahash_wait(crypto_ahash_final(req), &wait);
}
 out1:
ahash_request_free(req);
@@ -537,7 +515,7 @@ static int calc_buffer_ahash_atfm(const void *buf, loff_t 
len,
 {
struct ahash_request *req;
struct scatterlist sg;
-   struct ahash_completion res;
+   struct crypto_wait wait;
int rc, ahash_rc = 0;
 
hash->length = crypto_ahash_digestsize(tfm);
@@ -546,12 +524,12 @@ static int calc_buffer_ahash_atfm(const void *buf, loff_t 
len,
if (!req)
return -ENOMEM;
 
-   init_completion(&res.completion);
+   crypto_init_wait(&wait);
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG |
   CRYPTO_TFM_REQ_MAY_SLEEP,
-   

[PATCH v9 14/20] cifs: move to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
cifs starts an async. crypto op and waits for their completion.
Move it over to generic code doing the same.

Signed-off-by: Gilad Ben-Yossef 
Acked-by: Pavel Shilovsky 
---
 fs/cifs/smb2ops.c | 30 --
 1 file changed, 4 insertions(+), 26 deletions(-)

diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
index bdb963d..e067404 100644
--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -2087,22 +2087,6 @@ init_sg(struct smb_rqst *rqst, u8 *sign)
return sg;
 }
 
-struct cifs_crypt_result {
-   int err;
-   struct completion completion;
-};
-
-static void cifs_crypt_complete(struct crypto_async_request *req, int err)
-{
-   struct cifs_crypt_result *res = req->data;
-
-   if (err == -EINPROGRESS)
-   return;
-
-   res->err = err;
-   complete(&res->completion);
-}
-
 static int
 smb2_get_enc_key(struct TCP_Server_Info *server, __u64 ses_id, int enc, u8 
*key)
 {
@@ -2143,12 +2127,10 @@ crypt_message(struct TCP_Server_Info *server, struct 
smb_rqst *rqst, int enc)
struct aead_request *req;
char *iv;
unsigned int iv_len;
-   struct cifs_crypt_result result = {0, };
+   DECLARE_CRYPTO_WAIT(wait);
struct crypto_aead *tfm;
unsigned int crypt_len = le32_to_cpu(tr_hdr->OriginalMessageSize);
 
-   init_completion(&result.completion);
-
rc = smb2_get_enc_key(server, tr_hdr->SessionId, enc, key);
if (rc) {
cifs_dbg(VFS, "%s: Could not get %scryption key\n", __func__,
@@ -2208,14 +2190,10 @@ crypt_message(struct TCP_Server_Info *server, struct 
smb_rqst *rqst, int enc)
aead_request_set_ad(req, assoc_data_len);
 
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- cifs_crypt_complete, &result);
+ crypto_req_done, &wait);
 
-   rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);
-
-   if (rc == -EINPROGRESS || rc == -EBUSY) {
-   wait_for_completion(&result.completion);
-   rc = result.err;
-   }
+   rc = crypto_wait_req(enc ? crypto_aead_encrypt(req)
+   : crypto_aead_decrypt(req), &wait);
 
if (!rc && enc)
memcpy(&tr_hdr->Signature, sign, SMB2_SIGNATURE_SIZE);
-- 
2.7.4



[PATCH v9 19/20] crypto: mediatek: move to generic async completion

2017-10-15 Thread Gilad Ben-Yossef
The mediatek driver starts several async crypto ops and waits for their
completions. Move it over to generic code doing the same.

Signed-off-by: Gilad Ben-Yossef 
Acked-by: Ryder Lee 
---
 drivers/crypto/mediatek/mtk-aes.c | 31 +--
 1 file changed, 5 insertions(+), 26 deletions(-)

diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
index 32aa587..c2058cf 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -138,11 +138,6 @@ struct mtk_aes_gcm_ctx {
struct crypto_skcipher *ctr;
 };
 
-struct mtk_aes_gcm_setkey_result {
-   int err;
-   struct completion completion;
-};
-
 struct mtk_aes_drv {
struct list_head dev_list;
/* Device list lock */
@@ -942,17 +937,6 @@ static int mtk_aes_gcm_crypt(struct aead_request *req, u64 
mode)
&req->base);
 }
 
-static void mtk_gcm_setkey_done(struct crypto_async_request *req, int err)
-{
-   struct mtk_aes_gcm_setkey_result *result = req->data;
-
-   if (err == -EINPROGRESS)
-   return;
-
-   result->err = err;
-   complete(&result->completion);
-}
-
 /*
  * Because of the hardware limitation, we need to pre-calculate key(H)
  * for the GHASH operation. The result of the encryption operation
@@ -968,7 +952,7 @@ static int mtk_aes_gcm_setkey(struct crypto_aead *aead, 
const u8 *key,
u32 hash[4];
u8 iv[8];
 
-   struct mtk_aes_gcm_setkey_result result;
+   struct crypto_wait wait;
 
struct scatterlist sg[1];
struct skcipher_request req;
@@ -1008,22 +992,17 @@ static int mtk_aes_gcm_setkey(struct crypto_aead *aead, 
const u8 *key,
if (!data)
return -ENOMEM;
 
-   init_completion(&data->result.completion);
+   crypto_init_wait(&data->wait);
sg_init_one(data->sg, &data->hash, AES_BLOCK_SIZE);
skcipher_request_set_tfm(&data->req, ctr);
skcipher_request_set_callback(&data->req, CRYPTO_TFM_REQ_MAY_SLEEP |
  CRYPTO_TFM_REQ_MAY_BACKLOG,
- mtk_gcm_setkey_done, &data->result);
+ crypto_req_done, &data->wait);
skcipher_request_set_crypt(&data->req, data->sg, data->sg,
   AES_BLOCK_SIZE, data->iv);
 
-   err = crypto_skcipher_encrypt(&data->req);
-   if (err == -EINPROGRESS || err == -EBUSY) {
-   err = wait_for_completion_interruptible(
-   &data->result.completion);
-   if (!err)
-   err = data->result.err;
-   }
+   err = crypto_wait_req(crypto_skcipher_encrypt(&data->req),
+ &data->wait);
if (err)
goto out;
 
-- 
2.7.4



[PATCH v9 20/20] crypto: adapt api sample to use async. op wait

2017-10-15 Thread Gilad Ben-Yossef
The code sample is waiting for an async. crypto op completion.
Adapt sample to use the new generic infrastructure to do the same.

This also fixes a possible data coruption bug created by the
use of wait_for_completion_interruptible() without dealing
correctly with an interrupt aborting the wait prior to the
async op finishing.

Signed-off-by: Gilad Ben-Yossef 
---
 Documentation/crypto/api-samples.rst | 52 +++-
 1 file changed, 10 insertions(+), 42 deletions(-)

diff --git a/Documentation/crypto/api-samples.rst 
b/Documentation/crypto/api-samples.rst
index 2531948..006827e 100644
--- a/Documentation/crypto/api-samples.rst
+++ b/Documentation/crypto/api-samples.rst
@@ -7,59 +7,27 @@ Code Example For Symmetric Key Cipher Operation
 ::
 
 
-struct tcrypt_result {
-struct completion completion;
-int err;
-};
-
 /* tie all data structures together */
 struct skcipher_def {
 struct scatterlist sg;
 struct crypto_skcipher *tfm;
 struct skcipher_request *req;
-struct tcrypt_result result;
+struct crypto_wait wait;
 };
 
-/* Callback function */
-static void test_skcipher_cb(struct crypto_async_request *req, int error)
-{
-struct tcrypt_result *result = req->data;
-
-if (error == -EINPROGRESS)
-return;
-result->err = error;
-complete(&result->completion);
-pr_info("Encryption finished successfully\n");
-}
-
 /* Perform cipher operation */
 static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
  int enc)
 {
-int rc = 0;
+int rc;
 
 if (enc)
-rc = crypto_skcipher_encrypt(sk->req);
+rc = crypto_wait_req(crypto_skcipher_encrypt(sk->req), &sk->wait);
 else
-rc = crypto_skcipher_decrypt(sk->req);
-
-switch (rc) {
-case 0:
-break;
-case -EINPROGRESS:
-case -EBUSY:
-rc = wait_for_completion_interruptible(
-&sk->result.completion);
-if (!rc && !sk->result.err) {
-reinit_completion(&sk->result.completion);
-break;
-}
-default:
-pr_info("skcipher encrypt returned with %d result %d\n",
-rc, sk->result.err);
-break;
-}
-init_completion(&sk->result.completion);
+rc = crypto_wait_req(crypto_skcipher_decrypt(sk->req), &sk->wait);
+
+   if (rc)
+   pr_info("skcipher encrypt returned with result %d\n", rc);
 
 return rc;
 }
@@ -89,8 +57,8 @@ Code Example For Symmetric Key Cipher Operation
 }
 
 skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
-  test_skcipher_cb,
-  &sk.result);
+  crypto_req_done,
+  &sk.wait);
 
 /* AES 256 with random key */
 get_random_bytes(&key, 32);
@@ -122,7 +90,7 @@ Code Example For Symmetric Key Cipher Operation
 /* We encrypt one block */
 sg_init_one(&sk.sg, scratchpad, 16);
 skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata);
-init_completion(&sk.result.completion);
+crypto_init_wait(&sk.wait);
 
 /* encrypt data */
 ret = test_skcipher_encdec(&sk, 1);
-- 
2.7.4



Re: x86/mce: suspicious RCU usage in 4.13.4

2017-10-15 Thread Borislav Petkov
On Wed, Oct 11, 2017 at 09:34:22PM +, Luck, Tony wrote:
> > here's a second attempt at a more rigorous simplification: RCU stuff is
> > gone and only a single loop scans through the elements.
> 
> The dev_mce_log() changes look good now.
> 
> You can apply the axe to more bits of mce_chrdev_read() though. Like that

That provoked a very serious axing. Please check whether I went too far. Hunk
below is ontop of what got axed already:

---
diff --git a/arch/x86/kernel/cpu/mcheck/dev-mcelog.c 
b/arch/x86/kernel/cpu/mcheck/dev-mcelog.c
index 1e1c6d22c93e..17d2bab25720 100644
--- a/arch/x86/kernel/cpu/mcheck/dev-mcelog.c
+++ b/arch/x86/kernel/cpu/mcheck/dev-mcelog.c
@@ -162,13 +162,6 @@ static int mce_chrdev_release(struct inode *inode, struct 
file *file)
return 0;
 }
 
-static void collect_tscs(void *data)
-{
-   unsigned long *cpu_tsc = (unsigned long *)data;
-
-   cpu_tsc[smp_processor_id()] = rdtsc();
-}
-
 static int mce_apei_read_done;
 
 /* Collect MCE record of previous boot in persistent storage via APEI ERST. */
@@ -216,14 +209,9 @@ static ssize_t mce_chrdev_read(struct file *filp, char 
__user *ubuf,
size_t usize, loff_t *off)
 {
char __user *buf = ubuf;
-   unsigned long *cpu_tsc;
-   unsigned prev, next;
+   unsigned next;
int i, err;
 
-   cpu_tsc = kmalloc(nr_cpu_ids * sizeof(long), GFP_KERNEL);
-   if (!cpu_tsc)
-   return -ENOMEM;
-
mutex_lock(&mce_chrdev_read_mutex);
 
if (!mce_apei_read_done) {
@@ -232,63 +220,32 @@ static ssize_t mce_chrdev_read(struct file *filp, char 
__user *ubuf,
goto out;
}
 
-   next = mcelog.next;
-
/* Only supports full reads right now */
err = -EINVAL;
if (*off != 0 || usize < MCE_LOG_LEN*sizeof(struct mce))
goto out;
 
+   next = mcelog.next;
err = 0;
-   prev = 0;
-   do {
-   for (i = prev; i < next; i++) {
-   unsigned long start = jiffies;
-   struct mce *m = &mcelog.entry[i];
-
-   while (!m->finished) {
-   if (time_after_eq(jiffies, start + 2)) {
-   memset(m, 0, sizeof(*m));
-   goto timeout;
-   }
-   cpu_relax();
-   }
-   smp_rmb();
-   err |= copy_to_user(buf, m, sizeof(*m));
-   buf += sizeof(*m);
-timeout:
-   ;
-   }
-
-   memset(mcelog.entry + prev, 0,
-  (next - prev) * sizeof(struct mce));
-   prev = next;
-   next = cmpxchg(&mcelog.next, prev, 0);
-   } while (next != prev);
-
-   /*
-* Collect entries that were still getting written before the
-* synchronize.
-*/
-   on_each_cpu(collect_tscs, cpu_tsc, 1);
 
-   for (i = next; i < MCE_LOG_LEN; i++) {
+   for (i = 0; i < next; i++) {
struct mce *m = &mcelog.entry[i];
 
-   if (m->finished && m->tsc < cpu_tsc[m->cpu]) {
-   err |= copy_to_user(buf, m, sizeof(*m));
-   smp_rmb();
-   buf += sizeof(*m);
-   memset(m, 0, sizeof(*m));
-   }
+   if (!m->finished)
+   continue;
+
+   err |= copy_to_user(buf, m, sizeof(*m));
+   buf += sizeof(*m);
}
 
+   memset(mcelog.entry, 0, next * sizeof(struct mce));
+   mcelog.next = 0;
+
if (err)
err = -EFAULT;
 
 out:
mutex_unlock(&mce_chrdev_read_mutex);
-   kfree(cpu_tsc);
 
return err ? err : buf - ubuf;
 }

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


[PATCH] docs: dev-tools: correct Coccinelle version number

2017-10-15 Thread Julia Lawall
There is no Coccinelle version 1.2.  1.0.2 must be what was intended.

Signed-off-by: Julia Lawall 

---
 Documentation/dev-tools/coccinelle.rst |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/dev-tools/coccinelle.rst 
b/Documentation/dev-tools/coccinelle.rst
index 4a64b4c..37e474f 100644
--- a/Documentation/dev-tools/coccinelle.rst
+++ b/Documentation/dev-tools/coccinelle.rst
@@ -209,7 +209,7 @@ err.log will now have the profiling information, while 
stdout will
 provide some progress information as Coccinelle moves forward with
 work.
 
-DEBUG_FILE support is only supported when using coccinelle >= 1.2.
+DEBUG_FILE support is only supported when using coccinelle >= 1.0.2.
 
 .cocciconfig support
 



RFC: making cn_proc work in {pid,user} namespaces

2017-10-15 Thread Aleksa Sarai

Hi all,

At the moment, cn_proc is not usable by containers or container 
runtimes. In addition, all connectors have an odd relationship with 
init_net (for example, /proc/net/connectors only exists in init_net). 
There are two main use-cases that would be perfect for cn_proc, which is 
the reason for me pushing this:


First, when adding a process to an existing container, in certain modes 
runc would like to know that process's exit code. But, when joining a 
PID namespace, it is advisable[1] to always double-fork after doing the 
setns(2) to reparent the joining process to the init of the container 
(this causes the SIGCHLD to be received by the container init). It would 
also be useful to be able to monitor the exit code of the init process 
in a container without being its parent. At the moment, cn_proc doesn't 
allow unprivileged users to use it (making it a problem for user 
namespaces and "rootless containers"). In addition, it also doesn't 
allow nested containers to use it, because it requires the process to be 
in init_pid. As a result, runc cannot use cn_proc and relies on SIGCHLD 
(which can only be used if we don't double-fork, or keep around a 
long-running process which is something that runc also cannot do).


Secondly, there are/were some init systems that rely on cn_proc to 
manage service state. From a "it would be neat" perspective, I think it 
would be quite nice if such init systems could be used inside 
containers. But that requires cn_proc to be able to be used as an 
unprivileged user and in a pid namespace other than init_pid.


The /proc/net/connectors thing is quite easily resolved (just make it 
the connector driver perdev and make some small changes to make sure the 
interfaces stay sane inside of a container's network namespace). I'm 
sure that we'll probably have to make some changes to the registration 
API, so that a connector can specify whether they want to be visible to 
non-init_net namespaces.


However, the cn_proc problem is a bit harder to resolve nicely and there 
are quite a few interface questions that would need to be agreed upon. 
The basic idea would be that a process can only get cn_proc events if it 
has ptrace_may_access rights over said process (effectively a forced 
filter -- which would ideally be done send-side but it looks like it 
might have to be done receive-side). This should resolve possible 
concerns about an unprivileged process being able to inspect (fairly 
granular) information about the host. And obviously the pids, uids, and 
gids would all be translated according to the receiving process's user 
namespaces (if it cannot be translated then the message is not 
received). I guess that the translation would be done in the same way as 
SCM_CREDENTIALS (and cgroup.procs files), which is that it's done on the 
receive side not the send side.


My reason for sending this email rather than just writing the patch is 
to see whether anyone has any solid NACKs against the use-case or 
whether there is some fundamental issue that I'm not seeing. If nobody 
objects, I'll be happy to work on this.


[1]: https://lwn.net/Articles/532748/

--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/


Re: [PATCH v2 3/5] iio: adc: at91-sama5d2_adc: add support for DMA

2017-10-15 Thread Jonathan Cameron
On Wed, 11 Oct 2017 09:35:30 +0300
Eugen Hristev  wrote:

> Added support for DMA transfers. The implementation uses the user watermark
> to decide whether DMA will be used or not. For watermark 1, DMA will not be
> used. If watermark is bigger, DMA will be used.
> Sysfs attributes are created to indicate whether the DMA is used,
> with hwfifo_enabled, and the current DMA watermark is readable
> in hwfifo_watermark. Minimum and maximum values are in hwfifo_watermark_min
> and hwfifo_watermark_max.
> 
> Signed-off-by: Eugen Hristev 

You have shrunk the size of the buffer passed to
iio_push_to_buffers_with_timestamp in the non DMA case such that it is
no longer big enough to take the timestamp (the data is used in place
in that call so we need the extra space).

Other than that (and what I think is a missleading dev_info) I think
this is looking pretty good.

Lars if you have time to look at this one that would be great as 
your knowledge of the dmaengine stuff is better than mine.

Jonathan

> ---
>   Changes in v2:
>  - No longer add last timestamp to all samples. Now, compute an interval
> between samples w.r.t. start and end time of the transfer and number
> of samples. Then distribute them each in the time interval.
>  - Add warning for conversion overrun. This helps user identify cases
> when the watermark needs adjustment : the software is too slow in reading
> data from the ADC.
>  - Protection around watermark is not needed, changing of the watermark
> cannot be done while the buffer is enabled. When buffer is disabled, all
> DMA resources are freed anyway.
>  - Added validation on trigger to be used by own device
>  - Best sample rate I could obtain using the low frequency clock was about
> 4k samples/second, with a watermark of 100. To get up to 50k samples/second
> the ADC frequency must be increased to max.
>  - Fixed computation of DMA buffer size
>  - Addressed other comments from mailing list review. Feedback is appreciated
> 
>  drivers/iio/adc/Kconfig|   1 +
>  drivers/iio/adc/at91-sama5d2_adc.c | 432 
> +++--
>  2 files changed, 415 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 5762565..9ef288f 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -158,6 +158,7 @@ config AT91_SAMA5D2_ADC
>   tristate "Atmel AT91 SAMA5D2 ADC"
>   depends on ARCH_AT91 || COMPILE_TEST
>   depends on HAS_IOMEM
> + depends on HAS_DMA
>   select IIO_TRIGGERED_BUFFER
>   help
> Say yes here to build support for Atmel SAMA5D2 ADC which is
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c 
> b/drivers/iio/adc/at91-sama5d2_adc.c
> index bc5b38e..7a9305a 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -16,6 +16,8 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -100,6 +102,8 @@
>  #define AT91_SAMA5D2_LCDR0x20
>  /* Interrupt Enable Register */
>  #define AT91_SAMA5D2_IER 0x24
> +/* Interrupt Enable Register - general overrun error */
> +#define AT91_SAMA5D2_IER_GOVRE BIT(25)
>  /* Interrupt Disable Register */
>  #define AT91_SAMA5D2_IDR 0x28
>  /* Interrupt Mask Register */
> @@ -167,13 +171,16 @@
>  
>  /*
>   * Maximum number of bytes to hold conversion from all channels
> - * plus the timestamp
> + * without the timestamp.
>   */
>  #define AT91_BUFFER_MAX_BYTES ((AT91_SAMA5D2_SINGLE_CHAN_CNT +   
> \
> - AT91_SAMA5D2_DIFF_CHAN_CNT) * 2 + 8)
> + AT91_SAMA5D2_DIFF_CHAN_CNT) * 2)
>  
>  #define AT91_BUFFER_MAX_HWORDS (AT91_BUFFER_MAX_BYTES / 2)
>  
> +#define AT91_HWFIFO_MAX_SIZE_STR "128"
> +#define AT91_HWFIFO_MAX_SIZE 128
> +
>  #define AT91_SAMA5D2_CHAN_SINGLE(num, addr)  \
>   {   \
>   .type = IIO_VOLTAGE,\
> @@ -227,6 +234,28 @@ struct at91_adc_trigger {
>   unsigned intedge_type;
>  };
>  
> +/**
> + * at91_adc_dma - at91-sama5d2 dma information struct
> + * @dma_chan:the dma channel acquired
> + * @rx_buf:  dma coherent allocated area
> + * @rx_dma_buf:  dma handler for the buffer
> + * @phys_addr:   physical address of the ADC base register
> + * @buf_idx: index inside the dma buffer where reading was last done
> + * @rx_buf_sz:   size of buffer used by DMA operation
> + * @watermark:   number of conversions to copy before DMA 
> triggers irq
> + * @dma_ts:  hold the start timestamp of dma operation
> + */
> +struct at91_adc_dma {
> + struct dma_chan *dma_chan;
> + u8  *rx_buf;
> + dma_addr_t  rx_dma_buf;
> + phys_addr_t 

[PATCH] Coccinelle: make DEBUG_FILE option more useful

2017-10-15 Thread Julia Lawall
Make coccicheck checked for the existence of DEBUG_FILE on each semantic
patch, and bailed if it already existed.  This meant that DEBUG_FILE was
useless for checking more than one semantic patch at a time.  Now the check
is moved to the start of make coccicheck, and the 2> is changed to a 2>> to
append to the file on each semantic patch.  Furthermore, the spatch command
that is run for each semantic patch is also added to the DEBUG_FILE, to
make clear what each stdout trace corresponds to.

Signed-off-by: Julia Lawall 

---
 scripts/coccicheck |   21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/scripts/coccicheck b/scripts/coccicheck
index ec487b8..3e21a1b 100755
--- a/scripts/coccicheck
+++ b/scripts/coccicheck
@@ -122,15 +122,8 @@ run_cmd_parmap() {
if [ $VERBOSE -ne 0 ] ; then
echo "Running ($NPROC in parallel): $@"
fi
-   if [ "$DEBUG_FILE" != "/dev/null" -a "$DEBUG_FILE" != "" ]; then
-   if [ -f $DEBUG_FILE ]; then
-   echo "Debug file $DEBUG_FILE exists, bailing"
-   exit
-   fi
-   else
-   DEBUG_FILE="/dev/null"
-   fi
-   $@ 2>$DEBUG_FILE
+   echo $@ >>$DEBUG_FILE
+   $@ 2>>$DEBUG_FILE
if [[ $? -ne 0 ]]; then
echo "coccicheck failed"
exit $?
@@ -246,6 +239,16 @@ coccinelle () {
 
 }
 
+if [ "$DEBUG_FILE" != "/dev/null" -a "$DEBUG_FILE" != "" ]; then
+   if [ -f $DEBUG_FILE ]; then
+   echo "Debug file $DEBUG_FILE exists, bailing"
+   exit
+   fi
+   touch $DEBUG_FILE
+else
+   DEBUG_FILE="/dev/null"
+fi
+
 if [ "$COCCI" = "" ] ; then
 for f in `find $srctree/scripts/coccinelle/ -name '*.cocci' -type f | 
sort`; do
coccinelle $f



Re: [PATCH v2 5/5] iio: adc: at91-sama5d2_adc: use max sample rate

2017-10-15 Thread Jonathan Cameron
On Wed, 11 Oct 2017 09:35:32 +0300
Eugen Hristev  wrote:

> Change driver settings to use maximum sample rate clock.
> This is useful to achieve best possible sampling rate
> if we use DMA.
> 
> Signed-off-by: Eugen Hristev 

I would normally expect this to have some bearing on the 
noise levels on the measured signals.  All I can find
is a reference to the track time being 15*a single
clock cycle.  We could change this so that it is appropriate
for the currently samping frequency rather than leaving it
as a fixed value.

Jonathan

> ---
>  drivers/iio/adc/at91-sama5d2_adc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c 
> b/drivers/iio/adc/at91-sama5d2_adc.c
> index 7e51ecb..b76f88f 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -934,7 +934,7 @@ static void at91_adc_hw_init(struct at91_adc_state *st)
>   at91_adc_writel(st, AT91_SAMA5D2_MR,
>   AT91_SAMA5D2_MR_TRANSFER(2) | AT91_SAMA5D2_MR_ANACH);
>  
> - at91_adc_setup_samp_freq(st, st->soc_info.min_sample_rate);
> + at91_adc_setup_samp_freq(st, st->soc_info.max_sample_rate);
>  }
>  
>  static ssize_t at91_adc_get_fifo_state(struct device *dev,



Re: [PATCH 0/3] Enable CEC on rk3399

2017-10-15 Thread Hans Verkuil
On 10/14/2017 04:52 PM, Heiko Stuebner wrote:
> Am Samstag, 14. Oktober 2017, 15:14:40 CEST schrieb Pierre-Hugues Husson:
>> Hi Hans,
>>
>>> Nice! I had a similar dw-hdmi.c patch pending but got around to posting it.
>>>
>>> I'll brush off my old rk3288 patches and see if I can get CEC enabled
>>> for my firefly-reload. I was close to getting it work, but I guess
>>> missed the "enable cec pin" change.
>> Please note that on rk3288, there are two CEC pins, and you must write
>> in RK3288_GRF_SOC_CON8 which pin you're using.
>> On the firefly-reload, the pin used is GPIO7C0, while the default pin
>> configuration is GPIO7C7.
> 
> And as an additional note, later socs have even more of these pin-routing
> settings and we currently have infrastructure in the pinctrl driver to do
> this automatically depending on the pinctrl settings.
> 
> So most likely this can also be added there for the rk3288.
> 
> 
> Heiko
> 

How does 'GPIO7C0' translate to a 'rockchip,pins' line?

I have this in rk3288-firefly-reload.dts:

   hdmi {
hdmi_cec: hdmi-cec {
rockchip,pins = <7 16 RK_FUNC_2 &pcfg_pull_none>;
};
};

I think this is correct. You can find my patches for the firefly reload here:

https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=firefly2

I don't have access to my firefly reload until Friday, so I can't test this
until then.

I'd be very grateful though if you can check the last three patches in that
branch. It's just a test branch, so the subject/changelog of those patches
are incomplete.

The very last patch adds CEC support for the firefly/firefly beta. I don't
have that hardware, so I won't be able to test that.

Regards,

Hans


[PATCH] Bluetooth: hci_ldisc: Allow sleeping while proto locks are held.

2017-10-15 Thread =?UTF-8?q?Ronald=20Tschal=C3=A4r?=
Commit dec2c92880cc5435381d50e3045ef018a762a917 ("Bluetooth: hci_ldisc:
Use rwlocking to avoid closing proto races") introduced locks in
hci_ldisc that are held while calling the proto functions. These locks
are rwlock's, and hence do not allow sleeping while they are held.
However, the proto functions that hci_bcm registers use mutexes and
hence need to be able to sleep.

In more detail: hci_uart_tty_receive() and hci_uart_dequeue() both
acquire the rwlock, after which they call proto->recv() and
proto->dequeue(), respectively. In the case of hci_bcm these point to
bcm_recv() and bcm_dequeue(). The latter both acquire the
bcm_device_lock, which is a mutex, so doing so results in a call to
might_sleep(). But since we're holding a rwlock in hci_ldisc, that
results in the following BUG (this for the dequeue case - a similar
one for the receive case is omitted for brevity):

  BUG: sleeping function called from invalid context at kernel/locking/mutex.c
  in_atomic(): 1, irqs_disabled(): 0, pid: 7303, name: kworker/7:3
  INFO: lockdep is turned off.
  CPU: 7 PID: 7303 Comm: kworker/7:3 Tainted: GW  OE   4.13.2+ #17
  Hardware name: Apple Inc. MacBookPro13,3/Mac-A5C67F76ED83108C, BIOS MBP133.8
  Workqueue: events hci_uart_write_work [hci_uart]
  Call Trace:
   dump_stack+0x8e/0xd6
   ___might_sleep+0x164/0x250
   __might_sleep+0x4a/0x80
   __mutex_lock+0x59/0xa00
   ? lock_acquire+0xa3/0x1f0
   ? lock_acquire+0xa3/0x1f0
   ? hci_uart_write_work+0xd3/0x160 [hci_uart]
   mutex_lock_nested+0x1b/0x20
   ? mutex_lock_nested+0x1b/0x20
   bcm_dequeue+0x21/0xc0 [hci_uart]
   hci_uart_write_work+0xe6/0x160 [hci_uart]
   process_one_work+0x253/0x6a0
   worker_thread+0x4d/0x3b0
   kthread+0x133/0x150

We can't replace the mutex in hci_bcm, because there are other calls
there that might sleep. Therefore this replaces the rwlock's in
hci_ldisc with rw_semaphore's (which allow sleeping). This is a safer
approach anyway as it reduces the restrictions on the proto callbacks.
Also, because acquiring write-lock is very rare compared to acquiring
the read-lock, the percpu variant of rw_semaphore is used.

Lastly, the read-lock in the hci_uart_tx_wakeup() callback now needed
to be removed because that function is called from an IRQ context. But
since it doesn't actually call any proto functions, instead just
queueing the work, and the other operations are atomic bit operations,
this is ok.

Signed-off-by: Ronald Tschalär 
Cc: Lukas Wunner 
Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Cc: Dean Jenkins 
---
 drivers/bluetooth/hci_ldisc.c | 31 +--
 drivers/bluetooth/hci_uart.h  |  2 +-
 2 files changed, 14 insertions(+), 19 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index eec95019f15c..08bcb1239aa0 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -115,12 +115,12 @@ static inline struct sk_buff *hci_uart_dequeue(struct 
hci_uart *hu)
struct sk_buff *skb = hu->tx_skb;
 
if (!skb) {
-   read_lock(&hu->proto_lock);
+   percpu_down_read(&hu->proto_lock);
 
if (test_bit(HCI_UART_PROTO_READY, &hu->flags))
skb = hu->proto->dequeue(hu);
 
-   read_unlock(&hu->proto_lock);
+   percpu_up_read(&hu->proto_lock);
} else {
hu->tx_skb = NULL;
}
@@ -130,8 +130,6 @@ static inline struct sk_buff *hci_uart_dequeue(struct 
hci_uart *hu)
 
 int hci_uart_tx_wakeup(struct hci_uart *hu)
 {
-   read_lock(&hu->proto_lock);
-
if (!test_bit(HCI_UART_PROTO_READY, &hu->flags))
goto no_schedule;
 
@@ -145,8 +143,6 @@ int hci_uart_tx_wakeup(struct hci_uart *hu)
schedule_work(&hu->write_work);
 
 no_schedule:
-   read_unlock(&hu->proto_lock);
-
return 0;
 }
 EXPORT_SYMBOL_GPL(hci_uart_tx_wakeup);
@@ -247,12 +243,12 @@ static int hci_uart_flush(struct hci_dev *hdev)
tty_ldisc_flush(tty);
tty_driver_flush_buffer(tty);
 
-   read_lock(&hu->proto_lock);
+   percpu_down_read(&hu->proto_lock);
 
if (test_bit(HCI_UART_PROTO_READY, &hu->flags))
hu->proto->flush(hu);
 
-   read_unlock(&hu->proto_lock);
+   percpu_up_read(&hu->proto_lock);
 
return 0;
 }
@@ -275,15 +271,15 @@ static int hci_uart_send_frame(struct hci_dev *hdev, 
struct sk_buff *skb)
BT_DBG("%s: type %d len %d", hdev->name, hci_skb_pkt_type(skb),
   skb->len);
 
-   read_lock(&hu->proto_lock);
+   percpu_down_read(&hu->proto_lock);
 
if (!test_bit(HCI_UART_PROTO_READY, &hu->flags)) {
-   read_unlock(&hu->proto_lock);
+   percpu_up_read(&hu->proto_lock);
return -EUNATCH;
}
 
hu->proto->enqueue(hu, skb);
-   read_unlock(&hu->proto_lock);
+   percpu_up_read(&hu->proto_lock);
 
hci_uart_tx_wakeup(hu);
 
@@ -486,7 +482,7 @@ static int hci

Re: [PATCH] PCI: endpoint: make config_item_type const

2017-10-15 Thread kbuild test robot
Hi Bhumika,

[auto build test WARNING on pci/next]
[also build test WARNING on v4.14-rc4 next-20171013]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Bhumika-Goyal/PCI-endpoint-make-config_item_type-const/20171015-175843
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-randconfig-s1-201742+CONFIG_DEBUG_INFO_REDUCED (attached as 
.config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/pci/endpoint/pci-ep-cfs.c: In function 'pci_ep_cfs_add_epc_group':
>> drivers/pci/endpoint/pci-ep-cfs.c:174:43: warning: passing argument 3 of 
>> 'config_group_init_type_name' discards 'const' qualifier from pointer target 
>> type [-Wdiscarded-qualifiers]
 config_group_init_type_name(group, name, &pci_epc_type);
  ^
   In file included from include/linux/pci-ep-cfs.h:15:0,
from drivers/pci/endpoint/pci-ep-cfs.c:25:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/pci/endpoint/pci-ep-cfs.c: In function 'pci_epf_make':
   drivers/pci/endpoint/pci-ep-cfs.c:380:55: warning: passing argument 3 of 
'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
 config_group_init_type_name(&epf_group->group, name, &pci_epf_type);
  ^
   In file included from include/linux/pci-ep-cfs.h:15:0,
from drivers/pci/endpoint/pci-ep-cfs.c:25:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/pci/endpoint/pci-ep-cfs.c: In function 'pci_ep_cfs_add_epf_group':
>> drivers/pci/endpoint/pci-ep-cfs.c:413:7: warning: passing argument 3 of 
>> 'configfs_register_default_group' discards 'const' qualifier from pointer 
>> target type [-Wdiscarded-qualifiers]
  &pci_epf_group_type);
  ^
   In file included from include/linux/pci-ep-cfs.h:15:0,
from drivers/pci/endpoint/pci-ep-cfs.c:25:
   include/linux/configfs.h:262:1: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
configfs_register_default_group(struct config_group *parent_group,
^~~
   drivers/pci/endpoint/pci-ep-cfs.c: At top level:
>> drivers/pci/endpoint/pci-ep-cfs.c:447:15: warning: initialization discards 
>> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
   .ci_type = &pci_ep_type,
  ^
   drivers/pci/endpoint/pci-ep-cfs.c: In function 'pci_ep_cfs_init':
   drivers/pci/endpoint/pci-ep-cfs.c:468:10: warning: passing argument 3 of 
'configfs_register_default_group' discards 'const' qualifier from pointer 
target type [-Wdiscarded-qualifiers]
 &pci_functions_type);
 ^
   In file included from include/linux/pci-ep-cfs.h:15:0,
from drivers/pci/endpoint/pci-ep-cfs.c:25:
   include/linux/configfs.h:262:1: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
configfs_register_default_group(struct config_group *parent_group,
^~~
   drivers/pci/endpoint/pci-ep-cfs.c:478:7: warning: passing argument 3 of 
'configfs_register_default_group' discards 'const' qualifier from pointer 
target type [-Wdiscarded-qualifiers]
  &pci_controllers_type);
  ^
   In file included from include/linux/pci-ep-cfs.h:15:0,
from drivers/pci/endpoint/pci-ep-cfs.c:25:
   include/linux/configfs.h:262:1: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
configfs_register_default_group(struct config_group *parent_group,
^~~

vim +174 drivers/pci/endpoint/pci-ep-cfs.c

d7467991 Kishon Vijay Abraham I 2017-03-27  158  
d7467991 Kishon Vijay Abraham I 2017-03-27  159  struct config_group 
*pci_ep_cfs_add_epc_group(const char *name)
d7467991 Kishon Vijay Abraham I 2017-03-27  160  {
d7467991 Kish

Re: [PATCH 0/3] Enable CEC on rk3399

2017-10-15 Thread Heiko Stuebner
Hi Hans,

Am Sonntag, 15. Oktober 2017, 12:31:29 CEST schrieb Hans Verkuil:
> On 10/14/2017 04:52 PM, Heiko Stuebner wrote:
> > Am Samstag, 14. Oktober 2017, 15:14:40 CEST schrieb Pierre-Hugues Husson:
> >>> Nice! I had a similar dw-hdmi.c patch pending but got around to posting 
> >>> it.
> >>>
> >>> I'll brush off my old rk3288 patches and see if I can get CEC enabled
> >>> for my firefly-reload. I was close to getting it work, but I guess
> >>> missed the "enable cec pin" change.
> >> Please note that on rk3288, there are two CEC pins, and you must write
> >> in RK3288_GRF_SOC_CON8 which pin you're using.
> >> On the firefly-reload, the pin used is GPIO7C0, while the default pin
> >> configuration is GPIO7C7.
> > 
> > And as an additional note, later socs have even more of these pin-routing
> > settings and we currently have infrastructure in the pinctrl driver to do
> > this automatically depending on the pinctrl settings.
> > 
> > So most likely this can also be added there for the rk3288.
> > 
> > 
> > Heiko
> > 
> 
> How does 'GPIO7C0' translate to a 'rockchip,pins' line?
> 
> I have this in rk3288-firefly-reload.dts:
> 
>hdmi {
> hdmi_cec: hdmi-cec {
> rockchip,pins = <7 16 RK_FUNC_2 &pcfg_pull_none>;
> };
> };
> 
> I think this is correct. You can find my patches for the firefly reload here:

Yep, looks correct (i.e. we have 8 pins per A,B,C,D bank, so C0 is pin 16)
but as a helping measure we now also have constants, RK_PC7 in your case.

> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=firefly2
> 
> I don't have access to my firefly reload until Friday, so I can't test this
> until then.
> 
> I'd be very grateful though if you can check the last three patches in that
> branch. It's just a test branch, so the subject/changelog of those patches
> are incomplete.

While basically ok, I'd suggest having the cec pin definitions in rk3288.dtsi,
like adding entries "hdmi-cec-c0" and "hdmi-cec-c7" or similar and selecting
the correct one per board, so that we don't need to duplicate them into each
and every board dts.

The cec pin function is after all a function of the soc itself.


> The very last patch adds CEC support for the firefly/firefly beta. I don't
> have that hardware, so I won't be able to test that.

at least in the schematics for the old firefly-rk3288 it specifies gpio7c0
as cec pin, similar to the reload but in your patch you selected gpio7c7?

Especially as gpio7c7 is part of the debug uart, this would be quite strange.


Heiko


[GIT PULL] USB driver fixes for 4.14-rc5

2017-10-15 Thread Greg KH
The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f:

  Linux 4.14-rc4 (2017-10-08 20:53:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-4.14-rc5

for you to fetch changes up to 2d30408ecfd450c8377186615b330d329ded18ea:

  Merge tag 'fixes-for-v4.14-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus 
(2017-10-12 11:17:34 +0200)


USB fixes for 4.14-rc5

Here are a handful of USB driver fixes for 4.14-rc5.

There is the "usual" usb-serial fixes and device ids, USB gadget fixes,
and some more fixes found by the fuzz testing that is happening on the
USB layer right now.

All of these have been in my tree this week with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Alan Stern (2):
  USB: dummy-hcd: Fix deadlock caused by disconnect detection
  usb: usbtest: fix NULL pointer dereference

Andreas Engel (1):
  USB: serial: cp210x: add support for ELV TFD500

Andrew Gabbasov (2):
  usb: gadget: composite: Fix use-after-free in 
usb_composite_overwrite_options
  usb: gadget: configfs: Fix memory leak of interface directory data

Dan Carpenter (1):
  usb: misc: usbtest: Fix overflow in usbtest_do_ioctl()

Greg Kroah-Hartman (2):
  Merge tag 'usb-serial-4.14-rc5' of 
git://git.kernel.org/.../johan/usb-serial into usb-linus
  Merge tag 'fixes-for-v4.14-rc5' of git://git.kernel.org/.../balbi/usb 
into usb-linus

Henryk Heisig (1):
  USB: serial: option: add support for TP-Link LTE module

Jeffrey Chu (1):
  USB: serial: ftdi_sio: add id for Cypress WICED dev board

Johan Hovold (2):
  USB: serial: console: fix use-after-free on disconnect
  USB: serial: console: fix use-after-free after failed setup

Jon Hunter (1):
  usb: phy: tegra: Fix phy suspend for UDC

Kazuya Mizuguchi (1):
  usb: renesas_usbhs: Fix DMAC sequence for receiving zero-length packet

Sebastian Frei (1):
  USB: serial: cp210x: fix partnum regression

Shrirang Bagul (1):
  USB: serial: qcserial: add Dell DW5818, DW5819

 drivers/usb/gadget/composite.c|  5 +
 drivers/usb/gadget/configfs.c | 15 ---
 drivers/usb/gadget/configfs.h | 11 ++-
 drivers/usb/gadget/function/f_rndis.c | 12 ++--
 drivers/usb/gadget/function/u_rndis.h |  1 +
 drivers/usb/gadget/udc/dummy_hcd.c|  9 ++---
 drivers/usb/misc/usbtest.c| 10 --
 drivers/usb/phy/phy-tegra-usb.c   | 17 +
 drivers/usb/renesas_usbhs/fifo.c  |  2 +-
 drivers/usb/serial/console.c  |  3 ++-
 drivers/usb/serial/cp210x.c   | 13 +++--
 drivers/usb/serial/ftdi_sio.c |  2 ++
 drivers/usb/serial/ftdi_sio_ids.h |  7 +++
 drivers/usb/serial/option.c   |  2 ++
 drivers/usb/serial/qcserial.c |  4 
 15 files changed, 86 insertions(+), 27 deletions(-)


[GIT PULL] Char/Misc driver fixes for 4.14-rc5

2017-10-15 Thread Greg KH
The following changes since commit d81fa669e3de7eb8a631d7d95dac5fbcb2bf9d4e:

  Merge branch 'for-4.14-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq (2017-10-03 10:44:03 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
tags/char-misc-4.14-rc5

for you to fetch changes up to 512cf465ee01eb23936a9e6ed0b6414eccb00853:

  binder: fix use-after-free in binder_transaction() (2017-10-04 11:25:10 +0200)


Char/Misc driver fixes for 4.14-rc5

Here are 4 patches to resolve some char/misc driver issues found these
past weeks.

One of them is a mei bugfix and another is a new mei device id.  There
is also a hyper-v fix for a reported issue, and a binder issue fix for a
problem reported by a few people.

All of these have been in my tree for a while, I don't know if
linux-next is really testing much this month.  But 0-day is happy with
them :)

Signed-off-by: Greg Kroah-Hartman 


Alexander Usyskin (1):
  mei: always use domain runtime pm callbacks.

K. Y. Srinivasan (1):
  Drivers: hv: vmbus: Fix bugs in rescind handling

Todd Kjos (1):
  binder: fix use-after-free in binder_transaction()

Tomas Winkler (1):
  mei: me: add gemini lake devices id

 drivers/android/binder.c  | 93 ++-
 drivers/hv/channel.c  |  6 +--
 drivers/hv/channel_mgmt.c | 37 +
 drivers/hv/vmbus_drv.c|  3 +-
 drivers/misc/mei/hw-me-regs.h |  2 +
 drivers/misc/mei/pci-me.c | 23 ++-
 drivers/misc/mei/pci-txe.c| 30 +-
 include/linux/hyperv.h|  2 +-
 8 files changed, 115 insertions(+), 81 deletions(-)


[PATCH] ACPI / LPSS: remove redundant initialization of clk

2017-10-15 Thread Colin King
From: Colin Ian King 

The pointer clk is being initialized to ERR_PTR(-ENODEV) however
this value is never read before it is set to clk_data->clk. Thus
the initialization is redundant and can be mored.

Cleans up clang warning:
Value stored to 'clk' during its initialization is never read

Signed-off-by: Colin Ian King 
---
 drivers/acpi/acpi_lpss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 97b753dd2e6e..023191aa8d7e 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -362,7 +362,7 @@ static int register_device_clock(struct acpi_device *adev,
 {
const struct lpss_device_desc *dev_desc = pdata->dev_desc;
const char *devname = dev_name(&adev->dev);
-   struct clk *clk = ERR_PTR(-ENODEV);
+   struct clk *clk;
struct lpss_clk_data *clk_data;
const char *parent, *clk_name;
void __iomem *prv_base;
-- 
2.14.1



[PATCH] ipvs: Fix inappropriate output of procfs

2017-10-15 Thread KUWAZAWA Takuya
Information about ipvs in different network namespace can be seen via procfs.

How to reproduce:

  # ip netns add ns01
  # ip netns add ns02
  # ip netns exec ns01 ip a add dev lo 127.0.0.1/8
  # ip netns exec ns02 ip a add dev lo 127.0.0.1/8
  # ip netns exec ns01 ipvsadm -A -t 10.1.1.1:80
  # ip netns exec ns02 ipvsadm -A -t 10.1.1.2:80

The ipvsadm displays information about its own network namespace only.

  # ip netns exec ns01 ipvsadm -Ln
  IP Virtual Server version 1.2.1 (size=4096)
  Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port   Forward Weight ActiveConn InActConn
  TCP  10.1.1.1:80 wlc

  # ip netns exec ns02 ipvsadm -Ln
  IP Virtual Server version 1.2.1 (size=4096)
  Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port   Forward Weight ActiveConn InActConn
  TCP  10.1.1.2:80 wlc

But I can see information about other network namespace via procfs.

  # ip netns exec ns01 cat /proc/net/ip_vs
  IP Virtual Server version 1.2.1 (size=4096)
  Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
  TCP  0A010101:0050 wlc
  TCP  0A010102:0050 wlc

  # ip netns exec ns02 cat /proc/net/ip_vs
  IP Virtual Server version 1.2.1 (size=4096)
  Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
  TCP  0A010102:0050 wlc

Signed-off-by: KUWAZAWA Takuya 
---
 net/netfilter/ipvs/ip_vs_ctl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 4f940d7..b3245f9 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -2034,12 +2034,16 @@ static int ip_vs_info_seq_show(struct seq_file *seq, 
void *v)
seq_puts(seq,
 "  -> RemoteAddress:Port Forward Weight ActiveConn 
InActConn\n");
} else {
+   struct net *net = seq_file_net(seq);
+   struct netns_ipvs *ipvs = net_ipvs(net);
const struct ip_vs_service *svc = v;
const struct ip_vs_iter *iter = seq->private;
const struct ip_vs_dest *dest;
struct ip_vs_scheduler *sched = rcu_dereference(svc->scheduler);
char *sched_name = sched ? sched->name : "none";
 
+   if (svc->ipvs != ipvs)
+   return 0;
if (iter->table == ip_vs_svc_table) {
 #ifdef CONFIG_IP_VS_IPV6
if (svc->af == AF_INET6)
-- 
1.8.3.1



Re: [PATCH -v2 12/18] sched/fair: Rewrite PELT migration propagation

2017-10-15 Thread Vincent Guittot
On 13 October 2017 at 22:41, Peter Zijlstra  wrote:
> On Fri, Oct 13, 2017 at 05:22:54PM +0200, Vincent Guittot wrote:
>>
>> I have studied a bit more how to improve the propagation formula and the
>> changes below is doing the job for the UCs that I have tested.
>>
>> Unlike running, we can't directly propagate the runnable through hierarchy
>> when we migrate a task. Instead we must ensure that we will not
>> over/underestimate the impact of the migration thanks to several rules:
>>  - ge->avg.runnable_sum can't be higher than LOAD_AVG_MAX
>>  - ge->avg.runnable_sum can't be lower than ge->avg.running_sum (once scaled 
>> to
>>the same range)
>>  - we can't directly propagate a negative delta of runnable_sum because part 
>> of
>>this runnable time can be "shared" with others sched_entities and stays 
>> on the
>>gcfs_rq.
>
> Right, that's about how far I got.
>
>>  - ge->avg.runnable_sum can't increase when we detach a task.
>
> Yeah, that would be fairly broken.
>
>> Instead, we can't estimate the new runnable_sum of the gcfs_rq with
>
>  s/can't/can/ ?

yes it's can

>
>> the formula:
>>
>>   gcfs_rq's runnable sum = gcfs_rq's load_sum / gcfs_rq's weight.
>
> That might be the best we can do.. its wrong, but then its less wrong
> that what we have now. The comments can be much improved though. Not to
> mention that the big comment on top needs a little help.

I'm going to update the comment

>
>> ---
>>  kernel/sched/fair.c | 56 
>> ++---
>>  1 file changed, 45 insertions(+), 11 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 350dbec0..a063b048 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -3489,33 +3489,67 @@ update_tg_cfs_util(struct cfs_rq *cfs_rq, struct 
>> sched_entity *se, struct cfs_rq
>>  static inline void
>>  update_tg_cfs_runnable(struct cfs_rq *cfs_rq, struct sched_entity *se, 
>> struct cfs_rq *gcfs_rq)
>>  {
>> + long running_sum, runnable_sum = gcfs_rq->prop_runnable_sum;
>> + long runnable_load_avg, delta_avg, load_avg;
>> + s64 runnable_load_sum, delta_sum, load_sum = 0;
>>
>>   if (!runnable_sum)
>>   return;
>>
>>   gcfs_rq->prop_runnable_sum = 0;
>>
>> + /*
>> +  * Get a rough estimate of gcfs_rq's runnable
>> +  * This is a low guess as it assumes that tasks are equally
>> +  * runnable which is not true but we can't really do better
>> +  */
>> + if (scale_load_down(gcfs_rq->load.weight)) {
>> + load_sum = div_s64(gcfs_rq->avg.load_sum,
>> + scale_load_down(gcfs_rq->load.weight));
> }
>> +
>> + /*
>> +  * Propating a delta of runnable is not just adding it to ge's
>> +  * runnable_sum:
>> +  * - Adding a delta runnable can't make ge's runnable_sum higher than
>> +  *   LOAD_AVG_MAX
>> +  * - We can't directly remove a delta of runnable from
>> +  *   ge's runnable_sum but we can only guest estimate what runnable
>> +  *   will become thanks to few simple rules:
>> +  *   - gcfs_rq's runnable is a good estimate
>> +  *   - ge's runnable_sum can't increase when we remove runnable
>> +  *   - runnable_sum can't be lower than running_sum
>> +  */
>> + if (runnable_sum >= 0) {
>> + runnable_sum += se->avg.load_sum;
>> + runnable_sum = min(runnable_sum, LOAD_AVG_MAX);
>> + } else {
>> + runnable_sum = min(se->avg.load_sum, load_sum);
> }
>> +
>> + running_sum = se->avg.util_sum >> SCHED_CAPACITY_SHIFT;
>> + runnable_sum = max(runnable_sum, running_sum);
>> +
>>   load_sum = (s64)se_weight(se) * runnable_sum;
>>   load_avg = div_s64(load_sum, LOAD_AVG_MAX);
>>
>> + delta_sum = load_sum - (s64)se_weight(se) * se->avg.load_sum;
>> + delta_avg = load_avg - se->avg.load_avg;
>>
>> + se->avg.load_sum = runnable_sum;
>> + se->avg.load_avg = load_avg;
>> + add_positive(&cfs_rq->avg.load_avg, delta_avg);
>> + add_positive(&cfs_rq->avg.load_sum, delta_sum);
>>
>>   runnable_load_sum = (s64)se_runnable(se) * runnable_sum;
>>   runnable_load_avg = div_s64(runnable_load_sum, LOAD_AVG_MAX);
>> + delta_sum = runnable_load_sum - se_weight(se) * 
>> se->avg.runnable_load_sum;
>> + delta_avg = runnable_load_avg - se->avg.runnable_load_avg;
>>
>> + se->avg.runnable_load_sum = runnable_sum;
>> + se->avg.runnable_load_avg = runnable_load_avg;
>>
>>   if (se->on_rq) {
>> + add_positive(&cfs_rq->avg.runnable_load_avg, delta_avg);
>> + add_positive(&cfs_rq->avg.runnable_load_sum, delta_sum);
>>   }
>>  }
>>
>> --
>> 2.7.4
>>


Re: [PATCH 3/3] arm64: dts: rockchip: enable cec pin for rk3399 firefly

2017-10-15 Thread Heiko Stuebner
Am Samstag, 14. Oktober 2017, 00:53:37 CEST schrieb Pierre-Hugues Husson:
> Signed-off-by: Pierre-Hugues Husson 

applied for 4.15 after adding a basic commit message.
It is custom to always provide at least some sort of message there.


Thanks
Heiko


Re: [PATCH 2/3] arm64: dts: rockchip: add the cec clk for dw-mipi-hdmi on rk3399

2017-10-15 Thread Heiko Stuebner
Am Samstag, 14. Oktober 2017, 00:53:36 CEST schrieb Pierre-Hugues Husson:
> Signed-off-by: Pierre-Hugues Husson 

applied for 4.15 after adding a basic commit message.
It is custom to always provide at least some sort of message there.


Thanks
Heiko


WARNING in per_cpu_alloc

2017-10-15 Thread Shankara Pailoor
Hi,

We found the warning when fuzzing with Syzkaller on Linux 4-14-rc4.

illegal size (32776) or align (8) for percpu allocation
[ cut here ]
WARNING: CPU: 0 PID: 22596 at mm/percpu.c:1365 pcpu_alloc+0x140/0x10f0
Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 22596 Comm: syz-executor1 Not tainted 4.14.0-rc4 #1
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Call Trace:
 dump_stack+0x115/0x1da
 panic+0x1b4/0x3a7
 __warn+0x1c4/0x1d9
 report_bug+0x211/0x2d0
 fixup_bug+0x40/0x90
 do_trap+0x260/0x390
 do_error_trap+0x11c/0x350
 do_invalid_op+0x1b/0x20
 invalid_op+0x18/0x20
RIP: 0010:pcpu_alloc+0x140/0x10f0
RSP: 0018:8800a752f6a8 EFLAGS: 00010286
RAX: 0037 RBX:  RCX: 
RDX: 0037 RSI: c90001a32000 RDI: ed0014ea5ec9
RBP: 8800a752f920 R08: 8800a752ed98 R09: 
R10:  R11:  R12: 8007
R13:  R14: 8800a752fec0 R15: 0008
 __alloc_percpu+0x24/0x30
 dev_map_alloc+0x68e/0xb70
 SyS_bpf+0xd25/0x4500
 entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x452349
RSP: 002b:7f8c38897be8 EFLAGS: 0212 ORIG_RAX: 0141
RAX: ffda RBX: 00968000 RCX: 00452349
RDX: 001c RSI: 20038000 RDI: 
RBP: 0046 R08:  R09: 
R10:  R11: 0212 R12: 006f25a8
R13:  R14: 00968070 R15: 
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: 0x2380 from 0x8100 (relocation range:
0x8000-0xbfff)
Rebooting in 86400 seconds..

Here is the reproducer program: https://pastebin.com/TdSTCu5E



Linux 4.14: Reported regressions as of Sunday, 2017-10-15

2017-10-15 Thread Thorsten Leemhuis
Hi! Find below my third regression report for Linux 4.14. It lists 9
regressions I'm currently aware of. Two regressions got fixed since last
weeks report.

As always: Are you aware of any other regressions? Then please let me
know by mail (a simple bounce or forward in my direction is enough!).
For details see http://bit.ly/lnxregtrackid And please tell me if there
is anything in the report that shouldn't be there.

Ciao, Thorsten

== Current regressions ==

New default s2idle does not work on Dell XPS 13 9360 with hynix 512GB
Status: works fine on several other owners of this laptop;  appears to
be related to NVMe(and specifically to the particular Hynix 512G NVMe
SSD in that machine)
Note: this seems to be a regression in 4.13 that is exposed by a change
in 4.14; judge yourself if this should be in the list or not
Reported: 2017-09-11
https://bugzilla.kernel.org/show_bug.cgi?id=196907
https://lkml.kernel.org/r/3347223.tl9vk2v...@aspire.rjw.lan
Cause: e870c6c87cf9484090d28f2a68aa29e008960c93 (assumed)

CIFS SMB2+ combined with pythons xattr.listxattr leads to "IOError:
[Errno 61
Status: no reaction from developers yet; reporter too lazy, he still
needs to reverify and poke list
Note: Disclaimer: A regression the regression tracker reported
Reported: 2017-09-26
https://marc.info/?l=linux-cifs&m=150644485708526
Cause: 8dc5b3a6cb2f (assumed)

Ath10k disconnects
Status: no progress in the last week; will poke on Monday
Note: Only happens with some wifi routers; Disclaimer: A regression the
regression tracker reported
Reported: 2017-10-01
http://lists.infradead.org/pipermail/ath10k/2017-October/010189.html
Cause: c9353bf483d3724c116a9d502c0ead9cec54a61a

Oops in nouveau_fbcon_set_suspend_work during boot or resume on some
machines
Status: Three people see this now; one is considering a bisection
Reported: 2017-10-02
https://bugzilla.kernel.org/show_bug.cgi?id=197103
https://bugs.freedesktop.org/show_bug.cgi?id=102381

networking doesn't work in opensuse 42.2 due to apparmor: add base
infastructure for socket mediation
Status: stalled: after the reported by James there was a debate if this
is a regression or not that in the end faded out
Note: Maybe this should be removed from the list
Reported: 2017-10-03
https://lkml.kernel.org/r/1507003338.3174.4.ca...@hansenpartnership.com
Cause: 651e28c5537abb39076d3949fb7618536f1d242e

WiFi stopped working with 4.14 (two report: a staging driver and iwlwifi)
Status: told reporters a week ago they better should bring this to
netdev; didn't happen afaics
Note: maybe these are two different issues; one with rtl8723bs
(Staging!) and one where with 8265 that is related to switching BT on
and off
Reported: 2017-10-05
https://bugzilla.kernel.org/show_bug.cgi?id=197137

Dramatic lockdep slowdown in 4.14
Status: WIP
Note: "Now since it's lockdep I guess this can't really be considered a
regression if these changes did improve lockdep correctness, but still,
this dramatic slow down essentially forces me to disable PROVE_LOCKING
by default on this system."
Reported: 2017-10-13
https://lkml.kernel.org/r/20171013090333.GA17356@localhost
Cause: 28a903f63ec0

Hikey620: it's easy to trigger a panic with "rcu_preempt detected stalls
on CPUs/tasks"
https://lkml.kernel.org/r/20171010142725.GA24797@leoy-linaro
Status: WIP
Cause: e3067861ba66

On first generation i486 processors it immediately resets the system
after the "Booting the kernel" message.
Status: brand new
https://lkml.kernel.org/r/cap8wd_a-6dpezhrsq4yrkkkmypkxw1wobxchj0ojcrvjmsc...@mail.gmail.com
Cause: 87e81786b13b267c4355e0d23e33c7e4c08fa63f


== Fixed since last report ==

"hangs when building e.g. perf" & "Random insta-reboots on AMD Phenom II"
Status: Fixed by https://git.kernel.org/torvalds/c/67bb8e999e0a
Reported: 2017-09-05
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1484723.html
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1501379.html
https://lkml.kernel.org/r/cover.1508000261.git.l...@kernel.org
Cause: 94b1b03b519b81c494900cb112aa00ed205cc2d9

nftables oops with 4.14.0-rc3 on arm64 (Rock64 board)
Status: Fixed by https://git.kernel.org/torvalds/c/5f9bfe0ef622
Reported: 2017-10-04
https://bugzilla.kernel.org/show_bug.cgi?id=197123
Cause: 9f08ea848117


Re: [PATCH] ASoC: wm97xx: fix compilation corner case

2017-10-15 Thread Charles Keepax
On Sat, Oct 14, 2017 at 10:14:02PM +0200, Robert Jarzmik wrote:
> When the old AC97 is not used, CONFIG_SND_SOC_AC97_BUS is not
> defined. As a consequence, in the error path, snd_soc_free_ac97_codec()
> is not defined and triggers a compilation error.
> 
> Fix it for wm9705 and wm9712, as wm9713 is correctly written.
> 
> Signed-off-by: Robert Jarzmik 
> ---

Acked-by: Charles Keepax 

Thanks,
Charles


[PATCH] Fix isocpus's param handling when CPUMASK_OFFSTACK=n.

2017-10-15 Thread Rakib Mullick
 cpulist_parse() uses nr_cpumask_bits as limit to parse the
passed buffer from kernel commandline. What nr_cpumask_bits
represents varies depends upon CONFIG_CPUMASK_OFFSTACK option.
If CONFIG_CPUMASK_OFFSTACK=n, then nr_cpumask_bits is same as
NR_CPUS, which might not represent the # of cpus really exist
(default 64). So, there's a chance of gap between nr_cpu_ids
and NR_CPUS, which ultimately lead towards invalid cpulist_parse()
operation. For example, if isolcpus=9 is passed on a 8 cpu
system (CONFIG_CPUMASK_OFFSTACK=n) it doesn't show the error
that it suppose to.

This patch fixes this issue by effectively find out the last
cpu of the passed isolcpus list and checking it with nr_cpu_ids.
Also, fixes the error message where the nr_cpu_ids should be
nr_cpu_ids-1, since the cpu numbering starts from 0.

Signed-off-by: Rakib Mullick 
---
 include/linux/cpumask.h | 16 
 kernel/sched/topology.c |  8 +---
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 2404ad2..f9a7c9b 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -130,6 +130,11 @@ static inline unsigned int cpumask_first(const struct 
cpumask *srcp)
return 0;
 }
 
+static inline unsigned int cpumask_last(const struct cpumask *srcp)
+{
+   return 0;
+}
+
 /* Valid inputs for n are -1 and 0. */
 static inline unsigned int cpumask_next(int n, const struct cpumask *srcp)
 {
@@ -179,6 +184,17 @@ static inline unsigned int cpumask_first(const struct 
cpumask *srcp)
 }
 
 /**
+ * cpumask_last - get the last cpu in a cpumask
+ * @srcp:  - the cpumask pointer
+ *
+ * Returns >= nr_cpumask_bits if no cpus set.
+ */
+static inline unsigned int cpumask_last(const struct cpumask *srcp)
+{
+   return find_last_bit(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
  * cpumask_next - get the next cpu in a cpumask
  * @n: the cpu prior to the place to search (ie. return will be > @n)
  * @srcp: the cpumask pointer
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 1b0b4fb..55b5e09 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -452,12 +452,14 @@ cpu_attach_domain(struct sched_domain *sd, struct 
root_domain *rd, int cpu)
 /* Setup the mask of CPUs configured for isolated domains */
 static int __init isolated_cpu_setup(char *str)
 {
-   int ret;
+   int ret, lastcpu;
 
alloc_bootmem_cpumask_var(&cpu_isolated_map);
ret = cpulist_parse(str, cpu_isolated_map);
-   if (ret) {
-   pr_err("sched: Error, all isolcpus= values must be between 0 
and %d\n", nr_cpu_ids);
+   lastcpu = cpumask_last(cpu_isolated_map);
+   if (ret || lastcpu >= nr_cpu_ids) {
+   pr_err("sched: Error, all isolcpus= values must be between 0 
and %d\n",
+   nr_cpu_ids-1);
return 0;
}
return 1;
-- 
2.9.3



Re: [PATCH] spi-nor: intel-spi: Fix Kconfig dependency to LPC_ICH

2017-10-15 Thread Bin Meng
Hi Arnd,

On Fri, Oct 13, 2017 at 7:15 PM, Arnd Bergmann  wrote:
> On Wed, Oct 11, 2017 at 10:03 AM, Cyrille Pitchen
>  wrote:
>> Le 25/08/2017 à 10:12, Bin Meng a écrit :
>>> The Intel SPI-NOR driver is dependent on LPC_ICH to get the platform
>>> data. Select it in the Kconfig.
>>>
>>> Signed-off-by: Bin Meng 
>>
>> Applied to the spi-nor/next branch of l2-mtd
>
> This causes a build error now:
>
> warning: (SPI_INTEL_SPI_PLATFORM && ITCO_WDT) selects LPC_ICH which
> has unmet direct dependencies (HAS_IOMEM && PCI)
> drivers/mfd/lpc_ich.c: In function 'lpc_ich_init_spi':
> drivers/mfd/lpc_ich.c:1137:3: error: implicit declaration of function
> 'pci_bus_write_config_byte'; did you mean 'pci_write_config_byte'?
> [-Werror=implicit-function-declaration]
>

Thanks for your testing. However, I believe this build error cannot be
seen in a real system due to x86 always has PCI on. But I see you were
doing build testing with COMPILE_TEST.

> Generally speaking, using 'select' to force-enable another
> driver is a bad idea and causes endless problems, but if you
> insist on doing that, please make sure you get the right
> dependencies.
>

Sure.

> Also, the 'depends on EXPERT' statement looks misplaced,
> enabling EXPERT should only be there to allow you to turn
> extra things *off*, not to hide device drivers.
>

I will leave this to Mika to comment the "EXPERT" usage. If we remove
this, I think that should be another patch and the documentation of
this driver should be updated too.

> How about this:
>
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 19bcb63a1ce7..b81d9b4dae7b 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -90,7 +90,7 @@ config SPI_INTEL_SPI
> tristate
>
>  config SPI_INTEL_SPI_PCI
> -   tristate "Intel PCH/PCU SPI flash PCI driver" if EXPERT
> +   tristate "Intel PCH/PCU SPI flash PCI driver"
> depends on X86 && PCI
> select SPI_INTEL_SPI
> help
> @@ -106,10 +106,10 @@ config SPI_INTEL_SPI_PCI
>   will be called intel-spi-pci.
>
>  config SPI_INTEL_SPI_PLATFORM
> -   tristate "Intel PCH/PCU SPI flash platform driver" if EXPERT
> -   depends on X86
> +   tristate "Intel PCH/PCU SPI flash platform driver"
> +   depends on X86 && (PCI || COMPILE_TEST)
> select SPI_INTEL_SPI
> -   select LPC_ICH
> +   select LPC_ICH if PCI

I think we just need do:

depends on X86 && PCI

then

select LPC_ICH

> help
>   This enables platform support for the Intel PCH/PCU SPI
>   controller in master mode. This controller is present in modern
>

Regards,
Bin


Re: [PATCH] media: dvb_ca_en50221: sanity check slot number from userspace

2017-10-15 Thread Jasmin J.
Good catch!

> Seems that this bug has been in the driver forever.
Indeed ... and I overlooked it during my recent changes to that module.

Reviewed-by: Jasmin Jessich 

BR,
   Jasmin


Re: [PATCH] ipvs: Fix inappropriate output of procfs

2017-10-15 Thread Julian Anastasov

Hello,

On Sun, 15 Oct 2017, KUWAZAWA Takuya wrote:

> Information about ipvs in different network namespace can be seen via procfs.
> 
> How to reproduce:
> 
>   # ip netns add ns01
>   # ip netns add ns02
>   # ip netns exec ns01 ip a add dev lo 127.0.0.1/8
>   # ip netns exec ns02 ip a add dev lo 127.0.0.1/8
>   # ip netns exec ns01 ipvsadm -A -t 10.1.1.1:80
>   # ip netns exec ns02 ipvsadm -A -t 10.1.1.2:80
> 
> The ipvsadm displays information about its own network namespace only.
> 
>   # ip netns exec ns01 ipvsadm -Ln
>   IP Virtual Server version 1.2.1 (size=4096)
>   Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port   Forward Weight ActiveConn InActConn
>   TCP  10.1.1.1:80 wlc
> 
>   # ip netns exec ns02 ipvsadm -Ln
>   IP Virtual Server version 1.2.1 (size=4096)
>   Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port   Forward Weight ActiveConn InActConn
>   TCP  10.1.1.2:80 wlc
> 
> But I can see information about other network namespace via procfs.
> 
>   # ip netns exec ns01 cat /proc/net/ip_vs
>   IP Virtual Server version 1.2.1 (size=4096)
>   Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
>   TCP  0A010101:0050 wlc
>   TCP  0A010102:0050 wlc
> 
>   # ip netns exec ns02 cat /proc/net/ip_vs
>   IP Virtual Server version 1.2.1 (size=4096)
>   Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
>   TCP  0A010102:0050 wlc
> 
> Signed-off-by: KUWAZAWA Takuya 

Looks good to me

Acked-by: Julian Anastasov 

Simon, please apply to ipvs tree.

> ---
>  net/netfilter/ipvs/ip_vs_ctl.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 4f940d7..b3245f9 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -2034,12 +2034,16 @@ static int ip_vs_info_seq_show(struct seq_file *seq, 
> void *v)
>   seq_puts(seq,
>"  -> RemoteAddress:Port Forward Weight ActiveConn 
> InActConn\n");
>   } else {
> + struct net *net = seq_file_net(seq);
> + struct netns_ipvs *ipvs = net_ipvs(net);
>   const struct ip_vs_service *svc = v;
>   const struct ip_vs_iter *iter = seq->private;
>   const struct ip_vs_dest *dest;
>   struct ip_vs_scheduler *sched = rcu_dereference(svc->scheduler);
>   char *sched_name = sched ? sched->name : "none";
>  
> + if (svc->ipvs != ipvs)
> + return 0;
>   if (iter->table == ip_vs_svc_table) {
>  #ifdef CONFIG_IP_VS_IPV6
>   if (svc->af == AF_INET6)
> -- 
> 1.8.3.1

Regards

--
Julian Anastasov 


Re: [PATCH] video: fbdev: Fix an errro handling path in 'au1200fb_drv_probe()'

2017-10-15 Thread Christophe JAILLET

Le 12/10/2017 à 18:25, Bartlomiej Zolnierkiewicz a écrit :

[ added dri-devel ML to cc: ]

On Tuesday, September 12, 2017 07:39:30 AM Christophe JAILLET wrote:

If 'dmam_alloc_attrs()' fails, we must go through the error handling code,
as done elsewhere in this function. Otherwise, there is a resource leak.

Signed-off-by: Christophe JAILLET 
---
I'm also puzzled by the 'framebuffer_alloc()' call a few lines above.
'ret' is known to be 0 at this point. I guess that -ENOMEM should also be
returned.

Yes, moreover the "failed:" error path is incomplete (please take
a look at au1200fb_drv_remove() for comparison) and needs to be fixed.

Could you please take care of it?


I will try, but be indulgent :)

My understanding of the code is that they are several issues all related 
to this error handling path (double free, missing memory release, 
invalid irq release...)
I will try to sort it out, but my first tries will likely be incomplete 
and/or broken.


CJ


Re: [PATCH net-next v2 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE

2017-10-15 Thread Masahiro Yamada
2017-10-13 9:35 GMT+09:00 Kunihiko Hayashi :
> DT bindings for the AVE ethernet controller found on Socionext's
> UniPhier platforms.
>
> Signed-off-by: Kunihiko Hayashi 
> Signed-off-by: Jassi Brar 
> ---
>  .../bindings/net/socionext,uniphier-ave4.txt   | 53 
> ++
>  1 file changed, 53 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt 
> b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> new file mode 100644
> index 000..25f4d92
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> @@ -0,0 +1,53 @@
> +* Socionext AVE ethernet controller
> +
> +This describes the devicetree bindings for AVE ethernet controller
> +implemented on Socionext UniPhier SoCs.
> +
> +Required properties:
> + - compatible: Should be
> +   - "socionext,uniphier-pro4-ave4" : for Pro4 SoC
> +   - "socionext,uniphier-pxs2-ave4" : for PXs2 SoC
> +   - "socionext,uniphier-ld20-ave4" : for LD20 SoC
> +   - "socionext,uniphier-ld11-ave4" : for LD11 SoC
> + - reg: Address where registers are mapped and size of region.
> + - interrupts: Should contain the MAC interrupt.
> + - phy-mode: See ethernet.txt in the same directory. Allow to choose
> +   "rgmii", "rmii", or "mii" according to the PHY.
> + - pinctrl-names: List of assigned state names, see pinctrl
> +   binding documentation.
> + - pinctrl-0: List of phandles to configure the GPIO pin,
> +   see pinctrl binding documentation. Choose this appropriately
> +   according to phy-mode.
> +   - <&pinctrl_ether_rgmii> if phy-mode is "rgmii".
> +   - <&pinctrl_ether_rmii> if phy-mode is "rmii".
> +   - <&pinctrl_ether_mii> if phy-mode is "mii".
> + - phy-handle: Should point to the external phy device.
> +   See ethernet.txt file in the same directory.
> + - mdio subnode: Should be device tree subnode with the following required
> +   properties:
> +   - #address-cells: Must be <1>.
> +   - #size-cells: Must be <0>.
> +   - reg: phy ID number, usually a small integer.
> +
> +Optional properties:
> + - local-mac-address: See ethernet.txt in the same directory.
> +
> +Example:
> +
> +   ether: ethernet@6500 {
> +   compatible = "socionext,uniphier-ld20-ave4";
> +   reg = <0x6500 0x8500>;
> +   interrupts = <0 66 4>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&pinctrl_ether_rgmii>;
> +   phy-mode = "rgmii";
> +   phy-handle = <ðphy>;
> +   local-mac-address = [00 00 00 00 00 00];
> +   mdio {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   ethphy: ethphy@1 {
> +   reg = <1>;
> +   };
> +   };
> +   };
> --
> 2.7.4
>


I found the following code in 2/2.

+ /* get clock */
+ priv->clk = clk_get(dev, NULL);
+ if (IS_ERR(priv->clk))
+ priv->clk = NULL;
+
+ /* get reset */
+ priv->rst = reset_control_get(dev, NULL);
+ if (IS_ERR(priv->rst))
+ priv->rst = NULL;
+


This doc needs to describe "clocks", "resets".


-- 
Best Regards
Masahiro Yamada


Re: [PATCH net-next v2 2/2] net: ethernet: socionext: add AVE ethernet driver

2017-10-15 Thread Masahiro Yamada
2017-10-13 9:35 GMT+09:00 Kunihiko Hayashi :
> +static int ave_probe(struct platform_device *pdev)
> +{
> +   struct device *dev = &pdev->dev;
> +   struct device_node *np = dev->of_node;
> +   u32 ave_id;
> +   struct ave_private *priv;
> +   const struct ave_soc_data *data;
> +   phy_interface_t phy_mode;
> +   struct net_device *ndev;
> +   struct resource *res;
> +   void __iomem *base;
> +   int irq, ret = 0;
> +   char buf[ETHTOOL_FWVERS_LEN];
> +   const void *mac_addr;
> +
> +   data = of_device_get_match_data(dev);
> +   if (WARN_ON(!data))
> +   return -EINVAL;
> +
> +   phy_mode = of_get_phy_mode(np);
> +   if (phy_mode < 0) {
> +   dev_err(dev, "phy-mode not found\n");
> +   return -EINVAL;
> +   }
> +   if ((!phy_interface_mode_is_rgmii(phy_mode)) &&
> +   phy_mode != PHY_INTERFACE_MODE_RMII &&
> +   phy_mode != PHY_INTERFACE_MODE_MII) {
> +   dev_err(dev, "phy-mode is invalid\n");
> +   return -EINVAL;
> +   }
> +
> +   irq = platform_get_irq(pdev, 0);
> +   if (irq < 0) {
> +   dev_err(dev, "IRQ not found\n");
> +   return irq;
> +   }
> +
> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +   base = devm_ioremap_resource(dev, res);
> +   if (IS_ERR(base))
> +   return PTR_ERR(base);
> +
> +   /* alloc netdevice */
> +   ndev = alloc_etherdev(sizeof(struct ave_private));
> +   if (!ndev) {
> +   dev_err(dev, "can't allocate ethernet device\n");
> +   return -ENOMEM;
> +   }
> +
> +   ndev->netdev_ops = &ave_netdev_ops;
> +   ndev->ethtool_ops = &ave_ethtool_ops;
> +   SET_NETDEV_DEV(ndev, dev);
> +
> +   /* support hardware checksum */
> +   ndev->features|= (NETIF_F_IP_CSUM | NETIF_F_RXCSUM);
> +   ndev->hw_features |= (NETIF_F_IP_CSUM | NETIF_F_RXCSUM);
> +
> +   ndev->max_mtu = AVE_MAX_ETHFRAME - (ETH_HLEN + ETH_FCS_LEN);
> +
> +   /* get mac address */
> +   mac_addr = of_get_mac_address(np);
> +   if (mac_addr)
> +   ether_addr_copy(ndev->dev_addr, mac_addr);
> +
> +   /* if the mac address is invalid, use random mac address */
> +   if (!is_valid_ether_addr(ndev->dev_addr)) {
> +   eth_hw_addr_random(ndev);
> +   dev_warn(dev, "Using random MAC address: %pM\n",
> +ndev->dev_addr);
> +   }
> +
> +   priv = netdev_priv(ndev);
> +   priv->base = base;
> +   priv->irq = irq;
> +   priv->ndev = ndev;
> +   priv->msg_enable = netif_msg_init(-1, AVE_DEFAULT_MSG_ENABLE);
> +   priv->phy_mode = phy_mode;
> +   priv->data = data;
> +
> +   if (IS_DESC_64BIT(priv)) {
> +   priv->desc_size = AVE_DESC_SIZE_64;
> +   priv->tx.daddr  = AVE_TXDM_64;
> +   priv->rx.daddr  = AVE_RXDM_64;
> +   } else {
> +   priv->desc_size = AVE_DESC_SIZE_32;
> +   priv->tx.daddr  = AVE_TXDM_32;
> +   priv->rx.daddr  = AVE_RXDM_32;
> +   }
> +   priv->tx.ndesc = AVE_NR_TXDESC;
> +   priv->rx.ndesc = AVE_NR_RXDESC;
> +
> +   u64_stats_init(&priv->stats_rx.syncp);
> +   u64_stats_init(&priv->stats_tx.syncp);
> +
> +   /* get clock */

Please remove this super-obvious comment.


> +   priv->clk = clk_get(dev, NULL);

Missing clk_put() in the failure path.

Why don't you use devm?



> +   if (IS_ERR(priv->clk))
> +   priv->clk = NULL;

So, clk is optional, but
you need to check EPROBE_DEFER.




> +   /* get reset */

Remove.


> +   priv->rst = reset_control_get(dev, NULL);
> +   if (IS_ERR(priv->rst))
> +   priv->rst = NULL;


reset_control_get() is deprecated.  Do not use it in a new driver.

Again, missing reset_control_put().   devm?


The reset seems optional (again, ignoring EPROBE_DEFER)
but you did not use reset_control_get_optional, why?

>From your code, this reset is used as shared.


priv->rst = devm_reset_control_get_optional_shared(dev, NULL);
if (IS_ERR(priv->rst))
  return PTR_ERR(priv->rst);








-- 
Best Regards
Masahiro Yamada


Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

2017-10-15 Thread Yi Zhang
Thanks for your review Jim.

On 2017-10-13 at 09:57:45 -0700, Jim Mattson wrote:
> I'll ask before Paolo does: Can you please add kvm-unit-tests to
> exercise all of this new code?
it is should be a API/ioctl tools rather than a kvm-unit-test. Actually,
I have prepared a draft version of tools which embedded in the qemu
command line, mean that we could set/get the subpage protection via qemu
command.

Attached the qemu patch. BTW, it is a pre-design version, I will send a
formal qemu patch to qemu list after the API/ioctl was fix by kvm side.

> 
> BTW, what generation of hardware do we need to exercise this code ourselves?
As far as I know , This feature will enable on Intel next-generation Ice
Lake chips.

> 
> On Fri, Oct 13, 2017 at 4:11 PM, Zhang Yi  wrote:
> > From: Zhang Yi Z 
> >
> > Hi All,
> >
> > Here is a patch-series which adding EPT-Based Sub-page Write Protection 
> > Support. You can get It's software developer manuals from:
> >
> > https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
> >
> > In Chapter 4 EPT-BASED SUB-PAGE PERMISSIONS.
> >
> > Introduction:
> >
> > EPT-Based Sub-page Write Protection referred to as SPP, it is a capability 
> > which allow Virtual Machine Monitors(VMM) to specify write-permission for 
> > guest physical memory at a sub-page(128 byte) granularity.  When this 
> > capability is utilized, the CPU enforces write-access permissions for 
> > sub-page regions of 4K pages as specified by the VMM. EPT-based sub-page 
> > permissions is intended to enable fine-grained memory write enforcement by 
> > a VMM for security(guest OS monitoring) and usages such as device 
> > virtualization and memory check-point.
> >
> > How SPP Works:
> >
> > SPP is active when the "sub-page write protection" VM-execution control is 
> > 1. A new 4-level paging structure named SPP page table(SPPT) is introduced, 
> > SPPT will look up the guest physical addresses to derive a 64 bit "sub-page 
> > permission" value containing sub-page write permissions. The lookup from 
> > guest-physical addresses to the sub-page region permissions is determined 
> > by a set of this SPPT paging structures.
> >
> > The SPPT is used to lookup write permission bits for the 128 byte sub-page 
> > regions containing in the 4KB guest physical page. EPT specifies the 4KB 
> > page level privileges that software is allowed when accessing the guest 
> > physical address, whereas SPPT defines the write permissions for software 
> > at the 128 byte granularity regions within a 4KB page. Write accesses 
> > prevented due to sub-page permissions looked up via SPPT are reported as 
> > EPT violation VM exits. Similar to EPT, a logical processor uses SPPT to 
> > lookup sub-page region write permissions for guest-physical addresses only 
> > when those addresses are used to access memory.
> >
> > Guest write access --> GPA --> Walk EPT --> EPT leaf entry -┐
> > ┌---┘
> > └-> if VMexec_control.spp && ept_leaf_entry.spp_bit (bit 61)
> >  |
> >  └->  --> EPT legacy behavior
> >  |
> >  |
> >  └->   --> if ept_leaf_entry.writable
> >   |
> >   └->   --> Ignore SPP
> >   |
> >   └->  --> GPA --> Walk SPP 4-level table--┐
> >   |
> > ┌<--get-the-SPPT-point-from-VMCS-filed-<--┘
> > |
> > Walk SPP L4E table
> > |
> > └┐--> entry misconfiguration >--┐<┐
> >  |  | |
> > else| |
> >  |  | |
> >  |   ┌--SPP VMexit<-┘ |
> >  |   ||
> >  |   └-> exit_qualification & sppt_misconfig --> sppt misconfig   |
> >  |   ||
> >  |   └-> exit_qualification & sppt_miss --> sppt miss |
> >  └--┐ |
> > | |
> > walk SPPT L3E--┐--> if-entry-misconfiguration>┘
> >|  |
> >   else|
> >|  |
> >|  |
> > walk SPPT L2E --┐--> if-entry-misconfiguration>---┘
> > | |
> >else 

Re: [RESEND PATCH v4 0/2] add thermal nodes for UniPhier SoCs

2017-10-15 Thread Masahiro Yamada
2017-09-18 21:10 GMT+09:00 Masahiro Yamada :
> 2017-09-04 15:58 GMT+09:00 Kunihiko Hayashi :
>> This series adds thermal nodes for UniPhier PXs2 and LD20 SoCs.
>>
>> Resending the patches to apply the missing comments,
>> please ignore previous v4.
>>
>> Changes since v3:
>> - use the dt-bindings header to replace the limit values with 
>> THERMAL_NO_LIMIT
>> - add the calibration value to uniphier-pxs2.dtsi
>> - move the calibration value to uniphier-ld20.dtsi
>>
>> Changes since v2:
>> - add the calibration value to device tree for LD20 reference board
>>
>> Changes since v1:
>> - separate from driver's patchset[1]
>> - add cooling-maps nodes on the device tree
>> - fix an interrupt trigger to set 'level-triggered' according to
>>   hardware specification
>> - bring up threshold temperature for LD20 according to the spec sheet
>> - add cpuN labels for reference in cooling-device property on PXs2 dts
>>
>> [1] https://lkml.org/lkml/2017/6/28/170
>>
>> Kunihiko Hayashi (2):
>>   ARM: dts: uniphier: add nodes of thermal monitor and thermal zone for
>> PXs2
>>   arm64: dts: uniphier: add nodes of thermal monitor and thermal zone
>> for LD20
>>
>>  arch/arm/boot/dts/uniphier-pxs2.dtsi | 47 
>> ++--
>>  arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 45 
>> +++
>>  2 files changed, 88 insertions(+), 4 deletions(-)
>>
>
> Series, applied to linux-uniphier.  Thanks!
>
> --
> Best Regards
> Masahiro Yamada


Both of the patches added W=2 warnings by '_' in the node names.

I fixed them up locally, per Rob's comment:
https://patchwork.kernel.org/patch/9988355/



-- 
Best Regards
Masahiro Yamada


Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.

2017-10-15 Thread Yi Zhang
Thanks for your quick response Paolo.

On 2017-10-13 at 17:13:25 -0400, Paolo Bonzini wrote:
> 
> > I'll ask before Paolo does: Can you please add kvm-unit-tests to
> > exercise all of this new code?
> 
> More specifically it should be the api/ unit tests because this code
> can only be triggered by specific code in the host.
> 
> However, as things stand I'm not sure about how userspace would use it.
> Only allowing blocking of writes means that we cannot (for example) use
> it to do sub-page passthrough in VFIO.  That would be useful when the
> MSI-X table does not fit a full page, but would require blocking reads

For read access blocking, it is a good point, Will report your advice to
the hardware designers, hope it could apply in the next-next generation
nodes. ^_^

> as well.  And the introspection facility by Mihai uses a completely
> different API for the introspector, based on sockets rather than ioctls.
> So I'm not sure this is the right API at all.

Currently,  We only block the write access, As far as I know an example,
we now using it in a security daemon:
Consider It has a server which launching in the host user-space, and a
client launching in the guest kernel. Yes, they are communicate with
sockets. The guest kernel wanna protect a special area to prevent all
the process including the kernel itself modify this area. the client
could send the guest physical address via the security socket to server
side, and server would update these protection into KVM. Thus, all the
write access in a guest specific area will be blocked.

Now the implementation only on the second half(maybe third ^_^) of this
example: 'How kvm set the write-protect into a specific GFN?'

Maybe a user space tools which use ioctl let kvm mmu update the
write-protection is a better choice.

> 
> Paolo
> 
> > BTW, what generation of hardware do we need to exercise this code ourselves?
> > 
> > On Fri, Oct 13, 2017 at 4:11 PM, Zhang Yi  
> > wrote:
> > > From: Zhang Yi Z 
> > >
> > > Hi All,
> > >
> > > Here is a patch-series which adding EPT-Based Sub-page Write Protection
> > > Support. You can get It's software developer manuals from:
> > >
> > > https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
> > >
> > > In Chapter 4 EPT-BASED SUB-PAGE PERMISSIONS.
> > >
> > > Introduction:
> > >
> > > EPT-Based Sub-page Write Protection referred to as SPP, it is a capability
> > > which allow Virtual Machine Monitors(VMM) to specify write-permission for
> > > guest physical memory at a sub-page(128 byte) granularity.  When this
> > > capability is utilized, the CPU enforces write-access permissions for
> > > sub-page regions of 4K pages as specified by the VMM. EPT-based sub-page
> > > permissions is intended to enable fine-grained memory write enforcement by
> > > a VMM for security(guest OS monitoring) and usages such as device
> > > virtualization and memory check-point.
> > >
> > > How SPP Works:
> > >
> > > SPP is active when the "sub-page write protection" VM-execution control is
> > > 1. A new 4-level paging structure named SPP page table(SPPT) is
> > > introduced, SPPT will look up the guest physical addresses to derive a 64
> > > bit "sub-page permission" value containing sub-page write permissions. The
> > > lookup from guest-physical addresses to the sub-page region permissions is
> > > determined by a set of this SPPT paging structures.
> > >
> > > The SPPT is used to lookup write permission bits for the 128 byte sub-page
> > > regions containing in the 4KB guest physical page. EPT specifies the 4KB
> > > page level privileges that software is allowed when accessing the guest
> > > physical address, whereas SPPT defines the write permissions for software
> > > at the 128 byte granularity regions within a 4KB page. Write accesses
> > > prevented due to sub-page permissions looked up via SPPT are reported as
> > > EPT violation VM exits. Similar to EPT, a logical processor uses SPPT to
> > > lookup sub-page region write permissions for guest-physical addresses only
> > > when those addresses are used to access memory.
> > >
> > > Guest write access --> GPA --> Walk EPT --> EPT leaf entry -┐
> > > ┌---┘
> > > └-> if VMexec_control.spp && ept_leaf_entry.spp_bit (bit 61)
> > >  |
> > >  └->  --> EPT legacy behavior
> > >  |
> > >  |
> > >  └->   --> if ept_leaf_entry.writable
> > >   |
> > >   └->   --> Ignore SPP
> > >   |
> > >   └->  --> GPA --> Walk SPP 4-level table--┐
> > >   |
> > > ┌<--get-the-SPPT-point-from-VMCS-filed-<--┘
> > > |
> > > Walk SPP L4E table
> > > |
> > > └┐--> entry misconfiguration >--┐<┐
> > >  |  |

Re: [PATCH v9 00/20] simplify crypto wait for async op

2017-10-15 Thread Herbert Xu
On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote:
>
> Changes from v8:
> - Remove the translation of EAGAIN return code to the
>   previous return code of EBUSY for the user space
>   interface of algif as no one seems to rely on it as
>   requested by Herbert Xu.

Sorry, but I forgot to mention that EAGAIN is not a good value
to use because it's used by the network system calls for other
meanings (interrupted by a signal).

So if we stop doing the translation then we also need to pick
a different value, perhaps E2BIG or something similar that have
no current use within the crypto API or network API.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [GIT PULL] Introduce housekeeping subsystem v4

2017-10-15 Thread Frederic Weisbecker
2017-09-29 15:34 GMT+02:00 Frederic Weisbecker :
> On 28/09/2017 11:54, Ingo Molnar wrote:
>>
>>
>> * Frederic Weisbecker  wrote:
>>
>>> Ingo,
>>>
>>> Please pull the core/isolation-v4 branch that can be found at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
>>> core/isolation-v4
>>>
>>> HEAD: cf4c55aad44251369c8507c3823f9f9c51d4dc77
>>>
>>> Summary of changes:
>>>
>>> * Move the housekeeping code that was tied to NO_HZ to its own subsystem.
>>>Currently NO_HZ governs the other isolation features which is not
>>> right
>>>as dynticks is just an isolation feature like the others. We want to
>>>centralize the CPU isolation decisions to a subsystem of its own
>>> instead.
>>>
>>> * Integrate isolcpus code to housekeeping and treat it as a CPU isolation
>>>feature.
>>>
>>> * Reuse the "isolcpus=" kernel parameter to control the CPU isolation.
>>>For now only tick and domains can be isolated after this patchset:
>>>
>>> isolcpus=1-7 # isolate domains on CPU range 1 to 7
>>>  # "domain" flag is implicit by default to
>>>  # keep the current behaviour
>>>  isolcpus=domain,1-7  # do the same
>>>
>>> isolcpus=nohz,1-7# apply nohz_full to CPU range 1 to 7
>>>
>>> isolcpus=nohz,domain,1-7  # apply nohz_full and isolate domains
>>> of
>>>   # CPU range 1 to 7
>>>
>>> Thanks,
>>> Frederic
>>> ---
>>>
>>> Frederic Weisbecker (12):
>>>housekeeping: Move housekeeping related code to its own file
>>>watchdog: Use housekeeping_cpumask() instead of ad-hoc version
>>>housekeeping: Provide a dynamic off-case to housekeeping_any_cpu()
>>>housekeeping: Make housekeeping cpumask private
>>>housekeeping: Use its own static key
>>>housekeeping: Rename is_housekeeping_cpu to housekeeping_cpu
>>>housekeeping: Move it under its own config, independant from NO_HZ
>>>housekeeping: Introduce housekeeping flags
>>>housekeeping: Handle nohz_full= parameter
>>>housekeeping: Move isolcpus to housekeeping
>>>housekeeping: Add basic isolcpus flags
>>>housekeeping: Document isolcpus flags
>>>
>>>
>>>   Documentation/admin-guide/kernel-parameters.txt |  33 +++---
>>>   drivers/base/cpu.c  |  11 +-
>>>   drivers/net/ethernet/tile/tilegx.c  |   6 +-
>>>   include/linux/housekeeping.h|  51 
>>>   include/linux/sched.h   |   2 -
>>>   include/linux/tick.h|  39 +--
>>>   init/Kconfig|   7 ++
>>>   init/main.c |   2 +
>>>   kernel/Makefile |   1 +
>>>   kernel/cgroup/cpuset.c  |  15 +--
>>>   kernel/housekeeping.c   | 149
>>> 
>>>   kernel/rcu/tree_plugin.h|   3 +-
>>>   kernel/rcu/update.c |   3 +-
>>>   kernel/sched/core.c |  25 +---
>>>   kernel/sched/fair.c |   3 +-
>>>   kernel/sched/topology.c |  24 +---
>>>   kernel/time/tick-sched.c|  31 +
>>>   kernel/watchdog.c   |  13 +--
>>>   18 files changed, 276 insertions(+), 142 deletions(-)
>>
>>
>> Yeah, so while I agree that all this functionality needs to be factored
>> out and organized, I have a problem with this specific high level
>> organization.
>>
>> The main problem I think is that it's all called "housekeeping", which is
>> pretty
>> fuzzy and opaque. What does 'housekeeping' exactly mean? A dozen of
>> details if you
>> look at the code - and this name does not make it much easier to think
>> about this
>> whole problem category.
>
>
> Indeed I feel that housekeeping is probably not the best concept to express
> all these things. I'm all for something clearer.
>
>>
>> So how about introducing _two_ new high level concepts:
>>
>>1) 'global time handling'
>>2) 'double async CPU callbacks'
>>
>> The notion of 'global time' handling is obvious to everyone I think: it
>> involves
>> the system-global guarantee that certain kernel jobs will be executed
>> periodically. At least one CPU in the system needs to handle 'global
>> time'.
>>
>> The notion of 'double async CPU callbacks' is less obvious: it involves
>> the action
>> of invoking a callback on a CPU, that might be executed on _another_ CPU.
>>
>> I.e. there are 3 CPUs involved:
>>
>> - the invoking CPU
>> - the target CPU
>> - the CPU(s!) that will handle the callback (the housekeeping CPU
>> mask)
>>
>> For example the kmem-cache on_each_cpu() calls in mm/slab.c would fall
>> into this
>> category.
>
>

[PATCH] x86/intel_cacheinfo: remove redundant assignment to this_leaf

2017-10-15 Thread Colin King
From: Colin Ian King 

The variable this_leaf is being assigned a value that is never
read and it is being updated a little later with a newer value,
hence we can remove the redundant assignment.

Cleans up clang warning: Value stored to 'this_leaf' is never read

Signed-off-by: Colin Ian King 
---
 arch/x86/kernel/cpu/intel_cacheinfo.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index 24f749324c0f..9990a71e311f 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -831,7 +831,6 @@ static int __cache_amd_cpumap_setup(unsigned int cpu, int 
index,
} else if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
unsigned int apicid, nshared, first, last;
 
-   this_leaf = this_cpu_ci->info_list + index;
nshared = base->eax.split.num_threads_sharing + 1;
apicid = cpu_data(cpu).apicid;
first = apicid - (apicid % nshared);
-- 
2.14.1



[PATCH] dell-laptop: Fix keyboard led max_brightness property for Dell Latitude E6410

2017-10-15 Thread Pali Rohár
This machine reports number of keyboard backlight led levels, instead of
value of the last led level index. Therefore max_brightness properly needs
to be subtracted by 1 to match led max_brightness API.

Signed-off-by: Pali Rohár 
Reported-by: Gabriel M. Elder 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196913
---

Hi! I have not tested this patch yet, but I'm sending it, so other people
including Gabriel can test or review it.

If you have better idea how to call that quirk variable, then fell free
to rename it. I'm not happy with "kbd_led_num_of_levels_instead_of_last_index"
but I have nothing better in my mind.

---
 drivers/platform/x86/dell-laptop.c |   25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index f42159f..81f14ea 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -49,6 +49,7 @@
 
 struct quirk_entry {
u8 touchpad_led;
+   u8 kbd_led_num_of_levels_instead_of_last_index;
 
int needs_kbd_timeouts;
/*
@@ -79,6 +80,10 @@ static int __init dmi_matched(const struct dmi_system_id 
*dmi)
.kbd_timeouts = { 0, 5, 15, 60, 5 * 60, 15 * 60, -1 },
 };
 
+static struct quirk_entry quirk_dell_latitude_e6410 = {
+   .kbd_led_num_of_levels_instead_of_last_index = 1,
+};
+
 static struct platform_driver platform_driver = {
.driver = {
.name = "dell-laptop",
@@ -280,6 +285,15 @@ static int __init dmi_matched(const struct dmi_system_id 
*dmi)
},
.driver_data = &quirk_dell_xps13_9333,
},
+   {
+   .callback = dmi_matched,
+   .ident = "Dell Latitude E6410",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6410"),
+   },
+   .driver_data = &quirk_dell_latitude_e6410,
+   },
{ }
 };
 
@@ -1216,8 +1230,15 @@ static int kbd_get_info(struct kbd_info *info)
 
 static unsigned int kbd_get_max_level(void)
 {
-   if (kbd_info.levels != 0)
-   return kbd_info.levels;
+   u8 levels = kbd_info.levels;
+
+   if (quirks && quirks->kbd_led_num_of_levels_instead_of_last_index) {
+   if (levels > 1)
+   return levels - 1;
+   } else {
+   if (levels > 0)
+   return levels;
+   }
if (kbd_mode_levels_count > 0)
return kbd_mode_levels_count - 1;
return 0;
-- 
1.7.9.5



[PATCH] ipv6: addrconf: Use normal debugging style

2017-10-15 Thread Joe Perches
Remove local ADBG macro and use netdev_dbg/pr_debug

Miscellanea:

o Remove unnecessary debug message after allocation failure as there
  already is a dump_stack() on the failure paths
o Leave the allocation failure message on snmp6_alloc_dev as there
  is one code path that does not do a dump_stack()

Signed-off-by: Joe Perches 
---

o This is on top of David Ahern's proposed patch
  net: ipv6: Make inet6addr_validator a blocking notifier

 net/ipv6/addrconf.c | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 31ff12277bcf..c505e84dda1f 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -94,15 +94,6 @@
 #include 
 #include 
 
-/* Set to 3 to get tracing... */
-#define ACONF_DEBUG 2
-
-#if ACONF_DEBUG >= 3
-#define ADBG(fmt, ...) printk(fmt, ##__VA_ARGS__)
-#else
-#define ADBG(fmt, ...) do { if (0) printk(fmt, ##__VA_ARGS__); } while (0)
-#endif
-
 #defineINFINITY_LIFE_TIME  0x
 
 #define IPV6_MAX_STRLEN \
@@ -409,9 +400,8 @@ static struct inet6_dev *ipv6_add_dev(struct net_device 
*dev)
dev_hold(dev);
 
if (snmp6_alloc_dev(ndev) < 0) {
-   ADBG(KERN_WARNING
-   "%s: cannot allocate memory for statistics; dev=%s.\n",
-   __func__, dev->name);
+   netdev_dbg(dev, "%s: cannot allocate memory for statistics\n",
+  __func__);
neigh_parms_release(&nd_tbl, ndev->nd_parms);
dev_put(dev);
kfree(ndev);
@@ -419,9 +409,8 @@ static struct inet6_dev *ipv6_add_dev(struct net_device 
*dev)
}
 
if (snmp6_register_dev(ndev) < 0) {
-   ADBG(KERN_WARNING
-   "%s: cannot create /proc/net/dev_snmp6/%s\n",
-   __func__, dev->name);
+   netdev_dbg(dev, "%s: cannot create /proc/net/dev_snmp6/%s\n",
+  __func__, dev->name);
goto err_release;
}
 
@@ -966,7 +955,7 @@ static int ipv6_add_addr_hash(struct net_device *dev, 
struct inet6_ifaddr *ifa)
 
/* Ignore adding duplicate addresses on an interface */
if (ipv6_chk_same_addr(dev_net(dev), &ifa->addr, dev)) {
-   ADBG("ipv6_add_addr: already assigned\n");
+   netdev_dbg(dev, "ipv6_add_addr: already assigned\n");
err = -EEXIST;
goto out;
}
@@ -1029,7 +1018,6 @@ ipv6_add_addr(struct inet6_dev *idev, const struct 
in6_addr *addr,
 
ifa = kzalloc(sizeof(*ifa), gfp_flags);
if (!ifa) {
-   ADBG("ipv6_add_addr: malloc failed\n");
err = -ENOBUFS;
goto out;
}
@@ -2575,7 +2563,7 @@ void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, 
int len, bool sllao)
pinfo = (struct prefix_info *) opt;
 
if (len < sizeof(struct prefix_info)) {
-   ADBG("addrconf: prefix option too short\n");
+   netdev_dbg(dev, "addrconf: prefix option too short\n");
return;
}
 
@@ -4373,8 +4361,8 @@ static void addrconf_verify_rtnl(void)
if (time_before(next_sched, jiffies + ADDRCONF_TIMER_FUZZ_MAX))
next_sched = jiffies + ADDRCONF_TIMER_FUZZ_MAX;
 
-   ADBG(KERN_DEBUG "now = %lu, schedule = %lu, rounded schedule = %lu => 
%lu\n",
- now, next, next_sec, next_sched);
+   pr_debug("now = %lu, schedule = %lu, rounded schedule = %lu => %lu\n",
+now, next, next_sec, next_sched);
mod_delayed_work(addrconf_wq, &addr_chk_work, next_sched - now);
rcu_read_unlock_bh();
 }
-- 
2.10.0.rc2.1.g053435c



REPLY ME IMMEDIATELY..

2017-10-15 Thread Al-Shamali Ahmed
Good day dear friend,

As you are not a nationality of my country; i have a business proposal
for you, and it will be for the mutual benefit of the both of us.

I am Mr. Al-Shamali Ahmed, Working with Bank Of Africa here in Burkina
Faso Ouagadougou, I will like you to help me in receiving this fund
$23.5 million into your Bank Account for investment (Hotel industries
and Estate Building management) or any profitable business in your
country and I will give you 40%, for your assistance.

NOTE: The fund has been dormant (in-active) for some years in our Bank
here without any body coming for it. I want to apply for release of
the fund to you as the nearest person to our deceased customer Late
Capt. Rauof Noureldin, A nationality of Egypt (the owner of the
account) who died a long with his supposed next of kin in air crash
long time ago. I don't want the fund to go into our Bank treasury as
an abandoned fund,

If you are capable of handling this deal Contact me for more details .

IT'S A MATTER OF URGENCY!!!

Your Respectfully
Mr. Al-Shamali Ahmed


[PATCH] net: ceph: mark expected switch fall-throughs

2017-10-15 Thread Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Signed-off-by: Gustavo A. R. Silva 
---
 net/ceph/ceph_hash.c  | 12 +++-
 net/ceph/messenger.c  |  1 +
 net/ceph/mon_client.c |  1 +
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/net/ceph/ceph_hash.c b/net/ceph/ceph_hash.c
index 67bb1f1..9a5850f2 100644
--- a/net/ceph/ceph_hash.c
+++ b/net/ceph/ceph_hash.c
@@ -47,28 +47,38 @@ unsigned int ceph_str_hash_rjenkins(const char *str, 
unsigned int length)
 
/* handle the last 11 bytes */
c = c + length;
-   switch (len) {/* all the case statements fall through */
+   switch (len) {
case 11:
c = c + ((__u32)k[10] << 24);
+   /* fall through */
case 10:
c = c + ((__u32)k[9] << 16);
+   /* fall through */
case 9:
c = c + ((__u32)k[8] << 8);
/* the first byte of c is reserved for the length */
+   /* fall through */
case 8:
b = b + ((__u32)k[7] << 24);
+   /* fall through */
case 7:
b = b + ((__u32)k[6] << 16);
+   /* fall through */
case 6:
b = b + ((__u32)k[5] << 8);
+   /* fall through */
case 5:
b = b + k[4];
+   /* fall through */
case 4:
a = a + ((__u32)k[3] << 24);
+   /* fall through */
case 3:
a = a + ((__u32)k[2] << 16);
+   /* fall through */
case 2:
a = a + ((__u32)k[1] << 8);
+   /* fall through */
case 1:
a = a + k[0];
/* case 0: nothing left to add */
diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
index a67298c..73dac9d 100644
--- a/net/ceph/messenger.c
+++ b/net/ceph/messenger.c
@@ -429,6 +429,7 @@ static void ceph_sock_state_change(struct sock *sk)
switch (sk->sk_state) {
case TCP_CLOSE:
dout("%s TCP_CLOSE\n", __func__);
+   /* fall through */
case TCP_CLOSE_WAIT:
dout("%s TCP_CLOSE_WAIT\n", __func__);
con_sock_state_closing(con);
diff --git a/net/ceph/mon_client.c b/net/ceph/mon_client.c
index 63edc6e..b97c047 100644
--- a/net/ceph/mon_client.c
+++ b/net/ceph/mon_client.c
@@ -1281,6 +1281,7 @@ static struct ceph_msg *mon_alloc_msg(struct 
ceph_connection *con,
 * request had a non-zero tid.  Workaround this weirdness
 * by falling through to the allocate case.
 */
+   /* fall through */
case CEPH_MSG_MON_MAP:
case CEPH_MSG_MDS_MAP:
case CEPH_MSG_OSD_MAP:
-- 
2.7.4



[PATCH] net: dccp: mark expected switch fall-throughs

2017-10-15 Thread Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Notice that for options.c file, I placed the "fall through" comment
on its own line, which is what GCC is expecting to find.

Signed-off-by: Gustavo A. R. Silva 
---
This code was tested by compilation only (GCC 7.2.0 was used).
Please, verify if the actual intention of the code is to fall through.

 net/dccp/input.c   | 1 +
 net/dccp/options.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/dccp/input.c b/net/dccp/input.c
index fa6be97..d28d46b 100644
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -534,6 +534,7 @@ static int dccp_rcv_respond_partopen_state_process(struct 
sock *sk,
case DCCP_PKT_DATA:
if (sk->sk_state == DCCP_RESPOND)
break;
+   /* fall through */
case DCCP_PKT_DATAACK:
case DCCP_PKT_ACK:
/*
diff --git a/net/dccp/options.c b/net/dccp/options.c
index 51cdfc3..4e40db0 100644
--- a/net/dccp/options.c
+++ b/net/dccp/options.c
@@ -227,8 +227,8 @@ int dccp_parse_options(struct sock *sk, struct 
dccp_request_sock *dreq,
 * Ack vectors are processed by the TX CCID if it is
 * interested. The RX CCID need not parse Ack Vectors,
 * since it is only interested in clearing old state.
-* Fall through.
 */
+   /* fall through */
case DCCPO_MIN_TX_CCID_SPECIFIC ... DCCPO_MAX_TX_CCID_SPECIFIC:
if (ccid_hc_tx_parse_options(dp->dccps_hc_tx_ccid, sk,
 pkt_type, opt, value, len))
-- 
2.7.4



Re: [PATCH v2 2/5] dpaa_eth: move of_phy_connect() to the eth driver

2017-10-15 Thread Andrew Lunn
On Fri, Oct 13, 2017 at 05:50:09PM +0300, Madalin Bucur wrote:
> Signed-off-by: Madalin Bucur 
> ---
>  drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 48 +++--
>  drivers/net/ethernet/freescale/fman/mac.c  | 97 
> ++
>  drivers/net/ethernet/freescale/fman/mac.h  |  5 +-
>  3 files changed, 66 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c 
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index 4225806..7cf61d6 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -2435,6 +2435,48 @@ static void dpaa_eth_napi_disable(struct dpaa_priv 
> *priv)
>   }
>  }
>  
> +static void dpaa_adjust_link(struct net_device *net_dev)
> +{
> + struct mac_device *mac_dev;
> + struct dpaa_priv *priv;
> +
> + priv = netdev_priv(net_dev);
> + mac_dev = priv->mac_dev;
> + mac_dev->adjust_link(mac_dev);
> +}
> +
> +static int dpaa_phy_init(struct net_device *net_dev)
> +{
> + struct mac_device *mac_dev;
> + struct phy_device *phy_dev;
> + struct dpaa_priv *priv;
> +
> + priv = netdev_priv(net_dev);
> + mac_dev = priv->mac_dev;
> +
> + phy_dev = of_phy_connect(net_dev, mac_dev->phy_node,
> +  &dpaa_adjust_link, 0,
> +  mac_dev->phy_if);
> + if (!phy_dev) {
> + netif_err(priv, ifup, net_dev, "init_phy() failed\n");
> + return -ENODEV;
> + }
> +
> + /* Remove any features not supported by the controller */
> + phy_dev->supported &= mac_dev->if_support;
> +
> + /* Enable the symmetric and asymmetric PAUSE frame advertisements,
> +  * as most of the PHY drivers do not enable them by default.
> +  */

Hi Madalin

This is just moving code around, so the patch is O.K. However, it
would be nice to have a followup patch. This comment is wrong. The phy
driver should never enable symmetric and asymmetric PAUSE frames. The
MAC needs to, because only the MAC knows if the MAC supports pause
frames.

Andrew


[PATCH] xen/9pfs: mark expected switch fall-through in xen_9pfs_front_changed

2017-10-15 Thread Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Notice that in this particular case, I placed the "fall through" comment
on its own line, which is what GCC is expecting to find.

Signed-off-by: Gustavo A. R. Silva 
---
This code was tested by compilation only (GCC 7.2.0 was used).

 net/9p/trans_xen.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 6ad3e04..7ec5df9 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -510,7 +510,8 @@ static void xen_9pfs_front_changed(struct xenbus_device 
*dev,
case XenbusStateClosed:
if (dev->state == XenbusStateClosed)
break;
-   /* Missed the backend's CLOSING state -- fallthrough */
+   /* Missed the backend's CLOSING state */
+   /* fall through */
case XenbusStateClosing:
xenbus_frontend_closed(dev);
break;
-- 
2.7.4



[PATCH] scsi: hpsa: simplify hpsa_set_local_logical_count()

2017-10-15 Thread Christos Gkekas
Variable configured_logical_drive_count is defined as u8 and thus the
nested if statement always evaluates to true. Remove it and simplify.

Signed-off-by: Christos Gkekas 
---
 drivers/scsi/hpsa.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 9abe810..7d4f139 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -4090,14 +4090,7 @@ static int hpsa_set_local_logical_count(struct ctlr_info 
*h,
}
memset(id_ctlr, 0, sizeof(*id_ctlr));
rc = hpsa_bmic_id_controller(h, id_ctlr, sizeof(*id_ctlr));
-   if (!rc)
-   if (id_ctlr->configured_logical_drive_count < 256)
-   *nlocals = id_ctlr->configured_logical_drive_count;
-   else
-   *nlocals = le16_to_cpu(
-   id_ctlr->extended_logical_unit_count);
-   else
-   *nlocals = -1;
+   *nlocals = rc ? -1 : id_ctlr->configured_logical_drive_count;
return rc;
 }
 
-- 
2.7.4



Re: [PATCH v2 1/3] dt-bindings: Add vendor prefix for ProBox2

2017-10-15 Thread Andreas Färber
Am 19.09.2017 um 23:54 schrieb Andreas Färber:
> PROBOX2 is a TV box brand by Hong Kong based online reseller W2COMP
> Company Limited.
> 
> Cc: supp...@probox2.com
> Acked-by: Rob Herring 
> Signed-off-by: Andreas Färber 
> ---
>  v1 -> v2:
>  * Extend the vendor prefix explanation with info provided by PROBOX2
>  * Fix the commit message accordingly

No objections to the v2 texts, so full series applied:

https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-realtek.git/log/?h=v4.15/dt64

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)


[PATCH 0/3] char-bsr: Adjustments for two function implementations

2017-10-15 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 15 Oct 2017 22:02:34 +0200

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation in bsr_add_node()
  Improve a size determination in bsr_add_node()
  Adjust one function call together with a variable assignment

 drivers/char/bsr.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

-- 
2.14.2



[PATCH 1/3] char/bsr: Delete an error message for a failed memory allocation in bsr_add_node()

2017-10-15 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 15 Oct 2017 21:12:34 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/char/bsr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/char/bsr.c b/drivers/char/bsr.c
index a6cef548e01e..865eb457e539 100644
--- a/drivers/char/bsr.c
+++ b/drivers/char/bsr.c
@@ -203,7 +203,6 @@ static int bsr_add_node(struct device_node *bn)
int result;
 
if (!cur) {
-   printk(KERN_ERR "Unable to alloc bsr dev\n");
ret = -ENOMEM;
goto out_err;
}
-- 
2.14.2



[PATCH 2/3] char/bsr: Improve a size determination in bsr_add_node()

2017-10-15 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 15 Oct 2017 21:25:46 +0200

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/char/bsr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/char/bsr.c b/drivers/char/bsr.c
index 865eb457e539..d0597dfa4d88 100644
--- a/drivers/char/bsr.c
+++ b/drivers/char/bsr.c
@@ -197,8 +197,7 @@ static int bsr_add_node(struct device_node *bn)
num_bsr_devs = bsr_bytes_len / sizeof(u32);
 
for (i = 0 ; i < num_bsr_devs; i++) {
-   struct bsr_dev *cur = kzalloc(sizeof(struct bsr_dev),
- GFP_KERNEL);
+   struct bsr_dev *cur = kzalloc(sizeof(*cur), GFP_KERNEL);
struct resource res;
int result;
 
-- 
2.14.2



[PATCH 3/3] char/bsr: Adjust one function call together with a variable assignment

2017-10-15 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 15 Oct 2017 21:55:26 +0200

The script "checkpatch.pl" pointed information out like the following.

ERROR: do not use assignment in if condition

Thus fix the affected source code place.

Signed-off-by: Markus Elfring 
---
 drivers/char/bsr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/char/bsr.c b/drivers/char/bsr.c
index d0597dfa4d88..f11df210294a 100644
--- a/drivers/char/bsr.c
+++ b/drivers/char/bsr.c
@@ -320,7 +320,8 @@ static int __init bsr_init(void)
goto out_err_2;
}
 
-   if ((ret = bsr_create_devs(np)) < 0) {
+   ret = bsr_create_devs(np);
+   if (ret < 0) {
np = NULL;
goto out_err_3;
}
-- 
2.14.2



Crash during fork/clone

2017-10-15 Thread Stephan Müller
Hi,

in unregular intervals, I see the following crash. This crash happens if I 
start a test run that executes a large number of scripts sequentially. It 
happens with vanilla kernels from kernel.org and Fedora kernels. If my memory 
serves me well, I saw the first types of these crashes with 4.11.

This crash happens on native hardware as well as within a KVM guest.

Unfortunately, this crash cannot be easily triggered, it simply happens once 
in a while.

[ 8447.925544] BUG: unable to handle kernel NULL pointer dereference at 
003a
[ 8447.925590] IP: dup_fd+0x134/0x280
[ 8447.925605] PGD 0 
[ 8447.925606] P4D 0 

[ 8447.925634] Oops: 0002 [#1] SMP
[ 8447.925648] Modules linked in: ansi_cprng vfat fat vhost_net vhost tap fuse 
sha512_ssse3 sha512_generic ccm gcm salsa20_generic salsa20_x86_64 
camellia_generic camellia_aesni_avx2 camellia_aesni_avx_x86_64 ablk_helper 
camellia_x86_64 crypto_user des3_ede_x86_64 des_generic loop rfcomm 
xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter 
ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat 
ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 
nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c 
iptable_mangle iptable_raw iptable_security ebtable_filter ebtables 
ip6table_filter ip6_tables cmac bnep sunrpc nls_utf8 hfsplus iTCO_wdt 
iTCO_vendor_support joydev
[ 8447.925929]  intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel brcmfmac applesmc input_polldev kvm irqbypass brcmutil intel_cstate 
cfg80211 intel_uncore intel_rapl_perf btusb btrtl btbcm btintel bluetooth 
i2c_i801 intel_pch_thermal thunderbolt lpc_ich nvmem_core mmc_core 
snd_hda_codec_cirrus snd_hda_codec_hdmi snd_hda_codec_generic ecdh_generic 
rfkill snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq bcm5974 
snd_seq_device snd_pcm mei_me mei snd_timer snd spi_pxa2xx_pci shpchp 
soundcore sbs acpi_als sbshc kfifo_buf industrialio spi_pxa2xx_platform 
apple_bl binfmt_misc dm_crypt uas usb_storage hid_apple i915 crct10dif_pclmul 
crc32_pclmul crc32c_intel i2c_algo_bit drm_kms_helper ghash_clmulni_intel drm 
video
[ 8447.926189] CPU: 1 PID: 3179 Comm: test.sh Not tainted 
4.13.4-200.fc26.x86_64 #1
[ 8447.926218] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, 
BIOS MBP121.88Z.0171.B00.1708080033 08/08/2017
[ 8447.926258] task: 96da5fa4 task.stack: a2c109bd4000
[ 8447.926283] RIP: 0010:dup_fd+0x134/0x280
[ 8447.926299] RSP: 0018:a2c109bd7d78 EFLAGS: 00010202
[ 8447.926319] RAX: 00fd RBX: 0100 RCX: 
96dbeb3c97e8
[ 8447.926346] RDX: 0002 RSI: 96dbeb3c97e8 RDI: 
0100
[ 8447.926374] RBP: a2c109bd7db0 R08:  R09: 
96dad3243800
[ 8447.926401] R10: 96dbeb3c9000 R11: 96da8b796160 R12: 
96dc27d102c0
[ 8447.926427] R13: a2c109bd7e48 R14: 96dc531c6440 R15: 
96dc432423c0
[ 8447.926455] FS:  7f3239d45f80() GS:96dc6ec8() knlGS:

[ 8447.926485] CS:  0010 DS:  ES:  CR0: 80050033
[ 8447.926507] CR2: 003a CR3: 0001926ea000 CR4: 
003426e0
[ 8447.926534] Call Trace:
[ 8447.926552]  copy_process.part.30+0x898/0x1b30
[ 8447.926573]  ? selinux_file_alloc_security+0x37/0x60
[ 8447.926594]  ? alloc_file+0x65/0xc0
[ 8447.926610]  _do_fork+0xcf/0x390
[ 8447.926626]  ? __set_current_blocked+0x42/0x60
[ 8447.926645]  SyS_clone+0x19/0x20
[ 8447.926660]  do_syscall_64+0x67/0x140
[ 8447.926678]  entry_SYSCALL64_slow_path+0x25/0x25
[ 8447.926697] RIP: 0033:0x7f323921d53c
[ 8447.926712] RSP: 002b:7ffe3c3c7960 EFLAGS: 0246 ORIG_RAX: 
0038
[ 8447.926741] RAX: ffda RBX:  RCX: 
7f323921d53c
[ 8447.926768] RDX:  RSI:  RDI: 
01200011
[ 8447.926804] RBP: 7ffe3c3c79b0 R08: 7f3239d45f80 R09: 

[ 8447.926831] R10: 7f3239d46250 R11: 0246 R12: 

[ 8447.926858] R13: 7ffe3c3c7a60 R14:  R15: 

[ 8447.926886] Code: 4c 89 ce 4c 89 f7 89 da 4c 89 4d d0 e8 46 fa ff ff 4c 8b 
4d d0 4d 8b 56 08 8d 7b ff 31 c0 48 83 c7 01 4d 8b 49 08 4c 89 d1 eb 18  
48 ff 42 38 48 83 c0 01 48 8d 71 08 48 89 11 48 39 c7 74 31 
[ 8447.926980] RIP: dup_fd+0x134/0x280 RSP: a2c109bd7d78
[ 8447.927000] CR2: 003a
[ 8447.947234] ---[ end trace 0f02a0511461efba ]---

Ciao
Stephan


[PATCH] ipmi_si: Delete an error message for a failed memory allocation in try_smi_init()

2017-10-15 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 15 Oct 2017 22:30:11 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/char/ipmi/ipmi_si_intf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 55e0c42bee4d..2aed46a6c49c 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2095,7 +2095,6 @@ static int try_smi_init(struct smi_info *new_smi)
/* Allocate the state machine's data and initialize it. */
new_smi->si_sm = kmalloc(new_smi->handlers->size(), GFP_KERNEL);
if (!new_smi->si_sm) {
-   pr_err(PFX "Could not allocate state machine memory\n");
rv = -ENOMEM;
goto out_err;
}
-- 
2.14.2



Re: [PATCH] media: vb2: unify calling of set_page_dirty_lock

2017-10-15 Thread Sakari Ailus
Hi Nicolas,

On Tue, Oct 10, 2017 at 11:40:10AM -0400, Nicolas Dufresne wrote:
> Le mardi 29 août 2017 à 14:26 +0300, Stanimir Varbanov a écrit :
> > Currently videobuf2-dma-sg checks for dma direction for
> > every single page and videobuf2-dc lacks any dma direction
> > checks and calls set_page_dirty_lock unconditionally.
> > 
> > Thus unify and align the invocations of set_page_dirty_lock
> > for videobuf2-dc, videobuf2-sg  memory allocators with
> > videobuf2-vmalloc, i.e. the pattern used in vmalloc has been
> > copied to dc and dma-sg.
> 
> Just before we go too far in "doing like vmalloc", I would like to
> share this small video that display coherency issues when rendering
> vmalloc backed DMABuf over various KMS/DRM driver. I can reproduce this
> easily with Intel and MSM display drivers using UVC or Vivid as source.
> 
> The following is an HDMI capture of the following GStreamer pipeline
> running on Dragonboard 410c.
> 
> gst-launch-1.0 -v v4l2src device=/dev/video2 ! 
> video/x-raw,format=NV16,width=1280,height=720 ! kmssink
> https://people.collabora.com/~nicolas/vmalloc-issue.mov
> 
> Feedback on this issue would be more then welcome. It's not clear to me
> who's bug is this (v4l2, drm or iommu). The software is unlikely to be
> blamed as this same pipeline works fine with non-vmalloc based sources.

Could you elaborate this a little bit more? Which Intel CPU do you have
there?

Where are the buffers allocated for this GStreamer pipeline, is it v4l2src
or another element or somewhere else?

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi


Re: [PATCH] x86/intel_cacheinfo: remove redundant assignment to this_leaf

2017-10-15 Thread Borislav Petkov
On Sun, Oct 15, 2017 at 05:02:03PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The variable this_leaf is being assigned a value that is never
> read and it is being updated a little later with a newer value,
> hence we can remove the redundant assignment.
> 
> Cleans up clang warning: Value stored to 'this_leaf' is never read
> 
> Signed-off-by: Colin Ian King 
> ---
>  arch/x86/kernel/cpu/intel_cacheinfo.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
> b/arch/x86/kernel/cpu/intel_cacheinfo.c
> index 24f749324c0f..9990a71e311f 100644
> --- a/arch/x86/kernel/cpu/intel_cacheinfo.c
> +++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
> @@ -831,7 +831,6 @@ static int __cache_amd_cpumap_setup(unsigned int cpu, int 
> index,
>   } else if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
>   unsigned int apicid, nshared, first, last;
>  
> - this_leaf = this_cpu_ci->info_list + index;
>   nshared = base->eax.split.num_threads_sharing + 1;
>   apicid = cpu_data(cpu).apicid;
>   first = apicid - (apicid % nshared);
> -- 

Looks ok to me.

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


Re: Linux 4.14: Reported regressions as of Sunday, 2017-10-15

2017-10-15 Thread Borislav Petkov
On Sun, Oct 15, 2017 at 02:55:24PM +0200, Thorsten Leemhuis wrote:
> == Fixed since last report ==
> 
> "hangs when building e.g. perf" & "Random insta-reboots on AMD Phenom II"
> Status: Fixed by https://git.kernel.org/torvalds/c/67bb8e999e0a

That should be: b956575bed91 ("x86/mm: Flush more aggressively in lazy TLB 
mode")

> Reported: 2017-09-05
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1484723.html
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1501379.html
> https://lkml.kernel.org/r/cover.1508000261.git.l...@kernel.org
> Cause: 94b1b03b519b81c494900cb112aa00ed205cc2d9

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


Re: [PATCH v3 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants.

2017-10-15 Thread Chris Packham
Hi Boris,

On 15/10/17 02:13, Boris Brezillon wrote:
> Hi Kalyan,
> 
> On Thu, 28 Sep 2017 13:57:56 +1300
> Kalyan Kinthada  wrote:
> 
>> When the arbitration between NOR and NAND flash is enabled
>> the  field bit[21] in the Data Flash Control Register
>> needs to be set to 1 according to guidleine GL-5830741 mentioned
>> in Marvell Errata document MV-S501377-00, Rev. D.
> 
> The real question is, is this patch fixing a real bug or are you just
> setting this bit because a guideline says it should be set?

Yes that's a fair summary. It is in a document called "Functional 
Errata" so there is some feeling here that we (allied telesis) should 
follow up things in these kinds of documents.

> As far as I
> understand, noone fully understands what this bit does and why it needs
> to be set, so if you're not fixing a real bug, I'd prefer keeping the
> code unchanged code until someone complains for a good reason.

Agreed. We've certainly not noticed a change in behaviour on our boards. 
I've requested more information from Marvell through their support 
channels. I'll share what I can if/when they come back with something 
useful.

> 
> Regards,
> 
> Boris
> 
>>
>> This commit sets the FORCE_CSX bit to 1 for all
>> ARMADA370 variants as the arbitration is always enabled by default.
>> This change does not apply for pxa3xx variants because the FORCE_CSX
>> bit does not exist/reserved on the NFCv1.
>>
>> The NDCR_ND_MODE conflicts with the new NDCR_FORCE_CSX but is unused so
>> remove it along with NDCR_NAND_MODE.
>>
>> Signed-off-by: Kalyan Kinthada 
>> ---
>>   drivers/mtd/nand/pxa3xx_nand.c | 9 +++--
>>   1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
>> index 85cff68643e0..a6a7a5af7bed 100644
>> --- a/drivers/mtd/nand/pxa3xx_nand.c
>> +++ b/drivers/mtd/nand/pxa3xx_nand.c
>> @@ -67,8 +67,7 @@
>>   #define NDCR_DWIDTH_M  (0x1 << 26)
>>   #define NDCR_PAGE_SZ   (0x1 << 24)
>>   #define NDCR_NCSX  (0x1 << 23)
>> -#define NDCR_ND_MODE(0x3 << 21)
>> -#define NDCR_NAND_MODE  (0x0)
>> +#define NDCR_FORCE_CSX  (0x1 << 21)
>>   #define NDCR_CLR_PG_CNT(0x1 << 20)
>>   #define NFCV1_NDCR_ARB_CNTL(0x1 << 19)
>>   #define NFCV2_NDCR_STOP_ON_UNCOR   (0x1 << 19)
>> @@ -1464,6 +1463,9 @@ static int pxa3xx_nand_config_ident(struct 
>> pxa3xx_nand_info *info)
>>  info->chunk_size = PAGE_CHUNK_SIZE;
>>  info->reg_ndcr = 0x0; /* enable all interrupts */
>>  info->reg_ndcr |= (pdata->enable_arbiter) ? NDCR_ND_ARB_EN : 0;
>> +/* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#: GL-5830741 */
>> +if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
>> +info->reg_ndcr |= NDCR_FORCE_CSX;
>>  info->reg_ndcr |= NDCR_RD_ID_CNT(READ_ID_BYTES);
>>  info->reg_ndcr |= NDCR_SPARE_EN;
>>   
>> @@ -1498,6 +1500,9 @@ static void pxa3xx_nand_detect_config(struct 
>> pxa3xx_nand_info *info)
>>  info->reg_ndcr = ndcr &
>>  ~(NDCR_INT_MASK | NDCR_ND_ARB_EN | NFCV1_NDCR_ARB_CNTL);
>>  info->reg_ndcr |= (pdata->enable_arbiter) ? NDCR_ND_ARB_EN : 0;
>> +/* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#: GL-5830741 */
>> +if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
>> +info->reg_ndcr |= NDCR_FORCE_CSX;
>>  info->ndtr0cs0 = nand_readl(info, NDTR0CS0);
>>  info->ndtr1cs0 = nand_readl(info, NDTR1CS0);
>>   }
> 
> 



Re: [PATCH] scsi: scsi_transport_fc: make the function argument as const

2017-10-15 Thread kbuild test robot
Hi Bhumika,

[auto build test WARNING on mkp-scsi/for-next]
[also build test WARNING on v4.14-rc4 next-20171013]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Bhumika-Goyal/scsi-scsi_transport_fc-make-the-function-argument-as-const/20171016-040132
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
config: x86_64-randconfig-x015-201742 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/scsi/scsi_transport_fc.c: In function 'fc_attach_transport':
>> drivers/scsi/scsi_transport_fc.c:2198:7: warning: assignment discards 
>> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
 i->f = ft;
  ^

vim +/const +2198 drivers/scsi/scsi_transport_fc.c

5c44cd2af james.sm...@emulex.com 2005-06-10  2163  
^1da177e4 Linus Torvalds 2005-04-16  2164  struct 
scsi_transport_template *
b38779136 Bhumika Goyal  2017-10-13  2165  fc_attach_transport(const 
struct fc_function_template *ft)
^1da177e4 Linus Torvalds 2005-04-16  2166  {
^1da177e4 Linus Torvalds 2005-04-16  2167   int count;
24669f75a Jes Sorensen   2006-01-16  2168   struct fc_internal *i = 
kzalloc(sizeof(struct fc_internal),
24669f75a Jes Sorensen   2006-01-16  2169   
GFP_KERNEL);
^1da177e4 Linus Torvalds 2005-04-16  2170  
^1da177e4 Linus Torvalds 2005-04-16  2171   if (unlikely(!i))
^1da177e4 Linus Torvalds 2005-04-16  2172   return NULL;
^1da177e4 Linus Torvalds 2005-04-16  2173  
^1da177e4 Linus Torvalds 2005-04-16  2174   
i->t.target_attrs.ac.attrs = &i->starget_attrs[0];
^1da177e4 Linus Torvalds 2005-04-16  2175   
i->t.target_attrs.ac.class = &fc_transport_class.class;
^1da177e4 Linus Torvalds 2005-04-16  2176   
i->t.target_attrs.ac.match = fc_target_match;
^1da177e4 Linus Torvalds 2005-04-16  2177   i->t.target_size = 
sizeof(struct fc_starget_attrs);
^1da177e4 Linus Torvalds 2005-04-16  2178   
transport_container_register(&i->t.target_attrs);
^1da177e4 Linus Torvalds 2005-04-16  2179  
^1da177e4 Linus Torvalds 2005-04-16  2180   
i->t.host_attrs.ac.attrs = &i->host_attrs[0];
^1da177e4 Linus Torvalds 2005-04-16  2181   
i->t.host_attrs.ac.class = &fc_host_class.class;
^1da177e4 Linus Torvalds 2005-04-16  2182   
i->t.host_attrs.ac.match = fc_host_match;
^1da177e4 Linus Torvalds 2005-04-16  2183   i->t.host_size = 
sizeof(struct fc_host_attrs);
^1da177e4 Linus Torvalds 2005-04-16  2184   if 
(ft->get_fc_host_stats)
^1da177e4 Linus Torvalds 2005-04-16  2185   
i->t.host_attrs.statistics = &fc_statistics_group;
^1da177e4 Linus Torvalds 2005-04-16  2186   
transport_container_register(&i->t.host_attrs);
^1da177e4 Linus Torvalds 2005-04-16  2187  
^1da177e4 Linus Torvalds 2005-04-16  2188   
i->rport_attr_cont.ac.attrs = &i->rport_attrs[0];
^1da177e4 Linus Torvalds 2005-04-16  2189   
i->rport_attr_cont.ac.class = &fc_rport_class.class;
^1da177e4 Linus Torvalds 2005-04-16  2190   
i->rport_attr_cont.ac.match = fc_rport_match;
^1da177e4 Linus Torvalds 2005-04-16  2191   
transport_container_register(&i->rport_attr_cont);
^1da177e4 Linus Torvalds 2005-04-16  2192  
a53eb5e06 James Smart2007-04-27  2193   
i->vport_attr_cont.ac.attrs = &i->vport_attrs[0];
a53eb5e06 James Smart2007-04-27  2194   
i->vport_attr_cont.ac.class = &fc_vport_class.class;
a53eb5e06 James Smart2007-04-27  2195   
i->vport_attr_cont.ac.match = fc_vport_match;
a53eb5e06 James Smart2007-04-27  2196   
transport_container_register(&i->vport_attr_cont);
a53eb5e06 James Smart2007-04-27  2197  
^1da177e4 Linus Torvalds 2005-04-16 @2198   i->f = ft;
^1da177e4 Linus Torvalds 2005-04-16  2199  
^1da177e4 Linus Torvalds 2005-04-16  2200   /* Transport uses the 
shost workq for scsi scanning */
^1da177e4 Linus Torvalds 2005-04-16  2201   i->t.create_work_queue 
= 1;
^1da177e4 Linus Torvalds 2005-04-16  2202  
e02f3f592 Christoph Hellwig  2006-01-13  2203   i->t.user_scan = 
fc_user_scan;
5c44cd2af james.sm...@emulex.com 2005-06-10  2204  
^1da177e4 Linus Torvalds 2005-04-16  2205   /*
^1da177e4 Linus Torvalds 2005-04-16  2206* Setup SCSI Target 
Attributes.
^1da177e4 Linus Torvalds 2005-04-16  2207*/
^1da177e4 Linus Torvalds 2005-04-16  2208   count = 0;
^1da177e4 Linus Torvalds 2005-04-16  2209   
SETUP_STARGET_ATTRIBUTE

[PATCH] hamradio: baycom_par: use new parport device model

2017-10-15 Thread Sudip Mukherjee
Modify baycom driver to use the new parallel port device model.

Signed-off-by: Sudip Mukherjee 
---

Not tested on real hardware, only tested on kvm with 32 bit guest and
verified that the device is binding to the driver properly in par96_open
but then unbinding as the device was not found.

 drivers/net/hamradio/baycom_par.c | 48 +++
 1 file changed, 44 insertions(+), 4 deletions(-)

diff --git a/drivers/net/hamradio/baycom_par.c 
b/drivers/net/hamradio/baycom_par.c
index e178383..1f7ceaf 100644
--- a/drivers/net/hamradio/baycom_par.c
+++ b/drivers/net/hamradio/baycom_par.c
@@ -311,7 +311,9 @@ static void par96_wakeup(void *handle)
 static int par96_open(struct net_device *dev)
 {
struct baycom_state *bc = netdev_priv(dev);
+   struct pardev_cb par_cb;
struct parport *pp;
+   int i;
 
if (!dev || !bc)
return -ENXIO;
@@ -332,8 +334,21 @@ static int par96_open(struct net_device *dev)
}
memset(&bc->modem, 0, sizeof(bc->modem));
bc->hdrv.par.bitrate = 9600;
-   bc->pdev = parport_register_device(pp, dev->name, NULL, par96_wakeup, 
-par96_interrupt, PARPORT_DEV_EXCL, dev);
+   memset(&par_cb, 0, sizeof(par_cb));
+   par_cb.wakeup = par96_wakeup;
+   par_cb.irq_func = par96_interrupt;
+   par_cb.private = (void *)dev;
+   par_cb.flags = PARPORT_DEV_EXCL;
+   for (i = 0; i < NR_PORTS; i++)
+   if (baycom_device[i] == dev)
+   break;
+
+   if (i == NR_PORTS) {
+   pr_err("%s: no device found\n", bc_drvname);
+   parport_put_port(pp);
+   return -ENODEV;
+   }
+   bc->pdev = parport_register_dev_model(pp, dev->name, &par_cb, i);
parport_put_port(pp);
if (!bc->pdev) {
printk(KERN_ERR "baycom_par: cannot register parport at 
0x%lx\n", dev->base_addr);
@@ -490,12 +505,34 @@ static int baycom_ioctl(struct net_device *dev, struct 
ifreq *ifr,
 
 /* - */
 
+static int baycom_par_probe(struct pardevice *par_dev)
+{
+   struct device_driver *drv = par_dev->dev.driver;
+   int len = strlen(drv->name);
+
+   if (strncmp(par_dev->name, drv->name, len))
+   return -ENODEV;
+
+   return 0;
+}
+
+static struct parport_driver baycom_par_driver = {
+   .name = "bcp",
+   .probe = baycom_par_probe,
+   .devmodel = true,
+};
+
 static int __init init_baycompar(void)
 {
-   int i, found = 0;
+   int i, found = 0, ret;
char set_hw = 1;
 
printk(bc_drvinfo);
+
+   ret = parport_register_driver(&baycom_par_driver);
+   if (ret)
+   return ret;
+
/*
 * register net devices
 */
@@ -524,8 +561,10 @@ static int __init init_baycompar(void)
baycom_device[i] = dev;
}
 
-   if (!found)
+   if (!found) {
+   parport_unregister_driver(&baycom_par_driver);
return -ENXIO;
+   }
return 0;
 }
 
@@ -539,6 +578,7 @@ static void __exit cleanup_baycompar(void)
if (dev)
hdlcdrv_unregister(dev);
}
+   parport_unregister_driver(&baycom_par_driver);
 }
 
 module_init(init_baycompar);
-- 
1.9.1



[PATCH] parport: make parport_ip32_ops const and __initconst

2017-10-15 Thread Sudip Mukherjee
From: Bhumika Goyal 

Make this const as it is only used during a copy operation. This usage
is inside init function and the structure is not referenced after
initialisation, so make it __initconst too.

Signed-off-by: Bhumika Goyal 
Signed-off-by: Sudip Mukherjee 
---
 drivers/parport/parport_ip32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/parport/parport_ip32.c b/drivers/parport/parport_ip32.c
index 0186db7..6287307 100644
--- a/drivers/parport/parport_ip32.c
+++ b/drivers/parport/parport_ip32.c
@@ -1769,7 +1769,7 @@ static size_t parport_ip32_ecp_write_data(struct parport 
*p,
 
 /*--- Default parport operations ---*/
 
-static __initdata struct parport_operations parport_ip32_ops = {
+static const struct parport_operations parport_ip32_ops __initconst = {
.write_data = parport_ip32_write_data,
.read_data  = parport_ip32_read_data,
 
-- 
1.9.1



[PATCH] ALSA: pcm: remove redundant variable runtime

2017-10-15 Thread Colin King
From: Colin Ian King 

An earlier commit removed the access to variable runtime
and we are now left with unused variable that is redundant,
so remove it.

Cleans up the clang warning: Value stored to 'runtime' is never read

Fixes: e11f0f90a626 ("ALSA: pcm: remove SNDRV_PCM_IOCTL1_INFO internal command")
Signed-off-by: Colin Ian King 
---
 sound/core/pcm_native.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 2fec2feac387..a4d92e46c459 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -195,7 +195,6 @@ EXPORT_SYMBOL_GPL(snd_pcm_stream_unlock_irqrestore);
 
 int snd_pcm_info(struct snd_pcm_substream *substream, struct snd_pcm_info 
*info)
 {
-   struct snd_pcm_runtime *runtime;
struct snd_pcm *pcm = substream->pcm;
struct snd_pcm_str *pstr = substream->pstr;
 
@@ -211,7 +210,6 @@ int snd_pcm_info(struct snd_pcm_substream *substream, 
struct snd_pcm_info *info)
info->subdevices_count = pstr->substream_count;
info->subdevices_avail = pstr->substream_count - pstr->substream_opened;
strlcpy(info->subname, substream->name, sizeof(info->subname));
-   runtime = substream->runtime;
 
return 0;
 }
-- 
2.14.1



[PATCH] ALSA: ens137x: remove redundant variable result

2017-10-15 Thread Colin King
From: Colin Ian King 

Variable result is being assigned a value from a calculation
however the variable is never read, so this redundant variable
can be removed.

Cleans up clang warning: Value stored to 'result' is never read

Signed-off-by: Colin Ian King 
---
 sound/pci/ens1370.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/pci/ens1370.c b/sound/pci/ens1370.c
index d4cd6451fdca..39f79a6b5283 100644
--- a/sound/pci/ens1370.c
+++ b/sound/pci/ens1370.c
@@ -732,7 +732,7 @@ static void snd_es1371_codec_wait(struct snd_ac97 *ac97)
 
 static void snd_es1371_adc_rate(struct ensoniq * ensoniq, unsigned int rate)
 {
-   unsigned int n, truncm, freq, result;
+   unsigned int n, truncm, freq;
 
mutex_lock(&ensoniq->src_mutex);
n = rate / 3000;
@@ -740,7 +740,6 @@ static void snd_es1371_adc_rate(struct ensoniq * ensoniq, 
unsigned int rate)
n--;
truncm = (21 * n - 1) | 1;
freq = ((48000UL << 15) / rate) * n;
-   result = (48000UL << 15) / (freq / n);
if (rate >= 24000) {
if (truncm > 239)
truncm = 239;
-- 
2.14.1



  1   2   3   >