Re: [PATCH v4 2/2] of: Add unit tests for applying overlays

Hi Frank, On Fri, Apr 28, 2017 at 5:24 PM, Frank Rowand wrote: > On 04/28/17 04:25, Geert Uytterhoeven wrote: >> On Wed, Apr 26, 2017 at 2:09 AM, wrote: >>> create mode 100644 drivers/of/unittest-data/overlay.dts >>> create mode 100644

Re: [PATCH v4 2/2] of: Add unit tests for applying overlays

Hi Frank, On Fri, Apr 28, 2017 at 5:24 PM, Frank Rowand wrote: > On 04/28/17 04:25, Geert Uytterhoeven wrote: >> On Wed, Apr 26, 2017 at 2:09 AM, wrote: >>> create mode 100644 drivers/of/unittest-data/overlay.dts >>> create mode 100644 drivers/of/unittest-data/overlay_bad_phandle.dts >>>

[PATCH 7/7] crypto: aesni: add generic gcm(aes)

Now that the asm side of things can support all the valid lengths of ICV and all lengths of associated data, provide the glue code to expose a generic gcm(aes) crypto algorithm. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_glue.c | 208

[PATCH 7/7] crypto: aesni: add generic gcm(aes)

Now that the asm side of things can support all the valid lengths of ICV and all lengths of associated data, provide the glue code to expose a generic gcm(aes) crypto algorithm. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_glue.c | 208 - 1

[PATCH 5/7] crypto: aesni: make AVX2 AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 85

[PATCH 5/7] crypto: aesni: make AVX2 AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 85 ++-- 1 file

[PATCH 3/7] crypto: aesni: make AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 122

[PATCH 3/7] crypto: aesni: make AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 122 ++- 1 file

[PATCH 0/7] crypto: aesni: provide generic gcm(aes)

The current aesni AES-GCM implementation only offers support for rfc4106(gcm(aes)). This makes some things a little bit simpler (handling of associated data and authentication tag), but it means that non-IPsec users of gcm(aes) have to rely on gcm_base(ctr-aes-aesni,ghash-clmulni), which is much

[PATCH 0/7] crypto: aesni: provide generic gcm(aes)

The current aesni AES-GCM implementation only offers support for rfc4106(gcm(aes)). This makes some things a little bit simpler (handling of associated data and authentication tag), but it means that non-IPsec users of gcm(aes) have to rely on gcm_base(ctr-aes-aesni,ghash-clmulni), which is much

Re: Boot regression caused by kauditd

On Fri, Apr 28, 2017 at 8:30 AM, Paul Moore wrote: > On Thu, Apr 27, 2017 at 8:47 PM, Paul Moore wrote: >> In that case please send a proper inline patch to the audit mailing list >> and we'll review it. >> >> Thanks. > > Now that I'm back in front of a

Re: Boot regression caused by kauditd

On Fri, Apr 28, 2017 at 8:30 AM, Paul Moore wrote: > On Thu, Apr 27, 2017 at 8:47 PM, Paul Moore wrote: >> In that case please send a proper inline patch to the audit mailing list >> and we'll review it. >> >> Thanks. > > Now that I'm back in front of a proper screen/keyboard I've been > looking

Re: arm64: next-20170428 hangs on boot

> >> Hi, > >> > >> [adding Dave Miller, netdev, lkml] > > > > thanks > > > >>> On QEMU the next-20170428 hangs on boot for me due to kernel panic in > >>> rtnetlink_init(): > >>> > >>> void __init

Re: arm64: next-20170428 hangs on boot

> >> Hi, > >> > >> [adding Dave Miller, netdev, lkml] > > > > thanks > > > >>> On QEMU the next-20170428 hangs on boot for me due to kernel panic in > >>> rtnetlink_init(): > >>> > >>> void __init

Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform

From: Jan Kiszka Date: Mon, 24 Apr 2017 21:27:15 +0200 > The IOT2000 is industrial controller platform, derived from the Intel > Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the > IOT2040 has two of them. They can be told apart based on the board asset

Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform

From: Jan Kiszka Date: Mon, 24 Apr 2017 21:27:15 +0200 > The IOT2000 is industrial controller platform, derived from the Intel > Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the > IOT2040 has two of them. They can be told apart based on the board asset > tag in the DMI table.

Re: [PATCH 2/3] selinux: add checksum to policydb

