Re: [PATCH 05/12] arm64: dts: Add I2C nodes for Hi3660

Hi, Rob Thanks for the review. On 2017年05月23日 08:39, Rob Herring wrote: On Wed, May 17, 2017 at 04:37:38PM +0800, Guodong Xu wrote: From: Zhangfei Gao Add I2C nodes for Hi3660-hikey960. On HiKey960, I2C0, I2C7 is connected to Low Speed Expansion Connector. I2C1 is

Re: [PATCH 05/12] arm64: dts: Add I2C nodes for Hi3660

Hi, Rob Thanks for the review. On 2017年05月23日 08:39, Rob Herring wrote: On Wed, May 17, 2017 at 04:37:38PM +0800, Guodong Xu wrote: From: Zhangfei Gao Add I2C nodes for Hi3660-hikey960. On HiKey960, I2C0, I2C7 is connected to Low Speed Expansion Connector. I2C1 is connected to ADV7535.

Re: [PATCH 7/7] DWARF: add the config option

* H. Peter Anvin wrote: > On 05/22/17 04:12, Ingo Molnar wrote: > \>> > >> This construct might be useful for other arches, which is why I called > >> it "FP" instead of "BP". But then I ruined that with the last 3 :-) > > > > Please call it BP - 'FP' can easily be read as

Re: [PATCH 7/7] DWARF: add the config option

* H. Peter Anvin wrote: > On 05/22/17 04:12, Ingo Molnar wrote: > \>> > >> This construct might be useful for other arches, which is why I called > >> it "FP" instead of "BP". But then I ruined that with the last 3 :-) > > > > Please call it BP - 'FP' can easily be read as floating-point,

[PATCH]pstore: Don't warn if data is uncompressed and type is not PSTORE_TYPE_DMESG

commit 9abd3d5f ("pstore: Extract common arguments into structure") moved record decompression to function. decompress_record() gets called without checking type and compressed flag. Warning will be reported if data is uncompressed. Pstore type PSTORE_TYPE_PPC_OPAL, PSTORE_TYPE_PPC_COMMON

[PATCH]pstore: Don't warn if data is uncompressed and type is not PSTORE_TYPE_DMESG

commit 9abd3d5f ("pstore: Extract common arguments into structure") moved record decompression to function. decompress_record() gets called without checking type and compressed flag. Warning will be reported if data is uncompressed. Pstore type PSTORE_TYPE_PPC_OPAL, PSTORE_TYPE_PPC_COMMON

Re: [CFT][PATCH] ptrace: Properly initialize ptracer_cred on fork

On Mon, 22 May 2017 23:04:48 +0200, Eric W. Biederman wrote: > > > When I introduced ptracer_cred I failed to consider the weirdness of > fork where the task_struct copies the old value by default. This > winds up leaving ptracer_cred set even when a process forks and > the child process does

Re: [CFT][PATCH] ptrace: Properly initialize ptracer_cred on fork

On Mon, 22 May 2017 23:04:48 +0200, Eric W. Biederman wrote: > > > When I introduced ptracer_cred I failed to consider the weirdness of > fork where the task_struct copies the old value by default. This > winds up leaving ptracer_cred set even when a process forks and > the child process does

Re: [RFC 0/3] misc: new serdev based drivers for w2sg00x4 GPS module and w2cbw003 wifi/bluetooth

Hi Rob, > Am 23.05.2017 um 04:26 schrieb Rob Herring : > > On Sun, May 21, 2017 at 5:44 AM, H. Nikolaus Schaller > wrote: >> Since our proposed API was not acceptable and the new serdev API has arrived >> in 4.11 kernels, >> we finally took the

Re: [RFC 0/3] misc: new serdev based drivers for w2sg00x4 GPS module and w2cbw003 wifi/bluetooth

Hi Rob, > Am 23.05.2017 um 04:26 schrieb Rob Herring : > > On Sun, May 21, 2017 at 5:44 AM, H. Nikolaus Schaller > wrote: >> Since our proposed API was not acceptable and the new serdev API has arrived >> in 4.11 kernels, >> we finally took the challenge to update the w2sg and w2cbw drivers

perf/x86/intel: Collecting CPU-local performance counters from all cores in parallel

