Re: [GIT PULL] Kernel lockdown for secure boot

Andy Lutomirski wrote: > > A kernel that allows users arbitrary access to ring 0 is just an > > overfeatured bootloader. Why would you want secure boot in that case? > > To get a chain of trust. You don't have a chain of trust that you can trust in that case. David

RE: general protection fault in tipc_nametbl_unsubscribe

#syz dup: general protection fault in __list_del_entry_valid (3) > -Original Message- > From: syzbot > [mailto:syzbot+4859fe19555ea87c4...@syzkaller.appspotmail.com] > Sent: Monday, April 02, 2018 02:01 > To: da...@davemloft.net; Jon Maloy ; linux- >

Re: [GIT PULL] Kernel lockdown for secure boot

Andy Lutomirski wrote: > > A kernel that allows users arbitrary access to ring 0 is just an > > overfeatured bootloader. Why would you want secure boot in that case? > > To get a chain of trust. You don't have a chain of trust that you can trust in that case. David

RE: general protection fault in tipc_nametbl_unsubscribe

#syz dup: general protection fault in __list_del_entry_valid (3) > -Original Message- > From: syzbot > [mailto:syzbot+4859fe19555ea87c4...@syzkaller.appspotmail.com] > Sent: Monday, April 02, 2018 02:01 > To: da...@davemloft.net; Jon Maloy ; linux- > ker...@vger.kernel.org;

Re: [PATCH v6 3/9] pinctrl: actions: Add Actions S900 pinctrl driver

On Tue, Apr 03, 2018 at 07:03:46PM +0200, Andreas Färber wrote: > Hi Mani, > > Am 03.04.2018 um 19:00 schrieb Manivannan Sadhasivam: > > On Sat, Mar 31, 2018 at 12:16:49AM +0300, Andy Shevchenko wrote: > >> On Wed, Mar 28, 2018 at 8:46 PM, Manivannan Sadhasivam > >>

Re: [PATCH v6 3/9] pinctrl: actions: Add Actions S900 pinctrl driver

On Tue, Apr 03, 2018 at 07:03:46PM +0200, Andreas Färber wrote: > Hi Mani, > > Am 03.04.2018 um 19:00 schrieb Manivannan Sadhasivam: > > On Sat, Mar 31, 2018 at 12:16:49AM +0300, Andy Shevchenko wrote: > >> On Wed, Mar 28, 2018 at 8:46 PM, Manivannan Sadhasivam > >> wrote: > >>> +static const

Re: [PATCH 0/5] memory-barriers.txt: Applies upstream changes to the Korean version

On Tue, Apr 03, 2018 at 06:20:22PM +0900, SeongJae Park wrote: > This patchset applies upstream changes for memory-barriers.txt to the Korean > version of it. > > SeongJae Park (5): > kokr/doc: READ_ONCE() now implies smp_barrier_depends() > kokr/doc: De-emphasize smp_read_barrier_depends >

Re: [PATCH 0/5] memory-barriers.txt: Applies upstream changes to the Korean version

On Tue, Apr 03, 2018 at 06:20:22PM +0900, SeongJae Park wrote: > This patchset applies upstream changes for memory-barriers.txt to the Korean > version of it. > > SeongJae Park (5): > kokr/doc: READ_ONCE() now implies smp_barrier_depends() > kokr/doc: De-emphasize smp_read_barrier_depends >

[RFC PATCH 1/4] acpi: apei: Return severity of GHES messages after handling

The policy currently is to simply panic() on GHES fatal errors. Oftentimes we may correct fatal errors i.e. "Fatal" PCIe errors can be corrected via AER When these errors are corrected, it doesn't make sense to panic(). Update ghes_do_proc() to return the severity of the worst error, while

[RFC PATCH 1/4] acpi: apei: Return severity of GHES messages after handling

The policy currently is to simply panic() on GHES fatal errors. Oftentimes we may correct fatal errors i.e. "Fatal" PCIe errors can be corrected via AER When these errors are corrected, it doesn't make sense to panic(). Update ghes_do_proc() to return the severity of the worst error, while

[RFC PATCH 4/4] acpi: apei: Warn when GHES marks correctable errors as "fatal"

There seems to be a culture amongst BIOS teams to want to crash the OS when an error can't be handled in firmware. Marking GHES errors as "fatal" is a very common way to do this. However, a number of errors reported by GHES may be fatal in the sense a device or link is lost, but are not fatal to

[RFC PATCH 4/4] acpi: apei: Warn when GHES marks correctable errors as "fatal"

