[PATCH net 5/5] net/ncsi: Fix length of GVI response packet

From: Gavin Shan The length of GVI (GetVersionInfo) response packet should be 40 instead of 36. This issue was found from /sys/kernel/debug/ncsi/eth0/stats. # ethtool --ncsi eth0 swstats : RESPONSE OK TIMEOUT ERROR

[PATCH net 5/5] net/ncsi: Fix length of GVI response packet

From: Gavin Shan The length of GVI (GetVersionInfo) response packet should be 40 instead of 36. This issue was found from /sys/kernel/debug/ncsi/eth0/stats. # ethtool --ncsi eth0 swstats : RESPONSE OK TIMEOUT ERROR === GVI 0

[PATCH net 2/5] net/ncsi: Stop monitor if channel times out or is inactive

ncsi_channel_monitor() misses stopping the channel monitor in several places that it should, causing a WARN_ON_ONCE() to trigger when the monitor is re-started later, eg: [ 459.04] WARNING: CPU: 0 PID: 1093 at net/ncsi/ncsi-manage.c:269 ncsi_start_channel_monitor+0x7c/0x90 [ 459.04]

[PATCH net 1/5] net/ncsi: Fix AEN HNCDSC packet length

Correct the value of the HNCDSC AEN packet. Fixes: 7a82ecf4cfb85 "net/ncsi: NCSI AEN packet handler" Signed-off-by: Samuel Mendoza-Jonas --- net/ncsi/ncsi-aen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ncsi/ncsi-aen.c b/net/ncsi/ncsi-aen.c

[PATCH net 2/5] net/ncsi: Stop monitor if channel times out or is inactive

ncsi_channel_monitor() misses stopping the channel monitor in several places that it should, causing a WARN_ON_ONCE() to trigger when the monitor is re-started later, eg: [ 459.04] WARNING: CPU: 0 PID: 1093 at net/ncsi/ncsi-manage.c:269 ncsi_start_channel_monitor+0x7c/0x90 [ 459.04]

[PATCH net 1/5] net/ncsi: Fix AEN HNCDSC packet length

Correct the value of the HNCDSC AEN packet. Fixes: 7a82ecf4cfb85 "net/ncsi: NCSI AEN packet handler" Signed-off-by: Samuel Mendoza-Jonas --- net/ncsi/ncsi-aen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ncsi/ncsi-aen.c b/net/ncsi/ncsi-aen.c index

Re: [PATCH] hwmon: (coretemp) remove duplicated coretemp for same core id

> From: "Guenter Roeck" > To: "Shu Wang" > Cc: "fenghua yu" , jdelv...@suse.com, > linux-hw...@vger.kernel.org, > linux-kernel@vger.kernel.org, ch...@redhat.com, yiz...@redhat.com > Sent: Wednesday, October 18, 2017 9:14:39 PM >

Re: [PATCH] hwmon: (coretemp) remove duplicated coretemp for same core id

> From: "Guenter Roeck" > To: "Shu Wang" > Cc: "fenghua yu" , jdelv...@suse.com, > linux-hw...@vger.kernel.org, > linux-kernel@vger.kernel.org, ch...@redhat.com, yiz...@redhat.com > Sent: Wednesday, October 18, 2017 9:14:39 PM > Subject: Re: [PATCH] hwmon: (coretemp) remove duplicated coretemp

[GIT PULL] Security subystem fixes for v4.14-rc5

KEYS: Load key expiry time atomically in keyring_search_iterator() KEYS: load key flags and expiry time atomically in proc_keys_show() Eric Sesterhenn (1): pkcs7: Prevent NULL pointer dereference, since sinfo is not always set. James Morris (1): Merge commit 'tags/keys-fixe

[GIT PULL] Security subystem fixes for v4.14-rc5

KEYS: Load key expiry time atomically in keyring_search_iterator() KEYS: load key flags and expiry time atomically in proc_keys_show() Eric Sesterhenn (1): pkcs7: Prevent NULL pointer dereference, since sinfo is not always set. James Morris (1): Merge commit 'tags/keys-fixe

Re: more build problems with "Makefile: move stackprotector availability out of Kconfig"

On Wed, Oct 18, 2017 at 5:41 PM, Masahiro Yamada wrote: > Hi Kees, > > 2017-10-18 5:06 GMT+09:00 Kees Cook : >> On Tue, Oct 17, 2017 at 12:56 PM, Andrew Morton >> wrote: >>> On Tue, 17 Oct 2017 11:53:10 -0700 Kees

Re: more build problems with "Makefile: move stackprotector availability out of Kconfig"