I'm working on a system-wide profiling tool that uses perf_event to gather CPU-local performance counters (L2/L3 cache misses, etc.) across all CPUs (hyperthreads) of a multi-socket system. We'd like for the monitoring process to run on a single core, and to be able to sample at frequent, regular

perf/x86/intel: Collecting CPU-local performance counters from all cores in parallel

I'm working on a system-wide profiling tool that uses perf_event to gather CPU-local performance counters (L2/L3 cache misses, etc.) across all CPUs (hyperthreads) of a multi-socket system. We'd like for the monitoring process to run on a single core, and to be able to sample at frequent, regular

staging: sm750fb: Replace CamelCase variable names with underscores

Replace CamelCase variable names with underscores to comply with the standard kernel coding style Signed-off-by: Richa Jha --- drivers/staging/sm750fb/ddk750_chip.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git

staging: sm750fb: Replace CamelCase variable names with underscores

Replace CamelCase variable names with underscores to comply with the standard kernel coding style Signed-off-by: Richa Jha --- drivers/staging/sm750fb/ddk750_chip.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git

Re: [PATCH] mmc: renesas-sdhi: export renesas_sdhi_probe

On Mon, May 22, 2017 at 03:33:08PM +0200, Arnd Bergmann wrote: > We now build the sdhi driver in separate modules, which means we > have to export the symbols that are called from another module: > > ERROR: "renesas_sdhi_remove" [drivers/mmc/host/renesas_sdhi_sys_dmac.ko] > undefined! > ERROR:

Re: [PATCH] mmc: renesas-sdhi: export renesas_sdhi_probe

On Mon, May 22, 2017 at 03:33:08PM +0200, Arnd Bergmann wrote: > We now build the sdhi driver in separate modules, which means we > have to export the symbols that are called from another module: > > ERROR: "renesas_sdhi_remove" [drivers/mmc/host/renesas_sdhi_sys_dmac.ko] > undefined! > ERROR:

[PATCH net v2 2/2] net: ieee802154: fix net_device reference release too early

This patch fixes the kernel oops when release net_device reference in advance. In function raw_sendmsg(i think the dgram_sendmsg has the same problem), there is a race condition between dev_put and dev_queue_xmit when the device is gong that maybe lead to dev_queue_ximt to see an illegal

[PATCH net v2 2/2] net: ieee802154: fix net_device reference release too early

This patch fixes the kernel oops when release net_device reference in advance. In function raw_sendmsg(i think the dgram_sendmsg has the same problem), there is a race condition between dev_put and dev_queue_xmit when the device is gong that maybe lead to dev_queue_ximt to see an illegal

pxa3xx-nand failing to find device on linux-next

Hi, I'm doing some testing on linux-next and I'm finding that my nand flash has disappeared. pxa3xx-nand f10d.flash: This platform can't do DMA on this device pxa3xx-nand f10d.flash: non-supported command ef pxa3xx-nand f10d.flash: non-supported command ee pxa3xx-nand

pxa3xx-nand failing to find device on linux-next

Hi, I'm doing some testing on linux-next and I'm finding that my nand flash has disappeared. pxa3xx-nand f10d.flash: This platform can't do DMA on this device pxa3xx-nand f10d.flash: non-supported command ef pxa3xx-nand f10d.flash: non-supported command ee pxa3xx-nand

Re: [PATCH] pci: iov: use device lock to protect IOV sysfs accesses

On Mon, May 22, 2017 at 03:50:23PM -0700, Jakub Kicinski wrote: > PCI core sets the driver pointer before calling ->probe() and only > clears it after ->remove(). This means driver's ->sriov_configure() > callback will happily race with probe() and remove(), most likely > leading to BUGs, since

Re: [PATCH v3.1 4/6] mm/hugetlb: Allow architectures to override huge_pte_clear()

On Mon, 22 May 2017 17:25:55 +0100 Punit Agrawal wrote: > When unmapping a hugepage range, huge_pte_clear() is used to clear the > page table entries that are marked as not present. huge_pte_clear() > internally just ends up calling pte_clear() which does not correctly >

staging: sm750fb: Replace functions CamelCase naming with underscores.

Replace CamelCase function names with underscores to comply with the standard kernel coding style Signed-off-by: Richa Jha --- drivers/staging/sm750fb/ddk750_chip.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git

Re: [PATCH] pci: iov: use device lock to protect IOV sysfs accesses