There seems to be a culture amongst BIOS teams to want to crash the OS when an error can't be handled in firmware. Marking GHES errors as "fatal" is a very common way to do this. However, a number of errors reported by GHES may be fatal in the sense a device or link is lost, but are not fatal to

[RFC PATCH 2/4] acpi: apei: Swap ghes_print_queued_estatus and ghes_proc_in_irq

Move ghes_print_queued_estatus() above ghes_proc_in_irq(). In a subsequent patch, the NMI handler will be updated, and the print functionality will be used in ghes_proc_in_irq. This simply makes the subsequent diff look sane. Signed-off-by: Alexandru Gagniuc ---

[RFC PATCH 2/4] acpi: apei: Swap ghes_print_queued_estatus and ghes_proc_in_irq

Move ghes_print_queued_estatus() above ghes_proc_in_irq(). In a subsequent patch, the NMI handler will be updated, and the print functionality will be used in ghes_proc_in_irq. This simply makes the subsequent diff look sane. Signed-off-by: Alexandru Gagniuc --- drivers/acpi/apei/ghes.c | 40

[RFC PATCH 3/4] acpi: apei: Do not panic() in NMI because of GHES messages

BIOSes like to send NMIs for a number of silly reasons often deemed to be "fatal". For example pin bounce during a PCIE hotplug/unplug might cause the link to go down and retrain, with fatal PCI errors being generated while the link is retraining. Instead of panic()ing in NMI context, pass fatal

[RFC PATCH 3/4] acpi: apei: Do not panic() in NMI because of GHES messages

BIOSes like to send NMIs for a number of silly reasons often deemed to be "fatal". For example pin bounce during a PCIE hotplug/unplug might cause the link to go down and retrain, with fatal PCI errors being generated while the link is retraining. Instead of panic()ing in NMI context, pass fatal

[RFC PATCH 0/4] acpi: apei: Improve error handling with firmware-first

Hi, I'm helping out Dell work out through the issues related to PCIe and NVMe hotplug. Although hot-plug generally works, there are corner cases such as pin bounce, drives failing and surprise removal that are not 100% worked out. Because of this, NVMe is not yet on feature parity with SCSI and

[RFC PATCH 0/4] acpi: apei: Improve error handling with firmware-first

Hi, I'm helping out Dell work out through the issues related to PCIe and NVMe hotplug. Although hot-plug generally works, there are corner cases such as pin bounce, drives failing and surprise removal that are not 100% worked out. Because of this, NVMe is not yet on feature parity with SCSI and

Re: NO_HZ_FULL and tick running within a reasonable amount of time

On Tue, Apr 03, 2018 at 01:41:31PM +0200, Frederic Weisbecker wrote: > On Mon, Apr 02, 2018 at 03:04:38PM -0700, Paul E. McKenney wrote: > > Hello! > > > > I am hitting the following on today's mainline under rcutorture, but > > only on scenarios built with CONFIG_NO_HZ_FULL=y: > > > >

[PATCH] i8042: Enable MUX on Sony VAIO VGN-CS series to fix touchpad

The touch sensor buttons on Sony VAIO VGN-CS series laptops (e.g. VGN-CS31S) are a separate PS/2 device. As the MUX is disabled for all VAIO machines by the nomux blacklist, the data from touch sensor buttons and touchpad are combined. The protocol used by the buttons is probably similar to the

Re: NO_HZ_FULL and tick running within a reasonable amount of time

On Tue, Apr 03, 2018 at 01:41:31PM +0200, Frederic Weisbecker wrote: > On Mon, Apr 02, 2018 at 03:04:38PM -0700, Paul E. McKenney wrote: > > Hello! > > > > I am hitting the following on today's mainline under rcutorture, but > > only on scenarios built with CONFIG_NO_HZ_FULL=y: > > > >

[PATCH] i8042: Enable MUX on Sony VAIO VGN-CS series to fix touchpad

The touch sensor buttons on Sony VAIO VGN-CS series laptops (e.g. VGN-CS31S) are a separate PS/2 device. As the MUX is disabled for all VAIO machines by the nomux blacklist, the data from touch sensor buttons and touchpad are combined. The protocol used by the buttons is probably similar to the

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 03, 2018 at 11:09:09AM +0200, Daniel Vetter wrote: > On Thu, Mar 29, 2018 at 01:34:24PM +0200, Christian König wrote: > > Am 29.03.2018 um 08:57 schrieb Daniel Vetter: > > > On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote: > > > > Add a peer2peer flag noting that the

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 03, 2018 at 11:09:09AM +0200, Daniel Vetter wrote: > On Thu, Mar 29, 2018 at 01:34:24PM +0200, Christian König wrote: > > Am 29.03.2018 um 08:57 schrieb Daniel Vetter: > > > On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote: > > > > Add a peer2peer flag noting that the