On Wed, Oct 18, 2017 at 5:41 PM, Masahiro Yamada wrote: > Hi Kees, > > 2017-10-18 5:06 GMT+09:00 Kees Cook : >> On Tue, Oct 17, 2017 at 12:56 PM, Andrew Morton >> wrote: >>> On Tue, 17 Oct 2017 11:53:10 -0700 Kees Cook wrote: >>> On Tue, Oct 17, 2017 at 11:52 AM, Mark Brown wrote: >

Re: [PATCH v2 2/4] rtc: mediatek: add driver for RTC on MT7622 SoC

On Wed, 2017-10-18 at 17:52 +0800, Yingjoe Chen wrote: > On Tue, 2017-10-17 at 17:40 +0800, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > This patch introduces the driver for the RTC on MT7622 SoC. > > > > Signed-off-by: Sean Wang > >

Re: [PATCH v2 2/4] rtc: mediatek: add driver for RTC on MT7622 SoC

On Wed, 2017-10-18 at 17:52 +0800, Yingjoe Chen wrote: > On Tue, 2017-10-17 at 17:40 +0800, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > This patch introduces the driver for the RTC on MT7622 SoC. > > > > Signed-off-by: Sean Wang > > --- > > drivers/rtc/Kconfig | 10 ++ > >

[PATCH] f2fs: limit # of inmemory pages

If some abnormal users try lots of atomic write operations, f2fs is able to produce pinned pages in the main memory which affects system performance. This patch limits that as 20% over total memory size, and if f2fs reaches to the limit, it will drop all the inmemory pages. Signed-off-by: Jaegeuk

[PATCH] f2fs: limit # of inmemory pages

If some abnormal users try lots of atomic write operations, f2fs is able to produce pinned pages in the main memory which affects system performance. This patch limits that as 20% over total memory size, and if f2fs reaches to the limit, it will drop all the inmemory pages. Signed-off-by: Jaegeuk

Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel

On Wed, Oct 18, 2017 at 03:15:03PM +0200, Thomas Gleixner wrote: > On Wed, 18 Oct 2017, Linus Torvalds wrote: > > On Tue, Oct 17, 2017 at 3:33 AM, Joonsoo Kim wrote: > > > > > > It looks like a compiler bug. The code of slob_units() try to read two > > > bytes at

Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel

On Wed, Oct 18, 2017 at 03:15:03PM +0200, Thomas Gleixner wrote: > On Wed, 18 Oct 2017, Linus Torvalds wrote: > > On Tue, Oct 17, 2017 at 3:33 AM, Joonsoo Kim wrote: > > > > > > It looks like a compiler bug. The code of slob_units() try to read two > > > bytes at 88001c4afffe. It's valid. But

Re: dtc issue with overlays starting in next-20171009

On Wed, Oct 18, 2017 at 03:16:34PM -0500, Rob Herring wrote: > Use devicetree-compiler list for dtc issues please. > > On Wed, Oct 18, 2017 at 2:33 PM, Frank Rowand wrote: > > Hi Rob, Alan, > > > > On 10/18/17 08:58, Alan Tull wrote: > >> Hi Rob, > >> > >> I've noticed a

Re: dtc issue with overlays starting in next-20171009

On Wed, Oct 18, 2017 at 03:16:34PM -0500, Rob Herring wrote: > Use devicetree-compiler list for dtc issues please. > > On Wed, Oct 18, 2017 at 2:33 PM, Frank Rowand wrote: > > Hi Rob, Alan, > > > > On 10/18/17 08:58, Alan Tull wrote: > >> Hi Rob, > >> > >> I've noticed a problem compiling DT

Re: dtc issue with overlays starting in next-20171009

On Wed, Oct 18, 2017 at 07:17:04PM -0500, Rob Herring wrote: > On Wed, Oct 18, 2017 at 5:34 PM, Frank Rowand wrote: > > On 10/18/17 13:16, Rob Herring wrote: > >> Use devicetree-compiler list for dtc issues please. > >> > >> On Wed, Oct 18, 2017 at 2:33 PM, Frank Rowand

Re: dtc issue with overlays starting in next-20171009

On Wed, Oct 18, 2017 at 07:17:04PM -0500, Rob Herring wrote: > On Wed, Oct 18, 2017 at 5:34 PM, Frank Rowand wrote: > > On 10/18/17 13:16, Rob Herring wrote: > >> Use devicetree-compiler list for dtc issues please. > >> > >> On Wed, Oct 18, 2017 at 2:33 PM, Frank Rowand > >> wrote: > >>> Hi

Re: dtc issue with overlays starting in next-20171009

On Wed, Oct 18, 2017 at 03:34:08PM -0700, Frank Rowand wrote: > On 10/18/17 13:16, Rob Herring wrote: > > Use devicetree-compiler list for dtc issues please. > > > > On Wed, Oct 18, 2017 at 2:33 PM, Frank Rowand > > wrote: > >> Hi Rob, Alan, > >> > >> On 10/18/17 08:58,