2017-04-28 17:50 GMT+02:00 Stephen Smalley : > You seem to be conflating kernel policy with userspace policy. > security_load_policy() is provided with the kernel policy image, which > is the result of linking the kernel-relevant portions of all policy > modules together. A

Re: [PATCH 2/3] selinux: add checksum to policydb

2017-04-28 17:50 GMT+02:00 Stephen Smalley : > You seem to be conflating kernel policy with userspace policy. > security_load_policy() is provided with the kernel policy image, which > is the result of linking the kernel-relevant portions of all policy > modules together. A hash of that image will

Re: [REGRESSION] boot regression in next-20170428

From: Niklas Cassel <niklas.cas...@axis.com> Date: Fri, 28 Apr 2017 17:08:17 +0200 > Hello > > > Since next-20170428 > the ARTPEC-6 SoC (MACH_ARTPEC6) does no longer boot. > > It works fine with next-20170427. > > > I've

Re: [REGRESSION] boot regression in next-20170428

From: Niklas Cassel Date: Fri, 28 Apr 2017 17:08:17 +0200 > Hello > > > Since next-20170428 > the ARTPEC-6 SoC (MACH_ARTPEC6) does no longer boot. > > It works fine with next-20170427. > > > I've bisected it to the following commit: > > 6d684e54690caef45

Re: arm64: next-20170428 hangs on boot

From: Mark Rutland <mark.rutl...@arm.com> Date: Fri, 28 Apr 2017 15:52:34 +0100 > On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: >> Hi all, > > Hi, > > [adding Dave Miller, netdev, lkml] > >> On QEMU the next-20170428 hangs on boot for me due t

Re: arm64: next-20170428 hangs on boot

From: Mark Rutland Date: Fri, 28 Apr 2017 15:52:34 +0100 > On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: >> Hi all, > > Hi, > > [adding Dave Miller, netdev, lkml] > >> On QEMU the next-20170428 hangs on boot for me due to kernel panic in >>

[PATCH] staging: iio: isl29028: add isl29030 support

isl29030 is basically the same chip. The only difference is the chip's first pin. For isl29028 its named ADDR0 and can be used to change the chip's i2c address. For isl29030 on the other hand that pin is named Ials and is an analog current output proportional to ALS/IR. This change is irrelevant

[PATCH] staging: iio: isl29028: add isl29030 support

isl29030 is basically the same chip. The only difference is the chip's first pin. For isl29028 its named ADDR0 and can be used to change the chip's i2c address. For isl29030 on the other hand that pin is named Ials and is an analog current output proportional to ALS/IR. This change is irrelevant

Re: [PATCH v3] staging: speakup: fix wrong code indent

On Fri, Apr 28, 2017 at 11:43:26PM +0900, Michael Mera wrote: > Fix checkpatch messages: > ERROR: code indent should use tabs where possible > WARNING: Block comments should align the * on each line > > Changes: > - replace unnecessary multiline comment by a single line comment > - change

Re: [PATCH v3] staging: speakup: fix wrong code indent

On Fri, Apr 28, 2017 at 11:43:26PM +0900, Michael Mera wrote: > Fix checkpatch messages: > ERROR: code indent should use tabs where possible > WARNING: Block comments should align the * on each line > > Changes: > - replace unnecessary multiline comment by a single line comment > - change

Re: [PATCH v2] sched/fair: update scale invariance of PELT

Hi Vincent, Sorry for crashing the party this late. As you know, it takes a long period of uninterrupted review time to properly review PELT stuff. Disclaimer: I haven't read the rest of the thread yet. On Mon, Apr 10, 2017 at 11:18:29AM +0200, Vincent Guittot wrote: > The current

Re: [PATCH v2] sched/fair: update scale invariance of PELT

Hi Vincent, Sorry for crashing the party this late. As you know, it takes a long period of uninterrupted review time to properly review PELT stuff. Disclaimer: I haven't read the rest of the thread yet. On Mon, Apr 10, 2017 at 11:18:29AM +0200, Vincent Guittot wrote: > The current

Re: [PATCH v7 1/3] staging: typec: USB Type-C Port Manager (tcpm)