Re: [RFC PATCH v1] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On Tue, Apr 3, 2018 at 9:56 AM, Luis R. Rodriguez wrote: > The biggest thing which has changed since then is that we decided to *not* > support or streamline generic firmware signing (non-IMA) for now for a few > reasons [0] [1] which are important to re-iterate as these are

Re: [RFC PATCH v1] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On Tue, Apr 3, 2018 at 9:56 AM, Luis R. Rodriguez wrote: > The biggest thing which has changed since then is that we decided to *not* > support or streamline generic firmware signing (non-IMA) for now for a few > reasons [0] [1] which are important to re-iterate as these are easy to forget, > and

Re: [PATCH v6 3/9] pinctrl: actions: Add Actions S900 pinctrl driver

Hi Mani, Am 03.04.2018 um 19:00 schrieb Manivannan Sadhasivam: > On Sat, Mar 31, 2018 at 12:16:49AM +0300, Andy Shevchenko wrote: >> On Wed, Mar 28, 2018 at 8:46 PM, Manivannan Sadhasivam >> wrote: >>> +static const struct pinconf_ops owl_pinconf_ops = { >>> +

Re: [PATCH v6 3/9] pinctrl: actions: Add Actions S900 pinctrl driver

Hi Mani, Am 03.04.2018 um 19:00 schrieb Manivannan Sadhasivam: > On Sat, Mar 31, 2018 at 12:16:49AM +0300, Andy Shevchenko wrote: >> On Wed, Mar 28, 2018 at 8:46 PM, Manivannan Sadhasivam >> wrote: >>> +static const struct pinconf_ops owl_pinconf_ops = { >>> + .is_generic = true, >>> +

Re: 4.15.14 crash with iscsi target and dvd

On Sun, 2018-04-01 at 14:27 -0400, Wakko Warner wrote: > Wakko Warner wrote: > > Wakko Warner wrote: > > > I tested 4.14.32 last night with the same oops. 4.9.91 works fine. > > > From the initiator, if I do cat /dev/sr1 > /dev/null it works. If I mount > > > /dev/sr1 and then do find -type f |

Re: [PATCH v17 01/10] LIB: Introduce a generic PIO mapping method

On 03/04/2018 17:37, Thierry Reding wrote: On Tue, Apr 03, 2018 at 05:01:37PM +0100, John Garry wrote: +int logic_pio_register_range(struct logic_pio_hwaddr *new_range) +{ + struct logic_pio_hwaddr *range; + resource_size_t start = new_range->hw_start; + resource_size_t end =

Re: 4.15.14 crash with iscsi target and dvd

On Sun, 2018-04-01 at 14:27 -0400, Wakko Warner wrote: > Wakko Warner wrote: > > Wakko Warner wrote: > > > I tested 4.14.32 last night with the same oops. 4.9.91 works fine. > > > From the initiator, if I do cat /dev/sr1 > /dev/null it works. If I mount > > > /dev/sr1 and then do find -type f |

Re: [PATCH v17 01/10] LIB: Introduce a generic PIO mapping method

On 03/04/2018 17:37, Thierry Reding wrote: On Tue, Apr 03, 2018 at 05:01:37PM +0100, John Garry wrote: +int logic_pio_register_range(struct logic_pio_hwaddr *new_range) +{ + struct logic_pio_hwaddr *range; + resource_size_t start = new_range->hw_start; + resource_size_t end =

Re: [PATCH net] net: dsa: mt7530: Use NULL instead of plain integer

On 04/02/2018 07:18 PM, Sean Wang wrote: > On Mon, 2018-04-02 at 16:24 -0700, Florian Fainelli wrote: >> We would be passing 0 instead of NULL as the rsp argument to >> mt7530_fdb_cmd(), fix that. >> > > Acked-by: Sean Wang > > BTW, does the part of the commit message

Re: [PATCH net] net: dsa: mt7530: Use NULL instead of plain integer

On 04/02/2018 07:18 PM, Sean Wang wrote: > On Mon, 2018-04-02 at 16:24 -0700, Florian Fainelli wrote: >> We would be passing 0 instead of NULL as the rsp argument to >> mt7530_fdb_cmd(), fix that. >> > > Acked-by: Sean Wang > > BTW, does the part of the commit message should be updated with

KASAN: use-after-free Read in xfs_inobt_init_key_from_rec

Hello, syzbot hit the following crash on upstream commit 642e7fd23353e22290e3d51719fcb658dc252342 (Tue Apr 3 04:22:12 2018 +) Merge branch 'syscalls-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux syzbot dashboard link:

KASAN: use-after-free Read in xfs_inobt_init_key_from_rec

Hello, syzbot hit the following crash on upstream commit 642e7fd23353e22290e3d51719fcb658dc252342 (Tue Apr 3 04:22:12 2018 +) Merge branch 'syscalls-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux syzbot dashboard link:

KASAN: global-out-of-bounds Write in string

Hello, syzbot hit the following crash on upstream commit 642e7fd23353e22290e3d51719fcb658dc252342 (Tue Apr 3 04:22:12 2018 +) Merge branch 'syscalls-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux syzbot dashboard link:

Re: [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

On Tue, 2018-04-03 at 18:07 +0200, Daniel Kiper wrote: > On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote: > > > > On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote: > > > > > > Initialize UEFI secure boot state during dom0 boot. Otherwise the > > > kernel may not even know

KASAN: global-out-of-bounds Write in string

Hello, syzbot hit the following crash on upstream commit 642e7fd23353e22290e3d51719fcb658dc252342 (Tue Apr 3 04:22:12 2018 +) Merge branch 'syscalls-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux syzbot dashboard link:

Re: [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

On Tue, 2018-04-03 at 18:07 +0200, Daniel Kiper wrote: > On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote: > > > > On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote: > > > > > > Initialize UEFI secure boot state during dom0 boot. Otherwise the > > > kernel may not even know

Re: [PATCH v6 3/9] pinctrl: actions: Add Actions S900 pinctrl driver

Hi Andy, On Sat, Mar 31, 2018 at 12:16:49AM +0300, Andy Shevchenko wrote: > On Wed, Mar 28, 2018 at 8:46 PM, Manivannan Sadhasivam > wrote: > > Add pinctrl driver for Actions Semi S900 SoC. The driver supports > > pinctrl, pinmux and pinconf functionalities

Re: [PATCH v6 3/9] pinctrl: actions: Add Actions S900 pinctrl driver

Hi Andy, On Sat, Mar 31, 2018 at 12:16:49AM +0300, Andy Shevchenko wrote: > On Wed, Mar 28, 2018 at 8:46 PM, Manivannan Sadhasivam > wrote: > > Add pinctrl driver for Actions Semi S900 SoC. The driver supports > > pinctrl, pinmux and pinconf functionalities through a range of registers > >

[PATCH v2] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

This commit adds device tree description of Kieback & Peter GmbH iMX6Q TPC board. Signed-off-by: Lukasz Majewski --- Changes for v2: - SDPX license identifiers used - Separate regulators - Proper beeper driver - Use of the lcd panel (with compatible) instead of timings provided

[PATCH v2] ARM: dts: tpc: Device tree description of the iMX6Q TPC board

This commit adds device tree description of Kieback & Peter GmbH iMX6Q TPC board. Signed-off-by: Lukasz Majewski --- Changes for v2: - SDPX license identifiers used - Separate regulators - Proper beeper driver - Use of the lcd panel (with compatible) instead of timings provided in device tree

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, 3 Apr 2018 18:11:19 +0200 Michal Hocko wrote: > yes a fallback is questionable. Whether to make the batch size > configuration is a matter of how much internal details you want to > expose to userspace. Well, it is tracing the guts of the kernel, so internal details

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, 3 Apr 2018 18:11:19 +0200 Michal Hocko wrote: > yes a fallback is questionable. Whether to make the batch size > configuration is a matter of how much internal details you want to > expose to userspace. Well, it is tracing the guts of the kernel, so internal details are generally

Re: Looking for way to program external MMU from userspace (or viable alternative)

On Tue, Apr 03, 2018 at 01:27:36AM +, Simon Que wrote: > Hi kernel community, > > We have an external PCIe board with a custom coprocessor on it. We also > have code for a kernel driver for it. We have thought about upstreaming it, > but we realized that we can instead convert the driver to a

Re: Looking for way to program external MMU from userspace (or viable alternative)

On Tue, Apr 03, 2018 at 01:27:36AM +, Simon Que wrote: > Hi kernel community, > > We have an external PCIe board with a custom coprocessor on it. We also > have code for a kernel driver for it. We have thought about upstreaming it, > but we realized that we can instead convert the driver to a

[PATCH 3/3] Documentation/features: Refresh and auto-generate the arch support status files in place

Signed-off-by: Andrea Parri --- .../features/core/cBPF-JIT/arch-support.txt| 27 ++ .../features/core/eBPF-JIT/arch-support.txt| 27 ++ .../core/generic-idle-thread/arch-support.txt | 3 ++-

[PATCH 3/3] Documentation/features: Refresh and auto-generate the arch support status files in place

Signed-off-by: Andrea Parri --- .../features/core/cBPF-JIT/arch-support.txt| 27 ++ .../features/core/eBPF-JIT/arch-support.txt| 27 ++ .../core/generic-idle-thread/arch-support.txt | 3 ++-

[PATCH 2/3] Documentation/features/core: Add arch support status files for 'cBPF-JIT' and 'eBPF-JIT'

Signed-off-by: Andrea Parri --- .../features/core/BPF-JIT/arch-support.txt | 31 -- .../features/core/cBPF-JIT/arch-support.txt| 5 .../features/core/eBPF-JIT/arch-support.txt| 5 3 files changed, 10

[PATCH 2/3] Documentation/features/core: Add arch support status files for 'cBPF-JIT' and 'eBPF-JIT'

Signed-off-by: Andrea Parri --- .../features/core/BPF-JIT/arch-support.txt | 31 -- .../features/core/cBPF-JIT/arch-support.txt| 5 .../features/core/eBPF-JIT/arch-support.txt| 5 3 files changed, 10 insertions(+), 31 deletions(-) delete

[RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

In Ingo's words [1]: "[...] what should be done instead is to write a script that refreshes all the arch-support.txt files in-place. [...] It's OK for the script to have various quirks for weirdly implemented features and exceptions: i.e. basically whenever it gets a feature wrong,

[RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

In Ingo's words [1]: "[...] what should be done instead is to write a script that refreshes all the arch-support.txt files in-place. [...] It's OK for the script to have various quirks for weirdly implemented features and exceptions: i.e. basically whenever it gets a feature wrong,

[PATCH 1/3] Documentation/features: Add script that refreshes the arch support status files in place

Suggested-by: Ingo Molnar Signed-off-by: Andrea Parri --- Documentation/features/scripts/features-refresh.sh | 55 ++ 1 file changed, 55 insertions(+) create mode 100755 Documentation/features/scripts/features-refresh.sh

[PATCH 1/3] Documentation/features: Add script that refreshes the arch support status files in place

Suggested-by: Ingo Molnar Signed-off-by: Andrea Parri --- Documentation/features/scripts/features-refresh.sh | 55 ++ 1 file changed, 55 insertions(+) create mode 100755 Documentation/features/scripts/features-refresh.sh diff --git

Re: [RFC PATCH v1] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On Mon, Apr 02, 2018 at 05:42:22PM -0700, Andy Lutomirski wrote: > On 11/10/2017 01:02 PM, Mimi Zohar wrote: > > If the kernel is locked down and IMA-appraisal is not enabled, prevent > > loading of unsigned firmware. > > > diff --git a/security/fw_lockdown/Kconfig b/security/fw_lockdown/Kconfig

Re: [RFC PATCH v1] fw_lockdown: new micro LSM module to prevent loading unsigned firmware

On Mon, Apr 02, 2018 at 05:42:22PM -0700, Andy Lutomirski wrote: > On 11/10/2017 01:02 PM, Mimi Zohar wrote: > > If the kernel is locked down and IMA-appraisal is not enabled, prevent > > loading of unsigned firmware. > > > diff --git a/security/fw_lockdown/Kconfig b/security/fw_lockdown/Kconfig

RE: [PATCH v5 03/14] PCI: Add pcie_bandwidth_capable() to compute max supported link bandwidth

> -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Tuesday, April 03, 2018 7:06 AM > To: Jacob Keller > Cc: Tal Gilboa ; Tariq Toukan ; > Keller, Jacob E ; Ariel Elior >

RE: [PATCH v5 03/14] PCI: Add pcie_bandwidth_capable() to compute max supported link bandwidth

> -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Tuesday, April 03, 2018 7:06 AM > To: Jacob Keller > Cc: Tal Gilboa ; Tariq Toukan ; > Keller, Jacob E ; Ariel Elior > ; > Ganesh Goudar ; Kirsher, Jeffrey T > ; everest-linux...@cavium.com; intel-wired- >

Re: [LINUX PATCH v8 2/2] memory: pl353: Add driver for arm pl353 static memory controller

Hello- On Wed, Mar 14, 2018 at 04:14:34PM +0530, nagasureshkumarre...@gmail.com wrote: > From: Naga Sureshkumar Relli I'm pleased to see this patchset revived and resubmitted! It would be easier to follow if you constructed your two patchsets with git format-patch

Re: [LINUX PATCH v8 2/2] memory: pl353: Add driver for arm pl353 static memory controller

Hello- On Wed, Mar 14, 2018 at 04:14:34PM +0530, nagasureshkumarre...@gmail.com wrote: > From: Naga Sureshkumar Relli I'm pleased to see this patchset revived and resubmitted! It would be easier to follow if you constructed your two patchsets with git format-patch --thread. Or, merge them

Re: [PATCH v3 2/4] mfd: add Gateworks System Controller core driver

On Tue, Apr 03, 2018 at 08:48:27AM -0700, Tim Harvey wrote: > On Wed, Mar 28, 2018 at 8:14 AM, Tim Harvey wrote: > > The Gateworks System Controller (GSC) is an I2C slave controller > > implemented with an MSP430 micro-controller whose firmware embeds the > > following

Re: [PATCH v3 2/4] mfd: add Gateworks System Controller core driver

On Tue, Apr 03, 2018 at 08:48:27AM -0700, Tim Harvey wrote: > On Wed, Mar 28, 2018 at 8:14 AM, Tim Harvey wrote: > > The Gateworks System Controller (GSC) is an I2C slave controller > > implemented with an MSP430 micro-controller whose firmware embeds the > > following features: > > - I/O

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote: >> Can you explain that much more clearly? I'm asking why booting via >> UEFI Secure Boot should enable lockdown, and I don't see what this has >> to

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote: >> Can you explain that much more clearly? I'm asking why booting via >> UEFI Secure Boot should enable lockdown, and I don't see what this has >> to do with kexec. And "someone

Re: [PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()

On Tue, Apr 03, 2018 at 12:33:05PM -0400, David Miller wrote: > Yes Al, however the pattern choosen here is probably cheaper on little endian: > > __beXX val = x; > switch (val) { > case htons(ETH_P_FOO): >... > } > > This way only the compiler byte swaps the

Re: [PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()

On Tue, Apr 03, 2018 at 12:33:05PM -0400, David Miller wrote: > Yes Al, however the pattern choosen here is probably cheaper on little endian: > > __beXX val = x; > switch (val) { > case htons(ETH_P_FOO): >... > } > > This way only the compiler byte swaps the

[GIT PULL 2/2] Kconfig updates for 4.17

Hi Linus, Please pull Kconfig updates for 4.17. The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae: Linux 4.16-rc5 (2018-03-11 17:25:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git

[GIT PULL 2/2] Kconfig updates for 4.17

Hi Linus, Please pull Kconfig updates for 4.17. The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae: Linux 4.16-rc5 (2018-03-11 17:25:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git

Re: [PATCH v4 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

Hi Viresh, On 4/3/2018 9:53 AM, Viresh Kumar wrote: > On 03-04-18, 08:11, Sricharan R wrote: >> Right, i was adding a similar one for krait cores [1]. There is code common >> in the >> init sequence across both (little). Do you suggest to make them common ? > > It may make sense as we are

Re: [PATCH v4 13/14] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

Hi Viresh, On 4/3/2018 9:53 AM, Viresh Kumar wrote: > On 03-04-18, 08:11, Sricharan R wrote: >> Right, i was adding a similar one for krait cores [1]. There is code common >> in the >> init sequence across both (little). Do you suggest to make them common ? > > It may make sense as we are

Re: [PATCH v17 01/10] LIB: Introduce a generic PIO mapping method

On Tue, Apr 03, 2018 at 05:01:37PM +0100, John Garry wrote: > > > > +int logic_pio_register_range(struct logic_pio_hwaddr *new_range) > > > > +{ > > > > + struct logic_pio_hwaddr *range; > > > > + resource_size_t start = new_range->hw_start; > > > > + resource_size_t end =

Re: [PATCH v17 01/10] LIB: Introduce a generic PIO mapping method

On Tue, Apr 03, 2018 at 05:01:37PM +0100, John Garry wrote: > > > > +int logic_pio_register_range(struct logic_pio_hwaddr *new_range) > > > > +{ > > > > + struct logic_pio_hwaddr *range; > > > > + resource_size_t start = new_range->hw_start; > > > > + resource_size_t end =

Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12)

- On Apr 2, 2018, at 11:33 AM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Apr 1, 2018, at 12:13 PM, One Thousand Gnomes > gno...@lxorguk.ukuu.org.uk wrote: > >> On Tue, 27 Mar 2018 12:05:23 -0400 >> Mathieu Desnoyers wrote: >> >>>

Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12)

- On Apr 2, 2018, at 11:33 AM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Apr 1, 2018, at 12:13 PM, One Thousand Gnomes > gno...@lxorguk.ukuu.org.uk wrote: > >> On Tue, 27 Mar 2018 12:05:23 -0400 >> Mathieu Desnoyers wrote: >> >>> Expose a new system call allowing

Re: [PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()

From: Al Viro Date: Tue, 3 Apr 2018 17:29:33 +0100 > On Mon, Apr 02, 2018 at 03:58:55PM -0700, Florian Fainelli wrote: >> skb->protocol is a __be16 which we would be calling htons() against, >> while this is not wrong per-se as it correctly results in swapping the >>

Re: [PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()

From: Al Viro Date: Tue, 3 Apr 2018 17:29:33 +0100 > On Mon, Apr 02, 2018 at 03:58:55PM -0700, Florian Fainelli wrote: >> skb->protocol is a __be16 which we would be calling htons() against, >> while this is not wrong per-se as it correctly results in swapping the >> value on LE hosts, this

Re: stable-rc build: 4 warnings 0 failures (stable-rc/v4.15.15)

On Tue, Apr 03, 2018 at 04:47:31PM +0200, Arnd Bergmann wrote: > On Sat, Mar 31, 2018 at 7:49 PM, Olof's autobuilder wrote: > > > Warnings: > > > > arm64.allmodconfig: > > WARNING: modpost: missing MODULE_LICENSE() in > > drivers/phy/qualcomm/phy-qcom-ufs.o > > This

Re: stable-rc build: 4 warnings 0 failures (stable-rc/v4.15.15)

On Tue, Apr 03, 2018 at 04:47:31PM +0200, Arnd Bergmann wrote: > On Sat, Mar 31, 2018 at 7:49 PM, Olof's autobuilder wrote: > > > Warnings: > > > > arm64.allmodconfig: > > WARNING: modpost: missing MODULE_LICENSE() in > > drivers/phy/qualcomm/phy-qcom-ufs.o > > This needs a backport of

[GIT PULL 1/2] Kbuild updates for 4.17

Hi Linus, Please pull Kbuild updates for v4.17. You will see a merge conflict in arch/blackfin/kernel/bfin_ksyms.c This file was already removed since the blackfin support was entirely dropped. So, please remove it. The following changes since commit

[GIT PULL 1/2] Kbuild updates for 4.17

Hi Linus, Please pull Kbuild updates for v4.17. You will see a merge conflict in arch/blackfin/kernel/bfin_ksyms.c This file was already removed since the blackfin support was entirely dropped. So, please remove it. The following changes since commit

Re: [PATCH v8 25/42] ARM: davinci: dm644x: add new clock init using common clock framework

On 04/03/2018 05:26 AM, Sekhar Nori wrote: On Friday 16 March 2018 08:22 AM, David Lechner wrote: +static struct resource dm644x_pll1_resources[] = { + { + .start = DAVINCI_PLL1_BASE, + .end= DAVINCI_PLL1_BASE + SZ_4K - 1, The .end should be

Re: [PATCH v8 25/42] ARM: davinci: dm644x: add new clock init using common clock framework

On 04/03/2018 05:26 AM, Sekhar Nori wrote: On Friday 16 March 2018 08:22 AM, David Lechner wrote: +static struct resource dm644x_pll1_resources[] = { + { + .start = DAVINCI_PLL1_BASE, + .end= DAVINCI_PLL1_BASE + SZ_4K - 1, The .end should be

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote: > Can you explain that much more clearly? I'm asking why booting via > UEFI Secure Boot should enable lockdown, and I don't see what this has > to do with kexec. And "someone blacklist[ing] your key in the > bootloader"

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote: > Can you explain that much more clearly? I'm asking why booting via > UEFI Secure Boot should enable lockdown, and I don't see what this has > to do with kexec. And "someone blacklist[ing] your key in the > bootloader" sounds like a

Re: [PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()

On Mon, Apr 02, 2018 at 03:58:55PM -0700, Florian Fainelli wrote: > skb->protocol is a __be16 which we would be calling htons() against, > while this is not wrong per-se as it correctly results in swapping the > value on LE hosts, this still upsets sparse. Adopt a similar pattern to > what other

Re: [PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()

On Mon, Apr 02, 2018 at 03:58:55PM -0700, Florian Fainelli wrote: > skb->protocol is a __be16 which we would be calling htons() against, > while this is not wrong per-se as it correctly results in swapping the > value on LE hosts, this still upsets sparse. Adopt a similar pattern to > what other

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 8:41 AM, Alexei Starovoitov wrote: > On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy Lutomirski wrote: >> > >> >> "bpf: Restrict kernel image access functions when the kernel is locked >> >> down": >> >> This patch just sucks in general. >> >

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 8:41 AM, Alexei Starovoitov wrote: > On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy Lutomirski wrote: >> > >> >> "bpf: Restrict kernel image access functions when the kernel is locked >> >> down": >> >> This patch just sucks in general. >> > >> > Yes - but that's what

Re: [PATCH v2 1/6] spi: core: handle timeout error from transfer_one()

On 04/03/2018 07:18 PM, Mark Brown wrote: On Tue, Apr 03, 2018 at 07:00:55PM +0300, Sergey Suloev wrote: On 04/03/2018 06:52 PM, Mark Brown wrote: On Tue, Apr 03, 2018 at 06:29:00PM +0300, Sergey Suloev wrote: As long as sun4i/sun6i SPI drivers have overriden the default "wait for completion"

Re: [PATCH v2 1/6] spi: core: handle timeout error from transfer_one()

On 04/03/2018 07:18 PM, Mark Brown wrote: On Tue, Apr 03, 2018 at 07:00:55PM +0300, Sergey Suloev wrote: On 04/03/2018 06:52 PM, Mark Brown wrote: On Tue, Apr 03, 2018 at 06:29:00PM +0300, Sergey Suloev wrote: As long as sun4i/sun6i SPI drivers have overriden the default "wait for completion"

Re: [PATCH net 2/2] net: systemport: Fix sparse warnings in bcm_sysport_insert_tsb()

On Mon, Apr 02, 2018 at 03:58:56PM -0700, Florian Fainelli wrote: > skb->protocol is a __be16 which we would be calling htons() against, > while this is not wrong per-se as it correctly results in swapping the > value on LE hosts, this still upsets sparse. Adopt a similar pattern to > what other

Re: [PATCH net 2/2] net: systemport: Fix sparse warnings in bcm_sysport_insert_tsb()

On Mon, Apr 02, 2018 at 03:58:56PM -0700, Florian Fainelli wrote: > skb->protocol is a __be16 which we would be calling htons() against, > while this is not wrong per-se as it correctly results in swapping the > value on LE hosts, this still upsets sparse. Adopt a similar pattern to > what other

Re: [PATCH 1/1] taging: fbtft: fix memory leak

On Tue, 2018-04-03 at 21:33 +0800, Xidong Wang wrote: > From: Xidong Wang <2711406...@qq.com> > > In function fbtft_framebuffer_alloc(), the memory allocated by > framebuffer_alloc() is not released on the error path that txbuflen > 0 > and txbuf, which holds the return value of devm_kzalloc(),

Re: [PATCH 1/1] taging: fbtft: fix memory leak

On Tue, 2018-04-03 at 21:33 +0800, Xidong Wang wrote: > From: Xidong Wang <2711406...@qq.com> > > In function fbtft_framebuffer_alloc(), the memory allocated by > framebuffer_alloc() is not released on the error path that txbuflen > 0 > and txbuf, which holds the return value of devm_kzalloc(),

Re: [PATCH v2 1/6] spi: core: handle timeout error from transfer_one()

On Tue, Apr 03, 2018 at 07:00:55PM +0300, Sergey Suloev wrote: > On 04/03/2018 06:52 PM, Mark Brown wrote: > > On Tue, Apr 03, 2018 at 06:29:00PM +0300, Sergey Suloev wrote: > > > As long as sun4i/sun6i SPI drivers have overriden the default > > > "wait for completion" procedure then we need to

Re: [PATCH v2 1/6] spi: core: handle timeout error from transfer_one()

On Tue, Apr 03, 2018 at 07:00:55PM +0300, Sergey Suloev wrote: > On 04/03/2018 06:52 PM, Mark Brown wrote: > > On Tue, Apr 03, 2018 at 06:29:00PM +0300, Sergey Suloev wrote: > > > As long as sun4i/sun6i SPI drivers have overriden the default > > > "wait for completion" procedure then we need to

Re: [PATCH v8 11/14] iommu/rockchip: Use OF_IOMMU to attach devices automatically

Hi Jeffy, Sorry for delayed response. On Mon, Mar 26, 2018 at 1:58 AM JeffyChen wrote: > Hi Daniel, > Thanks for your reply. > On 03/26/2018 02:31 PM, Daniel Kurtz wrote: > >> >+struct rk_iommudata { > >> >+ struct rk_iommu *iommu; > >> >+}; > > Why do we

Re: [PATCH v8 11/14] iommu/rockchip: Use OF_IOMMU to attach devices automatically

Hi Jeffy, Sorry for delayed response. On Mon, Mar 26, 2018 at 1:58 AM JeffyChen wrote: > Hi Daniel, > Thanks for your reply. > On 03/26/2018 02:31 PM, Daniel Kurtz wrote: > >> >+struct rk_iommudata { > >> >+ struct rk_iommu *iommu; > >> >+}; > > Why do we need this struct? Can't we

<    4   5   6   7   8   9   10   11   12   13   >