Re: dtc issue with overlays starting in next-20171009

On Wed, Oct 18, 2017 at 03:34:08PM -0700, Frank Rowand wrote: > On 10/18/17 13:16, Rob Herring wrote: > > Use devicetree-compiler list for dtc issues please. > > > > On Wed, Oct 18, 2017 at 2:33 PM, Frank Rowand > > wrote: > >> Hi Rob, Alan, > >> > >> On 10/18/17 08:58, Alan Tull wrote: > >>>

Re: [PATCH 1/2] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default

On Wed, Oct 18, 2017 at 03:36:05PM +0200, Thomas Gleixner wrote: > On Wed, 18 Oct 2017, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > > > > > On Wed, 18 Oct 2017, Byungchul Park wrote: > > > > #ifdef CONFIG_LOCKDEP_CROSSRELEASE > > > > +#ifdef

Re: [PATCH 1/2] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default

On Wed, Oct 18, 2017 at 03:36:05PM +0200, Thomas Gleixner wrote: > On Wed, 18 Oct 2017, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > > > > > On Wed, 18 Oct 2017, Byungchul Park wrote: > > > > #ifdef CONFIG_LOCKDEP_CROSSRELEASE > > > > +#ifdef CONFIG_CROSSRELEASE_STACK_TRACE > > > >

Re: [RESEND PATCH 3/3] lockdep: Assign a lock_class per gendisk used for wait_for_completion()

On Wed, Oct 18, 2017 at 11:59:16AM +0200, Ingo Molnar wrote: > > * Byungchul Park wrote: > > > diff --git a/block/bio.c b/block/bio.c > > index 9a63597..0d4d6c0 100644 > > --- a/block/bio.c > > +++ b/block/bio.c > > @@ -941,7 +941,7 @@ int submit_bio_wait(struct bio

Re: [RESEND PATCH 3/3] lockdep: Assign a lock_class per gendisk used for wait_for_completion()

On Wed, Oct 18, 2017 at 11:59:16AM +0200, Ingo Molnar wrote: > > * Byungchul Park wrote: > > > diff --git a/block/bio.c b/block/bio.c > > index 9a63597..0d4d6c0 100644 > > --- a/block/bio.c > > +++ b/block/bio.c > > @@ -941,7 +941,7 @@ int submit_bio_wait(struct bio *bio) > > { > > struct

Re: [PATCH 2/2] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE

On Wed, Oct 18, 2017 at 12:12:08PM +0200, Ingo Molnar wrote: > > * Byungchul Park wrote: > > > Now the performance regression was fixed, re-enable LOCKDEP_CROSSRELEASE > > and LOCKDEP_COMPLETIONS. > > Please write out CONFIG_ variables, i.e. CONFIG_LOCKDEP_CROSSRELEASE,

Re: [PATCH 2/2] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE

On Wed, Oct 18, 2017 at 12:12:08PM +0200, Ingo Molnar wrote: > > * Byungchul Park wrote: > > > Now the performance regression was fixed, re-enable LOCKDEP_CROSSRELEASE > > and LOCKDEP_COMPLETIONS. > > Please write out CONFIG_ variables, i.e. CONFIG_LOCKDEP_CROSSRELEASE, etc. - > to > make it

Re: Fix false positive by LOCKDEP_CROSSRELEASE

On Wed, Oct 18, 2017 at 02:29:56PM +, Bart Van Assche wrote: > On Wed, 2017-10-18 at 18:38 +0900, Byungchul Park wrote: > > Several false positives were reported, so I tried to fix them. > > > > It would be appreciated if you tell me if it works as expected, or let > > me know your opinion. >

Re: Fix false positive by LOCKDEP_CROSSRELEASE

On Wed, Oct 18, 2017 at 02:29:56PM +, Bart Van Assche wrote: > On Wed, 2017-10-18 at 18:38 +0900, Byungchul Park wrote: > > Several false positives were reported, so I tried to fix them. > > > > It would be appreciated if you tell me if it works as expected, or let > > me know your opinion. >

Re: [RFC PATCH v4 4/8] drm/rockchip: dw_hdmi: Fix error handling path

Hi Sean, Thanks for your review. On 10/18/2017 02:10 AM, Sean Paul wrote: On Tue, Oct 17, 2017 at 06:16:20PM +0800, Jeffy Chen wrote: >Add missing clk_disable_unprepare() in bind()'s error handling path. This also isn't disabled in unbind(), is that intentional? i wasn't able to do that

Re: [RFC PATCH v4 4/8] drm/rockchip: dw_hdmi: Fix error handling path

Hi Sean, Thanks for your review. On 10/18/2017 02:10 AM, Sean Paul wrote: On Tue, Oct 17, 2017 at 06:16:20PM +0800, Jeffy Chen wrote: >Add missing clk_disable_unprepare() in bind()'s error handling path. This also isn't disabled in unbind(), is that intentional? i wasn't able to do that

Re: [PATCH v5] printk: hash addresses printed with %p

On Thu, Oct 19, 2017 at 03:36:20AM +0200, Jason A. Donenfeld wrote: > On Thu, Oct 19, 2017 at 3:31 AM, Sergey Senozhatsky > wrote: > > On (10/19/17 03:03), Jason A. Donenfeld wrote: > > [..] > >> 1) Go back to the spinlock yourself. > > > > so we ruled out NMI

Re: [PATCH v5] printk: hash addresses printed with %p

On Thu, Oct 19, 2017 at 03:36:20AM +0200, Jason A. Donenfeld wrote: > On Thu, Oct 19, 2017 at 3:31 AM, Sergey Senozhatsky > wrote: > > On (10/19/17 03:03), Jason A. Donenfeld wrote: > > [..] > >> 1) Go back to the spinlock yourself. > > > > so we ruled out NMI deadlocks? > > Oh, right. No, I