On Fri, Apr 28, 2017 at 06:14:44AM -0700, Guenter Roeck wrote: > On 04/28/2017 12:28 AM, Greg Kroah-Hartman wrote: > > On Thu, Apr 27, 2017 at 02:09:56PM -0700, Guenter Roeck wrote: > > > --- /dev/null > > > +++ b/drivers/staging/typec/pd.h > > > @@ -0,0 +1,281 @@ > > > +/* > > > + * Copyright

Re: [PATCH v7 1/3] staging: typec: USB Type-C Port Manager (tcpm)

On Fri, Apr 28, 2017 at 06:14:44AM -0700, Guenter Roeck wrote: > On 04/28/2017 12:28 AM, Greg Kroah-Hartman wrote: > > On Thu, Apr 27, 2017 at 02:09:56PM -0700, Guenter Roeck wrote: > > > --- /dev/null > > > +++ b/drivers/staging/typec/pd.h > > > @@ -0,0 +1,281 @@ > > > +/* > > > + * Copyright

Re: [PATCH v4 3/4] KEYS: Support for inserting a certificate into x86 bzImage

Mehmet Kayaalp wrote: > >> + /* TODO: update CRC */ > > > > Is this bit missing? > > I didn't add it, since I wasn't sure it was still used with secure boot. I'm not sure why secure boot would skip it if normal boot does it. You'll have to trawl the boot wrapper

Re: [PATCH v4 3/4] KEYS: Support for inserting a certificate into x86 bzImage

Mehmet Kayaalp wrote: > >> + /* TODO: update CRC */ > > > > Is this bit missing? > > I didn't add it, since I wasn't sure it was still used with secure boot. I'm not sure why secure boot would skip it if normal boot does it. You'll have to trawl the boot wrapper and kernel arch setup code

Re: [PATCH 1/2] of: fix uninitialized variable warning for overlay test

On 04/28/17 02:44, Arnd Bergmann wrote: > gcc warns that an empty device tree would cause undefined behavior: > > drivers/of/unittest.c: In function 'of_unittest': > drivers/of/unittest.c:2199:25: warning: 'last_sibling' may be used > uninitialized in this function [-Wmaybe-uninitialized] > >

Re: [PATCH 1/2] of: fix uninitialized variable warning for overlay test

On 04/28/17 02:44, Arnd Bergmann wrote: > gcc warns that an empty device tree would cause undefined behavior: > > drivers/of/unittest.c: In function 'of_unittest': > drivers/of/unittest.c:2199:25: warning: 'last_sibling' may be used > uninitialized in this function [-Wmaybe-uninitialized] > >

Re: [PATCH 2/3] selinux: add checksum to policydb

On Fri, 2017-04-28 at 17:16 +0200, Sebastien Buisson wrote: > 2017-04-27 20:47 GMT+02:00 Stephen Smalley : > > > I just checked, with the method of computing the checksum on a > > > (data, > > > len) pair on entry to security_load_policy() the checksum does > > > not > > >

Re: [PATCH 2/3] selinux: add checksum to policydb

On Fri, 2017-04-28 at 17:16 +0200, Sebastien Buisson wrote: > 2017-04-27 20:47 GMT+02:00 Stephen Smalley : > > > I just checked, with the method of computing the checksum on a > > > (data, > > > len) pair on entry to security_load_policy() the checksum does > > > not > > > change after using

Re: [PATCH 3/3] arm64/locking: qspinlocks and qrwlocks support

On Wed, Apr 26, 2017 at 03:39:47PM +0300, Yury Norov wrote: > On Thu, Apr 20, 2017 at 09:05:30PM +0200, Peter Zijlstra wrote: > > On Thu, Apr 20, 2017 at 09:23:18PM +0300, Yury Norov wrote: > > > Is there some test to reproduce the locking failure for the case. > > > > Possibly sysvsem stress

Re: [PATCH 3/3] arm64/locking: qspinlocks and qrwlocks support

On Wed, Apr 26, 2017 at 03:39:47PM +0300, Yury Norov wrote: > On Thu, Apr 20, 2017 at 09:05:30PM +0200, Peter Zijlstra wrote: > > On Thu, Apr 20, 2017 at 09:23:18PM +0300, Yury Norov wrote: > > > Is there some test to reproduce the locking failure for the case. > > > > Possibly sysvsem stress

RFC: i2c designware gpio recovery

Hi I have tried to add a gpio recovery gpio controller to the designware i2c driver. The attempt is attached below. I have a Intel(Altera) Cyclone V SOC Platform attached to a buggy power supply which gives a lockup on the i2c controller as a external device gives to much noise on the signal