On Mon, May 22, 2017 at 03:50:23PM -0700, Jakub Kicinski wrote: > PCI core sets the driver pointer before calling ->probe() and only > clears it after ->remove(). This means driver's ->sriov_configure() > callback will happily race with probe() and remove(), most likely > leading to BUGs, since

Re: [PATCH v3.1 4/6] mm/hugetlb: Allow architectures to override huge_pte_clear()

On Mon, 22 May 2017 17:25:55 +0100 Punit Agrawal wrote: > When unmapping a hugepage range, huge_pte_clear() is used to clear the > page table entries that are marked as not present. huge_pte_clear() > internally just ends up calling pte_clear() which does not correctly > deal with hugepages

staging: sm750fb: Replace functions CamelCase naming with underscores.

Replace CamelCase function names with underscores to comply with the standard kernel coding style Signed-off-by: Richa Jha --- drivers/staging/sm750fb/ddk750_chip.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git

Re: [V2, 2/6] tty: serial: lpuart: add little endian 32 bit register support

Hi, Alternative solution could be - have separate write path for earlycon. >>> >>> It looks to me having the same issue with a separate write patch >>> for earlycon as we still need distinguish Little or Big endian >>> for Layerscape and IMX. >>> At a glance, it is dozen lines of code.

Re: [V2, 2/6] tty: serial: lpuart: add little endian 32 bit register support

Hi, Alternative solution could be - have separate write path for earlycon. >>> >>> It looks to me having the same issue with a separate write patch >>> for earlycon as we still need distinguish Little or Big endian >>> for Layerscape and IMX. >>> At a glance, it is dozen lines of code.

Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

(new top-level subthread here since this is a separate topic): On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile > new file mode 100644 > index ..07ef200e0675 > --- /dev/null > +++

Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

(new top-level subthread here since this is a separate topic): On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile > new file mode 100644 > index ..07ef200e0675 > --- /dev/null > +++ b/arch/riscv/Makefile > @@ -0,0 +1,64 @@

[PATCH net v2 1/2] net: ieee802154: remove explicit set skb->sk

Explicit set skb->sk is needless, sock_alloc_send_skb is already set it. Signed-off-by: Lin Zhang Acked-by: Stefan Schmidt --- changelog: v1 -> v2: * split v1 into two patches, per Stefan Schmidt. Thanks to Stefan Schmidt for reviewing !

[PATCH net v2 1/2] net: ieee802154: remove explicit set skb->sk

Explicit set skb->sk is needless, sock_alloc_send_skb is already set it. Signed-off-by: Lin Zhang Acked-by: Stefan Schmidt --- changelog: v1 -> v2: * split v1 into two patches, per Stefan Schmidt. Thanks to Stefan Schmidt for reviewing ! --- net/ieee802154/socket.c | 2 -- 1 file

Re: Use case for TASKS_RCU

On Mon, 22 May 2017 17:00:36 -0700 "Paul E. McKenney" wrote: > On Fri, May 19, 2017 at 12:06:09PM -0700, Paul E. McKenney wrote: > > On Fri, May 19, 2017 at 10:23:31AM -0400, Steven Rostedt wrote: > > > On Fri, 19 May 2017 10:04:21 -0400 > > > Steven Rostedt

Re: Use case for TASKS_RCU

On Mon, 22 May 2017 17:00:36 -0700 "Paul E. McKenney" wrote: > On Fri, May 19, 2017 at 12:06:09PM -0700, Paul E. McKenney wrote: > > On Fri, May 19, 2017 at 10:23:31AM -0400, Steven Rostedt wrote: > > > On Fri, 19 May 2017 10:04:21 -0400 > > > Steven Rostedt wrote: > > > > > > > On Fri, 19

Re: kernel-trace: Fine-tuning for seven function implementations

On Mon, 22 May 2017 09:45:27 +0200 SF Markus Elfring wrote: > > I wont be touching or even looking at these until after 4.12-rc1 is > > released. Feel free to reply to this email with a ping in a week or > > two. > > *ping* > > How do you think about to give

Re: kernel-trace: Fine-tuning for seven function implementations

On Mon, 22 May 2017 09:45:27 +0200 SF Markus Elfring wrote: > > I wont be touching or even looking at these until after 4.12-rc1 is > > released. Feel free to reply to this email with a ping in a week or > > two. > > *ping* > > How do you think about to give these update suggestions another

Re: [patches] Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