Re: [PATCH v5] printk: hash addresses printed with %p

On Thu, Oct 19, 2017 at 3:31 AM, Sergey Senozhatsky wrote: > On (10/19/17 03:03), Jason A. Donenfeld wrote: > [..] >> 1) Go back to the spinlock yourself. > > so we ruled out NMI deadlocks? Oh, right. No, I haven't thought through this enough to rule it out.

Re: [PATCH v5] printk: hash addresses printed with %p

On Thu, Oct 19, 2017 at 3:31 AM, Sergey Senozhatsky wrote: > On (10/19/17 03:03), Jason A. Donenfeld wrote: > [..] >> 1) Go back to the spinlock yourself. > > so we ruled out NMI deadlocks? Oh, right. No, I haven't thought through this enough to rule it out. Indeed if that's an issue, the locks

Re: [PATCH] thermal/drivers/hisi: disable multi alarm support for hi3660 SoC

在 2017/10/18 23:54, Daniel Lezcano 写道: On 18/10/2017 11:15, Tao Wang wrote: From: Kevin Wangtao multi alarm interrupt forced a re-trigger of power_allocator_throttle which changes the PID's actual sampling rate, this isn't optimal for IPA, it is best to disable

Re: [PATCH] thermal/drivers/hisi: disable multi alarm support for hi3660 SoC

在 2017/10/18 23:54, Daniel Lezcano 写道: On 18/10/2017 11:15, Tao Wang wrote: From: Kevin Wangtao multi alarm interrupt forced a re-trigger of power_allocator_throttle which changes the PID's actual sampling rate, this isn't optimal for IPA, it is best to disable multi alarm support now and

[PATCH v2] driver core: Move device_links_purge() after bus_remove_device()

The current ordering of code in device_del() triggers a WARN_ON() in device_links_purge(), because of an unexpected link status. The device_links_unbind_consumers() call in device_release_driver() has to take place before device_links_purge() for the status of all links to be correct, so move the

[PATCH v2] driver core: Move device_links_purge() after bus_remove_device()

The current ordering of code in device_del() triggers a WARN_ON() in device_links_purge(), because of an unexpected link status. The device_links_unbind_consumers() call in device_release_driver() has to take place before device_links_purge() for the status of all links to be correct, so move the

Re: [PATCH v5] printk: hash addresses printed with %p

On (10/19/17 03:03), Jason A. Donenfeld wrote: [..] > 1) Go back to the spinlock yourself. so we ruled out NMI deadlocks? -ss

Re: [PATCH v5] printk: hash addresses printed with %p

On (10/19/17 03:03), Jason A. Donenfeld wrote: [..] > 1) Go back to the spinlock yourself. so we ruled out NMI deadlocks? -ss

[PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue

From: Hiroyuki Yokoyama SYS/RT/Audio DMAC includes independent data buffers for reading and writing. Therefore, the read transfer counter and write transfer counter have different values. TCR indicates read counter, and TCRB indicates write counter. The

[PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue

From: Hiroyuki Yokoyama SYS/RT/Audio DMAC includes independent data buffers for reading and writing. Therefore, the read transfer counter and write transfer counter have different values. TCR indicates read counter, and TCRB indicates write counter. The relationship is like below. TCR

Re: [GIT PULL] tpmdd updates for Linux 4.15

:55 -0700) > > are available in the git repository at: > > git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20171018 Thanks, merged to next-tpm and next-general in: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git - James -- James Morris <james.l.mor...@oracle.com>

Re: [GIT PULL] tpmdd updates for Linux 4.15

:55 -0700) > > are available in the git repository at: > > git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20171018 Thanks, merged to next-tpm and next-general in: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git - James -- James Morris