RFC: i2c designware gpio recovery

Hi I have tried to add a gpio recovery gpio controller to the designware i2c driver. The attempt is attached below. I have a Intel(Altera) Cyclone V SOC Platform attached to a buggy power supply which gives a lockup on the i2c controller as a external device gives to much noise on the signal

Re: [PATCH 2/2] of: fix unittest build without CONFIG_OF_OVERLAY

On 04/28/17 02:44, Arnd Bergmann wrote: > We get a link error when the new tests are used by overlays > are not: > > drivers/of/built-in.o: In function `unflatten_device_tree': > (.init.text+0x967): undefined reference to `unittest_unflatten_overlay_base' > > This makes the #ifdef check match

Re: [PATCH 2/2] of: fix unittest build without CONFIG_OF_OVERLAY

On 04/28/17 02:44, Arnd Bergmann wrote: > We get a link error when the new tests are used by overlays > are not: > > drivers/of/built-in.o: In function `unflatten_device_tree': > (.init.text+0x967): undefined reference to `unittest_unflatten_overlay_base' > > This makes the #ifdef check match

Re: arm64: next-20170428 hangs on boot

On 04/28/2017 08:09 AM, Yury Norov wrote: > On Fri, Apr 28, 2017 at 03:52:34PM +0100, Mark Rutland wrote: >> On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: >>> Hi all, >> >> Hi, >> >> [adding Dave Miller, netdev, lkml] > > thanks >

Re: arm64: next-20170428 hangs on boot

On 04/28/2017 08:09 AM, Yury Norov wrote: > On Fri, Apr 28, 2017 at 03:52:34PM +0100, Mark Rutland wrote: >> On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: >>> Hi all, >> >> Hi, >> >> [adding Dave Miller, netdev, lkml] > > thanks >

Re: [RFC PATCH 0/3] arm64: queued spinlocks and rw-locks

On Thu, Apr 13, 2017 at 01:33:09PM +0300, Yury Norov wrote: > On Wed, Apr 12, 2017 at 01:04:55PM -0400, Adam Wallis wrote: > > On 4/10/2017 5:35 PM, Yury Norov wrote: > > > The patch of Jan Glauber enables queued spinlocks on arm64. I rebased it > > > on > > > latest kernel sources, and added a

Re: [RFC PATCH 0/3] arm64: queued spinlocks and rw-locks

On Thu, Apr 13, 2017 at 01:33:09PM +0300, Yury Norov wrote: > On Wed, Apr 12, 2017 at 01:04:55PM -0400, Adam Wallis wrote: > > On 4/10/2017 5:35 PM, Yury Norov wrote: > > > The patch of Jan Glauber enables queued spinlocks on arm64. I rebased it > > > on > > > latest kernel sources, and added a

Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable

On Fri, Apr 28, 2017 at 6:16 PM, Chris Brandt wrote: > On Friday, April 28, 2017, Andy Shevchenko wrote: >> Had you read the following, esp. Note there? >> >> * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does >> not >> * affect the pin's

Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable

On Fri, Apr 28, 2017 at 6:16 PM, Chris Brandt wrote: > On Friday, April 28, 2017, Andy Shevchenko wrote: >> Had you read the following, esp. Note there? >> >> * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does >> not >> * affect the pin's ability to drive output. 1

Re: nvdimm/pmem device lifetime

On Thu, Apr 27, 2017 at 9:37 PM, Mika Penttilä wrote: > Hi, > > Just wondering the pmem struct device vs gendisk lifetimes.. from > pmem_attach_disk(): > > device_add_disk(dev, disk); > devm_add_action_or_reset(dev, pmem_release_disk, disk); > > >

Re: nvdimm/pmem device lifetime

On Thu, Apr 27, 2017 at 9:37 PM, Mika Penttilä wrote: > Hi, > > Just wondering the pmem struct device vs gendisk lifetimes.. from > pmem_attach_disk(): > > device_add_disk(dev, disk); > devm_add_action_or_reset(dev, pmem_release_disk, disk); > > > where: > static void

[PATCH v9 4/4] arm64/syscalls: Optimize address limit check

Disable the generic address limit check in favor of an architecture specific optimized implementation. The address limit is checked on each syscall return path to user-mode. If it was changed, a generic handler is called to stop the kernel on an explicit check. Signed-off-by: Thomas Garnier

[PATCH v9 3/4] arm/syscalls: Optimize address limit check