On Mon, May 22, 2017 at 9:49 PM, Palmer Dabbelt wrote: > On Mon, 22 May 2017 18:27:21 PDT (-0700), o...@lixom.net wrote: >> Hi, >> >> >> On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: >>> --- >>> arch/riscv/.gitignore| 35 >>>

Re: [patches] Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

On Mon, May 22, 2017 at 9:49 PM, Palmer Dabbelt wrote: > On Mon, 22 May 2017 18:27:21 PDT (-0700), o...@lixom.net wrote: >> Hi, >> >> >> On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: >>> --- >>> arch/riscv/.gitignore| 35 >>> arch/riscv/Kconfig |

Re: [PATCH 3/7] kernel-trace: Adjust two checks for null pointers in compatible_field()

On Fri, 5 May 2017 23:03:23 +0200 SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 5 May 2017 20:00:11 +0200 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > The script

Re: [PATCH 3/7] kernel-trace: Adjust two checks for null pointers in compatible_field()

On Fri, 5 May 2017 23:03:23 +0200 SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 5 May 2017 20:00:11 +0200 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > The script “checkpatch.pl” pointed information out like the following. >

[PATCH v2] ocfs2: fix a static checker warning

This patch will fix a static code checker warning, which looks like below, fs/ocfs2/inode.c:179 ocfs2_iget() warn: passing zero to 'ERR_PTR' this warning was caused by the commit d56a8f32e4c6 ("ocfs2: check/fix inode block for online file check"). after apply this patch, the error return value

[PATCH v2] ocfs2: fix a static checker warning

This patch will fix a static code checker warning, which looks like below, fs/ocfs2/inode.c:179 ocfs2_iget() warn: passing zero to 'ERR_PTR' this warning was caused by the commit d56a8f32e4c6 ("ocfs2: check/fix inode block for online file check"). after apply this patch, the error return value

[PATCH v4] fscrypt: Add support for AES-128-CBC

From: Daniel Walter fscrypt provides facilities to use different encryption algorithms which are selectable by userspace when setting the encryption policy. Currently, only AES-256-XTS for file contents and AES-256-CBC-CTS for file names are implemented. This is a clear

[PATCH v4] fscrypt: Add support for AES-128-CBC

From: Daniel Walter fscrypt provides facilities to use different encryption algorithms which are selectable by userspace when setting the encryption policy. Currently, only AES-256-XTS for file contents and AES-256-CBC-CTS for file names are implemented. This is a clear case of kernel offers the

Re: [PATCH v2 0/9] crypto: add HMAC IPAD/OPAD constant

On Fri, May 19, 2017 at 08:53:22AM +0200, Corentin Labbe wrote: > Hello > > Many HMAC users directly use directly 0x36/0x5c values. > It's better with crypto to use a name instead of directly some crypto > constant. > > Changes since v1: > - Moved constant to include/crypto/hmac.h > - Added to

Re: [PATCH v2 0/9] crypto: add HMAC IPAD/OPAD constant

On Fri, May 19, 2017 at 08:53:22AM +0200, Corentin Labbe wrote: > Hello > > Many HMAC users directly use directly 0x36/0x5c values. > It's better with crypto to use a name instead of directly some crypto > constant. > > Changes since v1: > - Moved constant to include/crypto/hmac.h > - Added to

Re: [PATCH v2 0/4] crypto: async crypto op fixes

On Thu, May 18, 2017 at 04:29:22PM +0300, Gilad Ben-Yossef wrote: > This patch set fixes various usage and documentation errors > in waiting for async crypto op to complete which can result > in data corruption. > > Note: these were discovered in the process of working on a > patch set that

Re: [PATCH v2 0/4] crypto: async crypto op fixes

On Thu, May 18, 2017 at 04:29:22PM +0300, Gilad Ben-Yossef wrote: > This patch set fixes various usage and documentation errors > in waiting for async crypto op to complete which can result > in data corruption. > > Note: these were discovered in the process of working on a > patch set that

Re: [PATCH] crypto: x86/aes - Don't use %rbp as temporary register

On Tue, May 16, 2017 at 09:03:08PM -0700, Eric Biggers wrote: > From: Eric Biggers > > When using the "aes-asm" implementation of AES (*not* the AES-NI > implementation) on an x86_64, v4.12-rc1 kernel with lockdep enabled, the > following warning was reported, along with a