[PATCH 3/3] rpmsg: glink: Use best fit intent during tx

Intents can vary in size, try to find the best fitting remote intent instead of first fit when sending a message to the remote proc. Signed-off-by: Chris Lew --- drivers/rpmsg/qcom_glink_native.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git

[PATCH 3/3] rpmsg: glink: Use best fit intent during tx

Intents can vary in size, try to find the best fitting remote intent instead of first fit when sending a message to the remote proc. Signed-off-by: Chris Lew --- drivers/rpmsg/qcom_glink_native.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git

Re: [PATCH] driver core: Move device_links_purge() after bus_remove_device()

Hi Rafael, On 10/19/2017 07:36 AM, Rafael J. Wysocki wrote: Why don't you write something like the following: "The current ordering of code in device_del() triggers a WARN_ON() in device_links_purge(), because of an unexpected link status. The device_links_unbind_consumers() call in

[PATCH 1/3] dt-bindings: soc: qcom: Support GLINK intents

Virtual GLINK channels may know what throughput to expect from a remoteproc. An intent advertises to the remoteproc this channel is ready to receive data. Allow a channel to define the size and amount of intents to be prequeued. Signed-off-by: Chris Lew ---

Re: [PATCH] driver core: Move device_links_purge() after bus_remove_device()

Hi Rafael, On 10/19/2017 07:36 AM, Rafael J. Wysocki wrote: Why don't you write something like the following: "The current ordering of code in device_del() triggers a WARN_ON() in device_links_purge(), because of an unexpected link status. The device_links_unbind_consumers() call in

[PATCH 1/3] dt-bindings: soc: qcom: Support GLINK intents

Virtual GLINK channels may know what throughput to expect from a remoteproc. An intent advertises to the remoteproc this channel is ready to receive data. Allow a channel to define the size and amount of intents to be prequeued. Signed-off-by: Chris Lew ---

[PATCH 0/3] GLINK intent preallocation support

Intents are used to specify when a channel can receive data from a remoteproc. Add support for channels to customize the size and amount of prequeued intents. An audio channel might expect to receive 3 packets of size 4k in rapid succession. This change allows the channel to prepare for this data

[PATCH 0/3] GLINK intent preallocation support

Intents are used to specify when a channel can receive data from a remoteproc. Add support for channels to customize the size and amount of prequeued intents. An audio channel might expect to receive 3 packets of size 4k in rapid succession. This change allows the channel to prepare for this data

[PATCH 2/3] rpmsg: glink: Add support to preallocate intents

The base intents prequeued during channel creation may not satisfy a channel's throughput requirement. Add support for intents dt-binding to allow channels to specify the size and amount of intents to prequeue during endpoint announcement. Signed-off-by: Chris Lew ---

[PATCH 2/3] rpmsg: glink: Add support to preallocate intents

The base intents prequeued during channel creation may not satisfy a channel's throughput requirement. Add support for intents dt-binding to allow channels to specify the size and amount of intents to prequeue during endpoint announcement. Signed-off-by: Chris Lew ---

Re: [PATCH] zswap: Same-filled pages handling