Disable the generic address limit check in favor of an architecture specific optimized implementation. The address limit is checked on each syscall return path to user-mode path as well as the irq user-mode return function. If the address limit was changed, a generic handler is called to stop the

[PATCH v9 4/4] arm64/syscalls: Optimize address limit check

Disable the generic address limit check in favor of an architecture specific optimized implementation. The address limit is checked on each syscall return path to user-mode. If it was changed, a generic handler is called to stop the kernel on an explicit check. Signed-off-by: Thomas Garnier

[PATCH v9 3/4] arm/syscalls: Optimize address limit check

Disable the generic address limit check in favor of an architecture specific optimized implementation. The address limit is checked on each syscall return path to user-mode path as well as the irq user-mode return function. If the address limit was changed, a generic handler is called to stop the

[PATCH v9 2/4] x86/syscalls: Optimize address limit check

Disable the generic address limit check in favor of an architecture specific optimized implementation. The user-mode state check is added to the prepare_exit_to_usermode function. This function is called before any user-mode return on 32-bit and on the 64-bit syscall slowpath. For the 64-bit

[PATCH v9 2/4] x86/syscalls: Optimize address limit check

Disable the generic address limit check in favor of an architecture specific optimized implementation. The user-mode state check is added to the prepare_exit_to_usermode function. This function is called before any user-mode return on 32-bit and on the 64-bit syscall slowpath. For the 64-bit

[PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

Ensure that a syscall does not return to user-mode with a kernel address limit. If that happens, a process can corrupt kernel-mode memory and elevate privileges [1]. The CONFIG_ADDR_LIMIT_CHECK option disables the generic check so each architecture can create optimized versions. This option is

[PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

Ensure that a syscall does not return to user-mode with a kernel address limit. If that happens, a process can corrupt kernel-mode memory and elevate privileges [1]. The CONFIG_ADDR_LIMIT_CHECK option disables the generic check so each architecture can create optimized versions. This option is

[PATCH v2] staging: ks7010: remove line continuations in quoted strings

Checkpatch emits WARNING: Avoid line continuations in quoted strings. Remove line continuations - split strings using quotes. Signed-off-by: Ilia Sergachev --- Changes for v4: - improve indentation for better readability drivers/staging/ks7010/ks_hostif.c | 30

[PATCH v2] staging: ks7010: remove line continuations in quoted strings

Checkpatch emits WARNING: Avoid line continuations in quoted strings. Remove line continuations - split strings using quotes. Signed-off-by: Ilia Sergachev --- Changes for v4: - improve indentation for better readability drivers/staging/ks7010/ks_hostif.c | 30 --

Re: Boot regression caused by kauditd

On Thu, Apr 27, 2017 at 8:47 PM, Paul Moore wrote: > In that case please send a proper inline patch to the audit mailing list > and we'll review it. > > Thanks. Now that I'm back in front of a proper screen/keyboard I've been looking over your patch and while you are very

Re: Boot regression caused by kauditd

On Thu, Apr 27, 2017 at 8:47 PM, Paul Moore wrote: > In that case please send a proper inline patch to the audit mailing list > and we'll review it. > > Thanks. Now that I'm back in front of a proper screen/keyboard I've been looking over your patch and while you are very right in that the

Re: iov_iter_pipe warning.

On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote: > On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote: > > > Well it's been running an hour without incident, which looks promising. > > I'll leave it run, but I'd say you're on the right track given how quick > > it reproduced

Re: iov_iter_pipe warning.

On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote: > On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote: > > > Well it's been running an hour without incident, which looks promising. > > I'll leave it run, but I'd say you're on the right track given how quick > > it reproduced

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

On Fri, 28 Apr 2017, Joerg Roedel wrote: > On Fri, Apr 28, 2017 at 02:46:34PM +0200, Gerald Schaefer wrote: > > On Thu, 27 Apr 2017 23:03:25 +0200 > > Joerg Roedel wrote: > > > > > > Well, there is a separate zpci_dev for each pci_dev on s390, > > > > and each of those has its

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

On Fri, 28 Apr 2017, Joerg Roedel wrote: > On Fri, Apr 28, 2017 at 02:46:34PM +0200, Gerald Schaefer wrote: > > On Thu, 27 Apr 2017 23:03:25 +0200 > > Joerg Roedel wrote: > > > > > > Well, there is a separate zpci_dev for each pci_dev on s390, > > > > and each of those has its own separate

Re: [PATCH v4 2/2] of: Add unit tests for applying overlays

On 04/28/17 04:25, Geert Uytterhoeven wrote: > Hi Frank, > > On Wed, Apr 26, 2017 at 2:09 AM, wrote: >> From: Frank Rowand >> >> Existing overlay unit tests examine individual pieces of the overlay >> code. The new tests target the entire process

Re: [PATCH v4 2/2] of: Add unit tests for applying overlays

On 04/28/17 04:25, Geert Uytterhoeven wrote: > Hi Frank, > > On Wed, Apr 26, 2017 at 2:09 AM, wrote: >> From: Frank Rowand >> >> Existing overlay unit tests examine individual pieces of the overlay >> code. The new tests target the entire process of applying an overlay. >> >> Signed-off-by:

Re: [PATCH linux v9 2/5] hwmon: occ: Add sysfs interface

On 04/02/2017 06:19 AM, Guenter Roeck wrote: On 03/14/2017 01:55 PM, Eddie James wrote: From: "Edward A. James" Add a generic mechanism to expose the sensors provided by the OCC in sysfs. Signed-off-by: Edward A. James Signed-off-by: Andrew Jeffery

Re: [PATCH linux v9 2/5] hwmon: occ: Add sysfs interface

On 04/02/2017 06:19 AM, Guenter Roeck wrote: On 03/14/2017 01:55 PM, Eddie James wrote: From: "Edward A. James" Add a generic mechanism to expose the sensors provided by the OCC in sysfs. Signed-off-by: Edward A. James Signed-off-by: Andrew Jeffery --- Documentation/hwmon/occ |

Re: [PATCH 2/3] selinux: add checksum to policydb

2017-04-27 20:47 GMT+02:00 Stephen Smalley : >> I just checked, with the method of computing the checksum on a (data, >> len) pair on entry to security_load_policy() the checksum does not >> change after using setsebool. So it seems I would need to call >>

Re: [PATCH 2/3] selinux: add checksum to policydb

2017-04-27 20:47 GMT+02:00 Stephen Smalley : >> I just checked, with the method of computing the checksum on a (data, >> len) pair on entry to security_load_policy() the checksum does not >> change after using setsebool. So it seems I would need to call >> security_read_policy() to retrieve the

RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable

On Friday, April 28, 2017, Andy Shevchenko wrote: > Had you read the following, esp. Note there? > > * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does > not > * affect the pin's ability to drive output. 1 enables input, 0 > disables > * input. > > For me manual

RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable

On Friday, April 28, 2017, Andy Shevchenko wrote: > Had you read the following, esp. Note there? > > * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input. Note that this does > not > * affect the pin's ability to drive output. 1 enables input, 0 > disables > * input. > > For me manual

Re: [PATCH] [4.11 regression] cpsw/netcp: refine cpts dependency

* Arnd Bergmann [170428 08:06]: > Tony Lindgren reports a kernel oops that resulted from my compile-time > fix on the default config. This shows two problems: > > a) configurations that did not already enable PTP_1588_CLOCK will >now miss the cpts driver > > b) when cpts

Re: [PATCH] [4.11 regression] cpsw/netcp: refine cpts dependency

* Arnd Bergmann [170428 08:06]: > Tony Lindgren reports a kernel oops that resulted from my compile-time > fix on the default config. This shows two problems: > > a) configurations that did not already enable PTP_1588_CLOCK will >now miss the cpts driver > > b) when cpts support is

Re: arm64: next-20170428 hangs on boot

On Fri, Apr 28, 2017 at 03:52:34PM +0100, Mark Rutland wrote: > On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: > > Hi all, > > Hi, > > [adding Dave Miller, netdev, lkml] thanks > > On QEMU the next-20170428 hangs on boot for me due to kernel p

Re: arm64: next-20170428 hangs on boot

On Fri, Apr 28, 2017 at 03:52:34PM +0100, Mark Rutland wrote: > On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: > > Hi all, > > Hi, > > [adding Dave Miller, netdev, lkml] thanks > > On QEMU the next-20170428 hangs on boot for me due to kernel p

Re: [PATCH net-next 08/18] net: dsa: mv88e6xxx: move generic VTU GetNext