Re: [PATCH] crypto: x86/aes - Don't use %rbp as temporary register

On Tue, May 16, 2017 at 09:03:08PM -0700, Eric Biggers wrote: > From: Eric Biggers > > When using the "aes-asm" implementation of AES (*not* the AES-NI > implementation) on an x86_64, v4.12-rc1 kernel with lockdep enabled, the > following warning was reported, along with a long unwinder dump: >

Re: [PATCH v7 0/3] PCI/IOMMU: Reserve IOVAs for PCI inbound memory

On Tue, May 23, 2017 at 12:48 AM, Alex Williamson wrote: > On Mon, 22 May 2017 22:09:39 +0530 > Oza Pawandeep wrote: > >> iproc based PCI RC and Stingray SOC has limitaiton of addressing only 512GB >> memory at once. >> >> IOVA allocation honors

Re: [PATCH v7 0/3] PCI/IOMMU: Reserve IOVAs for PCI inbound memory

On Tue, May 23, 2017 at 12:48 AM, Alex Williamson wrote: > On Mon, 22 May 2017 22:09:39 +0530 > Oza Pawandeep wrote: > >> iproc based PCI RC and Stingray SOC has limitaiton of addressing only 512GB >> memory at once. >> >> IOVA allocation honors device's coherent_dma_mask/dma_mask. >> In PCI

Re: [PATCH v1] crypto: img-hash - Handle return value of clk_prepare_enable

On Tue, May 16, 2017 at 01:57:41PM +0530, Arvind Yadav wrote: > Here, Clock enable can failed. So adding an error check for > clk_prepare_enable. > > Signed-off-by: Arvind Yadav Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH v1] crypto: img-hash - Handle return value of clk_prepare_enable

On Tue, May 16, 2017 at 01:57:41PM +0530, Arvind Yadav wrote: > Here, Clock enable can failed. So adding an error check for > clk_prepare_enable. > > Signed-off-by: Arvind Yadav Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

Re: [PATCH v1] hw_random : omap3-rom-rng:- Handle return value of clk_prepare_enable

On Mon, May 15, 2017 at 01:52:03PM +0530, Arvind Yadav wrote: > Here, Clock enable can failed. So adding an error check for > clk_prepare_enable. > > Signed-off-by: Arvind Yadav Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH v1] hw_random : omap3-rom-rng:- Handle return value of clk_prepare_enable

On Mon, May 15, 2017 at 01:52:03PM +0530, Arvind Yadav wrote: > Here, Clock enable can failed. So adding an error check for > clk_prepare_enable. > > Signed-off-by: Arvind Yadav Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

On Mon, 22 May 2017 18:31:08 PDT (-0700), rdun...@infradead.org wrote: > On 05/22/17 18:27, Olof Johansson wrote: >> Hi, >> >> >> On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: >>> --- >>> arch/riscv/.gitignore| 35 >>> arch/riscv/Kconfig

Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

On Mon, 22 May 2017 18:31:08 PDT (-0700), rdun...@infradead.org wrote: > On 05/22/17 18:27, Olof Johansson wrote: >> Hi, >> >> >> On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: >>> --- >>> arch/riscv/.gitignore| 35 >>> arch/riscv/Kconfig | 300

Re: [PATCH] kernel: mark all struct k_clock instances const

On Tue, May 23, 2017 at 12:17:31AM +0200, Thomas Gleixner wrote: > On Mon, 15 May 2017, Christoph Hellwig wrote: > > > And keep a pointer to it instead of a copy in the posix_clocks array. > > > > Based on similar changes in the Grsecurity patchset, but redone from > > scratch including a few

Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

On Mon, 22 May 2017 18:27:21 PDT (-0700), o...@lixom.net wrote: > Hi, > > > On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: >> --- >> arch/riscv/.gitignore| 35 >> arch/riscv/Kconfig | 300 >> +++

Re: RISC-V Linux Port v1