On Wed, Oct 18, 2017 at 01:43:10PM -0700, Andi Kleen wrote: > > +static int zswap_is_page_same_filled(void *ptr, unsigned long *value) > > +{ > > + unsigned int pos; > > + unsigned long *page; > > + > > + page = (unsigned long *)ptr; > > + for (pos = 1; pos < PAGE_SIZE / sizeof(*page);

Re: [PATCH] zswap: Same-filled pages handling

On Wed, Oct 18, 2017 at 01:43:10PM -0700, Andi Kleen wrote: > > +static int zswap_is_page_same_filled(void *ptr, unsigned long *value) > > +{ > > + unsigned int pos; > > + unsigned long *page; > > + > > + page = (unsigned long *)ptr; > > + for (pos = 1; pos < PAGE_SIZE / sizeof(*page);

Re: [PATCH] zswap: Same-filled pages handling

On Thu, Oct 19, 2017 at 12:31:18AM +0300, Timofey Titovets wrote: > > +static void zswap_fill_page(void *ptr, unsigned long value) > > +{ > > + unsigned int pos; > > + unsigned long *page; > > + > > + page = (unsigned long *)ptr; > > + if (value == 0) > > +

Re: [PATCH] zswap: Same-filled pages handling

On Thu, Oct 19, 2017 at 12:31:18AM +0300, Timofey Titovets wrote: > > +static void zswap_fill_page(void *ptr, unsigned long value) > > +{ > > + unsigned int pos; > > + unsigned long *page; > > + > > + page = (unsigned long *)ptr; > > + if (value == 0) > > +

Re: [PATCH] powerpc/watchdog: Convert timers to use timer_setup()

Michael Ellerman writes: > Kees Cook writes: >> On Tue, Oct 17, 2017 at 5:29 AM, Michael Ellerman >> wrote: >>> Nicholas Piggin writes: On Mon, 16 Oct 2017 16:47:10 -0700 Kees Cook

Re: [PATCH] powerpc/watchdog: Convert timers to use timer_setup()

Michael Ellerman writes: > Kees Cook writes: >> On Tue, Oct 17, 2017 at 5:29 AM, Michael Ellerman >> wrote: >>> Nicholas Piggin writes: On Mon, 16 Oct 2017 16:47:10 -0700 Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer > to >

Re: [PATCH v5] printk: hash addresses printed with %p

On Wed, Oct 18, 2017 at 11:30 PM, Tobin C. Harding wrote: > +static siphash_key_t ptr_secret __read_mostly; > +static atomic_t have_key = ATOMIC_INIT(0); > + > +static void initialize_ptr_secret(void) > +{ > + if (atomic_read(_key) == 1) > + return; > + > +

Re: [PATCH v5] printk: hash addresses printed with %p

On Wed, Oct 18, 2017 at 11:30 PM, Tobin C. Harding wrote: > +static siphash_key_t ptr_secret __read_mostly; > +static atomic_t have_key = ATOMIC_INIT(0); > + > +static void initialize_ptr_secret(void) > +{ > + if (atomic_read(_key) == 1) > + return; > + > +

[PATCH] clk: uniphier: fix parent of miodmac clock data

The "miodmac" is not a child of "stdmac". They are independent from each other. Fix it. Signed-off-by: Masahiro Yamada --- drivers/clk/uniphier/clk-uniphier-mio.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git

[PATCH] clk: uniphier: fix parent of miodmac clock data

The "miodmac" is not a child of "stdmac". They are independent from each other. Fix it. Signed-off-by: Masahiro Yamada --- drivers/clk/uniphier/clk-uniphier-mio.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/clk/uniphier/clk-uniphier-mio.c

Re: [PATCH] dmaengine: rcar-dmac: use DMATCRB when xxx_TO_MEM direction

Hi Laurent, Geert > >> > That's correct, but I don't think the explanation was detailed and clear > >> > enough. If it was Geert wouldn't have asked for a v2, and you wouldn't > >> > have > >> > agreed to his request :-) > >> > >> OK. Let's follow Vinod's decision. > >> > >> Vinod, I'm happy if

Re: [PATCH] dmaengine: rcar-dmac: use DMATCRB when xxx_TO_MEM direction

Hi Laurent, Geert > >> > That's correct, but I don't think the explanation was detailed and clear > >> > enough. If it was Geert wouldn't have asked for a v2, and you wouldn't > >> > have > >> > agreed to his request :-) > >> > >> OK. Let's follow Vinod's decision. > >> > >> Vinod, I'm happy if

Re: [PATCH 1/2 v3] user namespace: use union in {g,u}idmap struct

Christian Brauner writes: > I'm not sure why the build is complaining about how the union is initialized > here. This looks legitimate to me and I can't reproduce this locally with or > without the appended config. The struct introduced here is: > > #define

Re: [PATCH 1/2 v3] user namespace: use union in {g,u}idmap struct

Christian Brauner writes: > I'm not sure why the build is complaining about how the union is initialized > here. This looks legitimate to me and I can't reproduce this locally with or > without the appended config. The struct introduced here is: > > #define UID_GID_MAP_MAX_EXTENTS 5 > > struct

[PATCH 1/3] iommu/vt-d: Missing checks for pasid tables if allocation fails

intel_svm_alloc_pasid_tables() might return an error but never be checked by the callers. Later when intel_svm_bind_mm() is called, there are no checks for valid pasid tables before enabling them. Signed-off-by: Ashok Raj Signed-off-by: Lu Baolu

[PATCH 1/3] iommu/vt-d: Missing checks for pasid tables if allocation fails

intel_svm_alloc_pasid_tables() might return an error but never be checked by the callers. Later when intel_svm_bind_mm() is called, there are no checks for valid pasid tables before enabling them. Signed-off-by: Ashok Raj Signed-off-by: Lu Baolu --- drivers/iommu/intel-svm.c | 2 +- 1 file

[PATCH 3/3] iommu/vt-d: Clear pasid table entry when memory unbound

In intel_svm_unbind_mm(), pasid table entry must be cleared during svm free. Otherwise, hardware may be set up with a wild pointer. Suggested-by: Ashok Raj Signed-off-by: Lu Baolu --- drivers/iommu/intel-svm.c | 2 ++ 1 file changed, 2

[PATCH 3/3] iommu/vt-d: Clear pasid table entry when memory unbound

In intel_svm_unbind_mm(), pasid table entry must be cleared during svm free. Otherwise, hardware may be set up with a wild pointer. Suggested-by: Ashok Raj Signed-off-by: Lu Baolu --- drivers/iommu/intel-svm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/intel-svm.c

[PATCH 2/3] iommu/vt-d: Clear Page Request Overflow fault bit

Currently Page Request Overflow bit in IOMMU Fault Status register is not cleared. Not clearing this bit would mean that any future page-request is going to be automatically dropped by IOMMU. Suggested-by: Ashok Raj Signed-off-by: Lu Baolu ---

[PATCH 2/3] iommu/vt-d: Clear Page Request Overflow fault bit

Currently Page Request Overflow bit in IOMMU Fault Status register is not cleared. Not clearing this bit would mean that any future page-request is going to be automatically dropped by IOMMU. Suggested-by: Ashok Raj Signed-off-by: Lu Baolu --- drivers/iommu/dmar.c| 3 ++-

Re: RFC(v2): Audit Kernel Container IDs

Aleksa Sarai writes: >>> The security implications are that anything that can change the label >>> could also hide itself and its doings from the audit system and thus >>> would be used as a means to evade detection. I actually think this >>> means the label should be write once

Re: RFC(v2): Audit Kernel Container IDs

Aleksa Sarai writes: >>> The security implications are that anything that can change the label >>> could also hide itself and its doings from the audit system and thus >>> would be used as a means to evade detection. I actually think this >>> means the label should be write once (once you've

Re: more build problems with "Makefile: move stackprotector availability out of Kconfig"

Hi Kees, 2017-10-18 5:06 GMT+09:00 Kees Cook : > On Tue, Oct 17, 2017 at 12:56 PM, Andrew Morton > wrote: >> On Tue, 17 Oct 2017 11:53:10 -0700 Kees Cook wrote: >> >>> On Tue, Oct 17, 2017 at 11:52 AM, Mark Brown

Re: more build problems with "Makefile: move stackprotector availability out of Kconfig"

Hi Kees, 2017-10-18 5:06 GMT+09:00 Kees Cook : > On Tue, Oct 17, 2017 at 12:56 PM, Andrew Morton > wrote: >> On Tue, 17 Oct 2017 11:53:10 -0700 Kees Cook wrote: >> >>> On Tue, Oct 17, 2017 at 11:52 AM, Mark Brown wrote: >>> > On Tue, Oct 17, 2017 at 08:47:06PM +0200, Arnd Bergmann wrote: >>> >

[RFC v6-1 1/1] platform/x86: intel_pmc_ipc: Use spin_lock to protect GCR updates

From: Kuppuswamy Sathyanarayanan Currently, update_no_reboot_bit() function implemented in this driver uses mutex_lock() to protect its register updates. But this function is called with in atomic context in iTCO_wdt_start() and iTCO_wdt_stop()

[RFC v6-1 1/1] platform/x86: intel_pmc_ipc: Use spin_lock to protect GCR updates

From: Kuppuswamy Sathyanarayanan Currently, update_no_reboot_bit() function implemented in this driver uses mutex_lock() to protect its register updates. But this function is called with in atomic context in iTCO_wdt_start() and iTCO_wdt_stop() functions in iTCO_wdt.c driver, which in turn

Re: [PATCH] Input: stmfts: Fix bug of ABS_MT_POSITION_* maximum size

On Wed, Oct 18, 2017 at 07:38:30PM +0900, Chanwoo Choi wrote: > The commit 78bcac7b2ae1e ("Input: add support for the STMicroelectronics > FingerTip touchscreen) used the 'touchscreen_parse_properties()' helper > function in order to get the value of common properties. > > But, commit

Re: [PATCH] Input: stmfts: Fix bug of ABS_MT_POSITION_* maximum size

On Wed, Oct 18, 2017 at 07:38:30PM +0900, Chanwoo Choi wrote: > The commit 78bcac7b2ae1e ("Input: add support for the STMicroelectronics > FingerTip touchscreen) used the 'touchscreen_parse_properties()' helper > function in order to get the value of common properties. > > But, commit

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

2017-10-18 19:23 GMT+09:00 Kunihiko Hayashi : > On Mon, 16 Oct 2017 00:08:21 +0900 wrote: >> priv->rst = devm_reset_control_get_optional_shared(dev, NULL); >> if (IS_ERR(priv->rst)) >> return PTR_ERR(priv->rst); > > The clk

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

2017-10-18 19:23 GMT+09:00 Kunihiko Hayashi : > On Mon, 16 Oct 2017 00:08:21 +0900 wrote: >> priv->rst = devm_reset_control_get_optional_shared(dev, NULL); >> if (IS_ERR(priv->rst)) >> return PTR_ERR(priv->rst); > > The clk and reset are optional in the driver. > Referring to your

Re: [PATCH] input: touchscreen: ti_am335x_tsc: Fix incorrect step config for 5 wire touchscreen

On Wed, Oct 18, 2017 at 07:18:11AM +0200, Michael Nazzareno Trimarchi wrote: > Hi > > On Tue, Sep 19, 2017 at 8:29 AM, Vignesh R wrote: > > From: Jeff Lance > > > > Step config setting for 5 wire touchscreen is incorrect for Y coordinates. > > It was broken

Re: [PATCH] input: touchscreen: ti_am335x_tsc: Fix incorrect step config for 5 wire touchscreen

On Wed, Oct 18, 2017 at 07:18:11AM +0200, Michael Nazzareno Trimarchi wrote: > Hi > > On Tue, Sep 19, 2017 at 8:29 AM, Vignesh R wrote: > > From: Jeff Lance > > > > Step config setting for 5 wire touchscreen is incorrect for Y coordinates. > > It was broken while we moved to DT. If you look

[RFC v6 3/9] platform/x86: intel_punit_ipc: Fix resource ioremap warning

From: Kuppuswamy Sathyanarayanan For PUNIT device, ISPDRIVER_IPC and GTDDRIVER_IPC resources are not mandatory. So when PMC IPC driver creates a PUNIT device, if these resources are not available then it creates dummy resource entries for these missing

[RFC v6 3/9] platform/x86: intel_punit_ipc: Fix resource ioremap warning

From: Kuppuswamy Sathyanarayanan For PUNIT device, ISPDRIVER_IPC and GTDDRIVER_IPC resources are not mandatory. So when PMC IPC driver creates a PUNIT device, if these resources are not available then it creates dummy resource entries for these missing resources. But during PUNIT device probe ,

[RFC v6 4/9] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

From: Kuppuswamy Sathyanarayanan Currently, we have lot of repetitive code in dependent device resource allocation and device creation handling code. This logic can be improved if we use MFD framework for dependent device creation. This patch adds this

[RFC v6 4/9] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

From: Kuppuswamy Sathyanarayanan Currently, we have lot of repetitive code in dependent device resource allocation and device creation handling code. This logic can be improved if we use MFD framework for dependent device creation. This patch adds this support. Signed-off-by: Kuppuswamy

[RFC v6 6/9] platform: x86: Add generic Intel IPC driver

From: Kuppuswamy Sathyanarayanan Currently intel_scu_ipc.c, intel_pmc_ipc.c and intel_punit_ipc.c redundantly implements the same IPC features and has lot of code duplication between them. This driver addresses this issue by grouping the common IPC

[RFC v6 6/9] platform: x86: Add generic Intel IPC driver

From: Kuppuswamy Sathyanarayanan Currently intel_scu_ipc.c, intel_pmc_ipc.c and intel_punit_ipc.c redundantly implements the same IPC features and has lot of code duplication between them. This driver addresses this issue by grouping the common IPC functionalities under the same driver.

[RFC v6 5/9] platform/x86: intel_pmc_ipc: Use regmap calls for GCR updates

From: Kuppuswamy Sathyanarayanan This patch adds support for regmap based implementation for GCR read/write/update APIs. Signed-off-by: Kuppuswamy Sathyanarayanan --- drivers/platform/x86/Kconfig

[RFC v6 5/9] platform/x86: intel_pmc_ipc: Use regmap calls for GCR updates

From: Kuppuswamy Sathyanarayanan This patch adds support for regmap based implementation for GCR read/write/update APIs. Signed-off-by: Kuppuswamy Sathyanarayanan --- drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/intel_pmc_ipc.c | 121 +--

[RFC v6 8/9] platform/x86: intel_pmc_ipc: Use generic Intel IPC device calls

From: Kuppuswamy Sathyanarayanan Removed redundant IPC helper functions and refactored the driver to use generic IPC device driver APIs. Also, cleaned up the driver to minimize the usage of global variable ipcdev by propogating the struct

[RFC v6 8/9] platform/x86: intel_pmc_ipc: Use generic Intel IPC device calls

From: Kuppuswamy Sathyanarayanan Removed redundant IPC helper functions and refactored the driver to use generic IPC device driver APIs. Also, cleaned up the driver to minimize the usage of global variable ipcdev by propogating the struct intel_pmc_ipc_dev pointer or by getting it from device

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