Hi Andrew, Andrew Lunn writes: >> +/* Write the VID to iterate from only once */ >> +if (!entry->valid) { >> +err = mv88e6xxx_g1_vtu_vid_write(chip, entry); >> +if (err) >> +return err; >> +} > > Please could you add a

Re: [PATCH net-next 08/18] net: dsa: mv88e6xxx: move generic VTU GetNext

Hi Andrew, Andrew Lunn writes: >> +/* Write the VID to iterate from only once */ >> +if (!entry->valid) { >> +err = mv88e6xxx_g1_vtu_vid_write(chip, entry); >> +if (err) >> +return err; >> +} > > Please could you add a bigger comment. It

[REGRESSION] boot regression in next-20170428

Hello Since next-20170428 the ARTPEC-6 SoC (MACH_ARTPEC6) does no longer boot. It works fine with next-20170427. I've bisected it to the following commit: 6d684e54690caef45cf14051ddeb7c71beeb681b is the first bad commit commit 6d684e54690caef45cf14051ddeb7c71beeb681b Author: Herbert Xu <h

[REGRESSION] boot regression in next-20170428

Hello Since next-20170428 the ARTPEC-6 SoC (MACH_ARTPEC6) does no longer boot. It works fine with next-20170427. I've bisected it to the following commit: 6d684e54690caef45cf14051ddeb7c71beeb681b is the first bad commit commit 6d684e54690caef45cf14051ddeb7c71beeb681b Author: Herbert Xu Date

RE: [PATCH v8 1/3] backlight arcxcnn add arc to vendor prefix

> On Thursday, April 27, 2017 8:37 AM, Geert Uytterhoeven wrote: > > On Tue, Apr 25, 2017 at 6:36 PM, Jingoo Han wrote: > > > On Monday, April 24, 2017 1:56 PM, Olimpiu Dejeu wrote: > > >> > > >> On Mon, April 24, 2017 11:10 AM, Rob Herring < r...@kernel.org> wrote: > > >> >

RE: [PATCH v8 1/3] backlight arcxcnn add arc to vendor prefix

> On Thursday, April 27, 2017 8:37 AM, Geert Uytterhoeven wrote: > > On Tue, Apr 25, 2017 at 6:36 PM, Jingoo Han wrote: > > > On Monday, April 24, 2017 1:56 PM, Olimpiu Dejeu wrote: > > >> > > >> On Mon, April 24, 2017 11:10 AM, Rob Herring < r...@kernel.org> wrote: > > >> > > >> > On Wed, Mar

Re: [PATCH v2] drm/rockchip: Set line flag config register in vop_crtc_enable

On Fri, Apr 28, 2017 at 03:37:47PM +0800, Jeffy Chen wrote: > We need to set vop config done after update line flag config, it's a > new requirement for chips newer than rk3368. > > Since we would only use line flag irq for vact_end, let's move it to > vop_crtc_enable. > > v2: Remove unused

Re: [PATCH v2] drm/rockchip: Set line flag config register in vop_crtc_enable

On Fri, Apr 28, 2017 at 03:37:47PM +0800, Jeffy Chen wrote: > We need to set vop config done after update line flag config, it's a > new requirement for chips newer than rk3368. > > Since we would only use line flag irq for vact_end, let's move it to > vop_crtc_enable. > > v2: Remove unused

[PATCH] [4.11 regression] cpsw/netcp: refine cpts dependency

Tony Lindgren reports a kernel oops that resulted from my compile-time fix on the default config. This shows two problems: a) configurations that did not already enable PTP_1588_CLOCK will now miss the cpts driver b) when cpts support is disabled, the driver crashes. This is a preexisting

[PATCH] [4.11 regression] cpsw/netcp: refine cpts dependency

Tony Lindgren reports a kernel oops that resulted from my compile-time fix on the default config. This shows two problems: a) configurations that did not already enable PTP_1588_CLOCK will now miss the cpts driver b) when cpts support is disabled, the driver crashes. This is a preexisting

Re: [REGRESSION next-20170426] Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") causes oops in mvneta

On Fri, Apr 28, 2017 at 06:48:33PM +0530, Sricharan R wrote: > Also, probably this patch now going through the iommu tree looks more apt, > as its for probe-deferral. > Joerg, is that correct ? Definitly. Please send the patch directly to me and I put it in the tree. Thanks, Joerg

Re: [REGRESSION next-20170426] Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") causes oops in mvneta