On Mon, 22 May 2017 19:16:43 PDT (-0700), rdun...@infradead.org wrote: > On 05/22/17 17:41, Palmer Dabbelt wrote: > >> [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64} >> [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs >> [PATCH 3/7] RISC-V: Device Tree Documentation >> [PATCH 4/7]

Re: [PATCH] kernel: mark all struct k_clock instances const

On Tue, May 23, 2017 at 12:17:31AM +0200, Thomas Gleixner wrote: > On Mon, 15 May 2017, Christoph Hellwig wrote: > > > And keep a pointer to it instead of a copy in the posix_clocks array. > > > > Based on similar changes in the Grsecurity patchset, but redone from > > scratch including a few

Re: [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs

On Mon, 22 May 2017 18:27:21 PDT (-0700), o...@lixom.net wrote: > Hi, > > > On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: >> --- >> arch/riscv/.gitignore| 35 >> arch/riscv/Kconfig | 300 >> +++ >>

Re: RISC-V Linux Port v1

On Mon, 22 May 2017 19:16:43 PDT (-0700), rdun...@infradead.org wrote: > On 05/22/17 17:41, Palmer Dabbelt wrote: > >> [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64} >> [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs >> [PATCH 3/7] RISC-V: Device Tree Documentation >> [PATCH 4/7]

linux-next: Tree for May 23

Hi all, Changes since 20170522: The net-next tree lost its build failure. The drm-misc tree gained a conflict against the drm-intel tree. Non-merge commits (relative to Linus' tree): 2206 2551 files changed, 83651 insertions(+), 50797 deletions

linux-next: Tree for May 23

Hi all, Changes since 20170522: The net-next tree lost its build failure. The drm-misc tree gained a conflict against the drm-intel tree. Non-merge commits (relative to Linus' tree): 2206 2551 files changed, 83651 insertions(+), 50797 deletions

[PATCH net] ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets

This fix addresses two problems in the way the DSCP field is formulated on the encapsulating header of IPv6 tunnels. 1) The IPv6 tunneling code was manipulating the DSCP field of the encapsulating packet using the 32b flowlabel. Since the flowlabel is only the lower 20b it was incorrect to

[PATCH net] ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets

This fix addresses two problems in the way the DSCP field is formulated on the encapsulating header of IPv6 tunnels. 1) The IPv6 tunneling code was manipulating the DSCP field of the encapsulating packet using the 32b flowlabel. Since the flowlabel is only the lower 20b it was incorrect to

Re: [PATCH 0/5] atm: Adjustments for some function implementations

On Sun, May 21, 2017 at 1:12 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 21 May 2017 22:09:11 +0200 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (5):

Re: [PATCH 0/5] atm: Adjustments for some function implementations

On Sun, May 21, 2017 at 1:12 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 21 May 2017 22:09:11 +0200 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (5): > Improve a size determination in four functions > Delete

Re: [PATCHv2 3/3] fpga_mgr: Add streaming support through the new driver_data API

hi Alan On 5/22/2017 4:09 PM, Alan Tull wrote: On Sat, May 20, 2017 at 1:49 AM, wrote: Hi Yi, From: Yi Li Since the FPGA image are getting bigger in size, this add an new API fpga_mgr_firmware_stream You could replace the guts of the

Re: [PATCHv2 3/3] fpga_mgr: Add streaming support through the new driver_data API

hi Alan On 5/22/2017 4:09 PM, Alan Tull wrote: On Sat, May 20, 2017 at 1:49 AM, wrote: Hi Yi, From: Yi Li Since the FPGA image are getting bigger in size, this add an new API fpga_mgr_firmware_stream You could replace the guts of the current fpga_mgr_firmware_load() with this new API

Re: [PATCH 4/4] arch/powerpc/44x/fsp2: wdt tcr update instead of whole rewrite

Ivan Mikhaylov writes: > > From my point of view it's possible. I've checked docu and on idea > it should be possible cause WP is only affecting watchdog ping time. The question is, is there any chance that leaving those bits set on another platform will cause a problem? ie. on

Re: [PATCH 4/4] arch/powerpc/44x/fsp2: wdt tcr update instead of whole rewrite

Ivan Mikhaylov writes: > > From my point of view it's possible. I've checked docu and on idea > it should be possible cause WP is only affecting watchdog ping time. The question is, is there any chance that leaving those bits set on another platform will cause a problem? ie. on existing

[PATCH 2/2] spi: use gpio_desc instead of numeric gpio

By using a gpio_desc and gpiod_set_value() instead of a numeric gpio and gpio_set_value() the gpio flags are taken into account. This is useful when using a gpio chip-select to supplement a controllers native chip-select. Signed-off-by: Chris Packham ---

[PATCH 2/2] spi: use gpio_desc instead of numeric gpio

By using a gpio_desc and gpiod_set_value() instead of a numeric gpio and gpio_set_value() the gpio flags are taken into account. This is useful when using a gpio chip-select to supplement a controllers native chip-select. Signed-off-by: Chris Packham --- Notes: My specific use-case is I

[PATCH 1/2] spi: orion: Handle GPIO chip-selects

Some hardware designs use GPIOs to add (or supplement) the SPI chip-select so that more than one SPI slave device can be used. For this to work with the spi-orion driver the SPI_MASTER_GPIO_SS flag needs to be set (because the other outputs are gated internally by the CS) and the correct

[PATCH 1/2] spi: orion: Handle GPIO chip-selects

Some hardware designs use GPIOs to add (or supplement) the SPI chip-select so that more than one SPI slave device can be used. For this to work with the spi-orion driver the SPI_MASTER_GPIO_SS flag needs to be set (because the other outputs are gated internally by the CS) and the correct

[PATCH V2 2/4] PM / OPP: Don't create copy of regulators unnecessarily

This code was required while the OPP core was managed with help of RCUs, but not anymore. Get rid of unnecessary alloc/memcpy operations. Signed-off-by: Viresh Kumar Reviewed-by: Stephen Boyd --- drivers/base/power/opp/core.c | 14 +++---

[PATCH V2 2/4] PM / OPP: Don't create copy of regulators unnecessarily

This code was required while the OPP core was managed with help of RCUs, but not anymore. Get rid of unnecessary alloc/memcpy operations. Signed-off-by: Viresh Kumar Reviewed-by: Stephen Boyd --- drivers/base/power/opp/core.c | 14 +++--- 1 file changed, 3 insertions(+), 11

[PATCH V2 1/4] PM / OPP: Reorganize _generic_set_opp_regulator()

The code was overly complicated here because of the limitations that we had with RCUs (Couldn't use opp-table and OPPs outside RCU protected section and can't call sleep-able routines from within that). But that is long gone now. Reorganize _generic_set_opp_regulator() in order to avoid using

[PATCH V2 3/4] PM / OPP: opp-microvolt is not optional if regulators are set

If dev_pm_opp_set_regulators() is called for a device and its regulators are set in the OPP core, the OPP nodes for the device must contain the "opp-microvolt" property, otherwise there is something wrong and we better error out. Signed-off-by: Viresh Kumar ---

[PATCH V2 4/4] PM / OPP: Don't create debugfs "supply-0" directory unnecessarily

We create "supply-0" debugfs directory even if the device doesn't do voltage scaling. That looks confusing, as if the regulator is found but we never managed to get voltage levels for it. Avoid creating such a directory unnecessarily. Signed-off-by: Viresh Kumar ---

[PATCH V2 3/4] PM / OPP: opp-microvolt is not optional if regulators are set

If dev_pm_opp_set_regulators() is called for a device and its regulators are set in the OPP core, the OPP nodes for the device must contain the "opp-microvolt" property, otherwise there is something wrong and we better error out. Signed-off-by: Viresh Kumar --- drivers/base/power/opp/of.c | 10

[PATCH V2 4/4] PM / OPP: Don't create debugfs "supply-0" directory unnecessarily

We create "supply-0" debugfs directory even if the device doesn't do voltage scaling. That looks confusing, as if the regulator is found but we never managed to get voltage levels for it. Avoid creating such a directory unnecessarily. Signed-off-by: Viresh Kumar ---

[PATCH V2 1/4] PM / OPP: Reorganize _generic_set_opp_regulator()

The code was overly complicated here because of the limitations that we had with RCUs (Couldn't use opp-table and OPPs outside RCU protected section and can't call sleep-able routines from within that). But that is long gone now. Reorganize _generic_set_opp_regulator() in order to avoid using

[PATCH V2 0/4] PM / OPP: Minor cleanups

Hi, Here are few cleanup patches for the OPP core. The first two simplify the code that was written specifically due to the limitations that we had because of RCUs. We don't RCUs anymore and this can be simplified. The last two take care of specific corner cases. Rebased over pm/linux-next and

[PATCH V2 0/4] PM / OPP: Minor cleanups

Hi, Here are few cleanup patches for the OPP core. The first two simplify the code that was written specifically due to the limitations that we had because of RCUs. We don't RCUs anymore and this can be simplified. The last two take care of specific corner cases. Rebased over pm/linux-next and

Re: [PATCH 0/2] Fixes for Switchtec Driver

On 22/05/17 03:54 PM, Bjorn Helgaas wrote: > Since we merged the Switchtec driver during the v4.12 merge window, I > applied these to for-linus for v4.12, with the following changelogs to > correct a few typos: Great! Thanks Bjorn. Logan

Re: [PATCH 0/2] Fixes for Switchtec Driver

On 22/05/17 03:54 PM, Bjorn Helgaas wrote: > Since we merged the Switchtec driver during the v4.12 merge window, I > applied these to for-linus for v4.12, with the following changelogs to > correct a few typos: Great! Thanks Bjorn. Logan

Crypto Fixes for 4.12

Hi Linus: This push fixes a regression in the skcipher interface that allows bogus key parameters to hit underlying implementations which can cause crashes. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Herbert Xu (1): crypto: skcipher -

Crypto Fixes for 4.12

Hi Linus: This push fixes a regression in the skcipher interface that allows bogus key parameters to hit underlying implementations which can cause crashes. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Herbert Xu (1): crypto: skcipher -

Re: RISC-V Linux Port v1

On Mon, 22 May 2017 18:25:41 PDT (-0700), rdun...@infradead.org wrote: > On 05/22/17 18:16, Olof Johansson wrote: >> Hi Palmer, >> >> On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: >> >>> In addition to the threaded messages, our port can be found on Git Hib >>> >>>

Re: RISC-V Linux Port v1

On Mon, 22 May 2017 18:16:20 PDT (-0700), o...@lixom.net wrote: > Hi Palmer, > > On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: >> We'd like to submit for inclusion in Linux a port for the RISC-V >> architecture. >> While it is doubtlessly not complete, we think it is

Re: [PATCH 7/7] RISC-V: arch/riscv/mm

On Mon, 22 May 2017 19:17:52 PDT (-0700), o...@lixom.net wrote: > On Mon, May 22, 2017 at 6:28 PM, Randy Dunlap wrote: >> >>> diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c >>> new file mode 100644 >>> index ..f02e286dd1c1 >>> --- /dev/null >>> +++

Re: RISC-V Linux Port v1

On Mon, 22 May 2017 18:25:41 PDT (-0700), rdun...@infradead.org wrote: > On 05/22/17 18:16, Olof Johansson wrote: >> Hi Palmer, >> >> On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: >> >>> In addition to the threaded messages, our port can be found on Git Hib >>> >>>

Re: RISC-V Linux Port v1

On Mon, 22 May 2017 18:16:20 PDT (-0700), o...@lixom.net wrote: > Hi Palmer, > > On Mon, May 22, 2017 at 5:41 PM, Palmer Dabbelt wrote: >> We'd like to submit for inclusion in Linux a port for the RISC-V >> architecture. >> While it is doubtlessly not complete, we think it is far enough along to

Re: [PATCH 7/7] RISC-V: arch/riscv/mm

On Mon, 22 May 2017 19:17:52 PDT (-0700), o...@lixom.net wrote: > On Mon, May 22, 2017 at 6:28 PM, Randy Dunlap wrote: >> >>> diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c >>> new file mode 100644 >>> index ..f02e286dd1c1 >>> --- /dev/null >>> +++ b/arch/riscv/mm/fault.c

Re: [PATCH v3 0/3] Fix mdp device tree

On Mon, 2017-05-22 at 16:16 +0200, Hans Verkuil wrote: > On 05/22/2017 04:14 PM, Matthias Brugger wrote: > > > > > > On 22/05/17 11:09, Hans Verkuil wrote: > >> On 05/12/2017 05:22 AM, Minghsiu Tsai wrote: > >> > >> Who should take care of the dtsi changes? I'm not sure who maintains the > >>

Re: [PATCH v3 0/3] Fix mdp device tree

On Mon, 2017-05-22 at 16:16 +0200, Hans Verkuil wrote: > On 05/22/2017 04:14 PM, Matthias Brugger wrote: > > > > > > On 22/05/17 11:09, Hans Verkuil wrote: > >> On 05/12/2017 05:22 AM, Minghsiu Tsai wrote: > >> > >> Who should take care of the dtsi changes? I'm not sure who maintains the > >>

  1   2   3   4   5   6   7   8   9   10   >