On Fri, Apr 28, 2017 at 06:48:33PM +0530, Sricharan R wrote: > Also, probably this patch now going through the iommu tree looks more apt, > as its for probe-deferral. > Joerg, is that correct ? Definitly. Please send the patch directly to me and I put it in the tree. Thanks, Joerg

Re: [PATCH] arm64: Print DT machine model in setup_machine_fdt()

On Thu, Apr 27, 2017 at 02:33:05PM +0200, Geert Uytterhoeven wrote: > On arm32, the machine model specified in the device tree is printed > during boot-up, courtesy of of_flat_dt_match_machine(). > > On arm64, of_flat_dt_match_machine() is not called, and the machine > model information is not

Re: [PATCH] arm64: Print DT machine model in setup_machine_fdt()

On Thu, Apr 27, 2017 at 02:33:05PM +0200, Geert Uytterhoeven wrote: > On arm32, the machine model specified in the device tree is printed > during boot-up, courtesy of of_flat_dt_match_machine(). > > On arm64, of_flat_dt_match_machine() is not called, and the machine > model information is not

RE: [PATCH v2] clk: Provide dummy of_clk_get_from_provider() for compile-testing

> -Original Message- > From: devicetree-ow...@vger.kernel.org [mailto:devicetree- > ow...@vger.kernel.org] On Behalf Of Geert Uytterhoeven > Sent: Friday, April 28, 2017 3:09 PM > To: Michael Turquette ; Stephen Boyd > ; Russell King

RE: [PATCH v2] clk: Provide dummy of_clk_get_from_provider() for compile-testing

> -Original Message- > From: devicetree-ow...@vger.kernel.org [mailto:devicetree- > ow...@vger.kernel.org] On Behalf Of Geert Uytterhoeven > Sent: Friday, April 28, 2017 3:09 PM > To: Michael Turquette ; Stephen Boyd > ; Russell King ; Rob Herring > ; Mark Rutland ; John Crispin > ; Ralf

Re: [PATCH] clk: stm32h7: Add stm32h743 clock driver

Hi Stephen Sorry for delay i was on sick live On 04/07/2017 09:51 PM, Stephen Boyd wrote: On 04/06, Gabriel Fernandez wrote: On 04/06/2017 12:32 AM, Stephen Boyd wrote: On 03/15, gabriel.fernan...@st.com wrote: diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt

Re: [PATCH] clk: stm32h7: Add stm32h743 clock driver

Hi Stephen Sorry for delay i was on sick live On 04/07/2017 09:51 PM, Stephen Boyd wrote: On 04/06, Gabriel Fernandez wrote: On 04/06/2017 12:32 AM, Stephen Boyd wrote: On 03/15, gabriel.fernan...@st.com wrote: diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

Hi Gerald, On Fri, Apr 28, 2017 at 02:46:34PM +0200, Gerald Schaefer wrote: > On Thu, 27 Apr 2017 23:03:25 +0200 > Joerg Roedel wrote: > > > > Well, there is a separate zpci_dev for each pci_dev on s390, > > > and each of those has its own separate dma-table (thus not shared).

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

Hi Gerald, On Fri, Apr 28, 2017 at 02:46:34PM +0200, Gerald Schaefer wrote: > On Thu, 27 Apr 2017 23:03:25 +0200 > Joerg Roedel wrote: > > > > Well, there is a separate zpci_dev for each pci_dev on s390, > > > and each of those has its own separate dma-table (thus not shared). > > > > Is

Re: [PATCH] iio: stm32 trigger: Add support for TRGO2 triggers

On 04/27/2017 07:49 AM, Jonathan Cameron wrote: > On 26/04/17 09:55, Benjamin Gaignard wrote: >> 2017-04-26 10:17 GMT+02:00 Fabrice Gasnier : >>> Add support for TRGO2 trigger that can be found on STM32F7. >>> Add additional master modes supported by TRGO2. > These

Re: [PATCH] iio: stm32 trigger: Add support for TRGO2 triggers

On 04/27/2017 07:49 AM, Jonathan Cameron wrote: > On 26/04/17 09:55, Benjamin Gaignard wrote: >> 2017-04-26 10:17 GMT+02:00 Fabrice Gasnier : >>> Add support for TRGO2 trigger that can be found on STM32F7. >>> Add additional master modes supported by TRGO2. > These additional modes would benefit

<    1   2   3   4   5   6   7   8   9   10   >