[PATCH 0/4] Qualcomm Camera Control Interface driver

This patchset adds basic support for the Qualcomm Camera Control Interface (CCI) controller found on Qualcomm MSM8916/APQ8016 and MSM8996/APQ8996 SoC. CCI has one I2C bus on MSM8916/APQ8016 and two I2C busses on MSM8996/APQ8096. The present driver supports the first I2C bus only. The driver is

[PATCH 0/4] Qualcomm Camera Control Interface driver

This patchset adds basic support for the Qualcomm Camera Control Interface (CCI) controller found on Qualcomm MSM8916/APQ8016 and MSM8996/APQ8996 SoC. CCI has one I2C bus on MSM8916/APQ8016 and two I2C busses on MSM8996/APQ8096. The present driver supports the first I2C bus only. The driver is

Re: Build regressions/improvements in v4.14-rc3

On Mon, Oct 02, 2017 at 11:49:33AM +0200, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v4.14-rc3[1] compared to v4.13[2]. Hi, a question regarding the um-defconfig build: http://kisskb.ellerman.id.au/kisskb/target/2974/ The error thrown

Re: Build regressions/improvements in v4.14-rc3

On Mon, Oct 02, 2017 at 11:49:33AM +0200, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v4.14-rc3[1] compared to v4.13[2]. Hi, a question regarding the um-defconfig build: http://kisskb.ellerman.id.au/kisskb/target/2974/ The error thrown

Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

On Sun, Oct 1, 2017 at 12:57 PM, Tetsuo Handa wrote: >> > I inserted u-SD card, only to realize that it is not detected as it >> > should be. And dmesg indeed reveals: >> >> Tetsuo asked me to report this to linux-mm. >> >> But 2^4 is 16 pages, IIRC that can't

Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

On Sun, Oct 1, 2017 at 12:57 PM, Tetsuo Handa wrote: >> > I inserted u-SD card, only to realize that it is not detected as it >> > should be. And dmesg indeed reveals: >> >> Tetsuo asked me to report this to linux-mm. >> >> But 2^4 is 16 pages, IIRC that can't be expected to work reliably, and

Re: [PATCH] mm,hugetlb,migration: don't migrate kernelcore hugepages

On Mon, Oct 02, 2017 at 02:54:32PM +0200, Michal Hocko wrote: > On Mon 02-10-17 00:51:11, Alexandru Moise wrote: > > This attempts to bring more flexibility to how hugepages are allocated > > by making it possible to decide whether we want the hugepages to be > > allocated from ZONE_MOVABLE or to

Re: [PATCH] mm,hugetlb,migration: don't migrate kernelcore hugepages

On Mon, Oct 02, 2017 at 02:54:32PM +0200, Michal Hocko wrote: > On Mon 02-10-17 00:51:11, Alexandru Moise wrote: > > This attempts to bring more flexibility to how hugepages are allocated > > by making it possible to decide whether we want the hugepages to be > > allocated from ZONE_MOVABLE or to

Re: [PATCH] string.h: work around for increased stack usage

On 10/02/2017 11:40 AM, Arnd Bergmann wrote: > The hardened strlen() function causes rather large stack usage > in at least one file in the kernel when CONFIG_KASAN is enabled: > > drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': >

Re: [PATCH] string.h: work around for increased stack usage

On 10/02/2017 11:40 AM, Arnd Bergmann wrote: > The hardened strlen() function causes rather large stack usage > in at least one file in the kernel when CONFIG_KASAN is enabled: > > drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': >

Re: [PATCH] [DEV] dma mapping : export caller to vmallocinfo

On Mon, Oct 02, 2017 at 03:01:55PM +0200, Matthieu CASTET wrote: > For example on arm64 board, this add info to "user" entries in vmallocinfo > > Before : > [...] > 0xff8008997000 0xff80089d8000 266240 user > [...] > > Afer : > [...] > 0xff8008997000 0xff80089d8000 266240

Re: [PATCH] [DEV] dma mapping : export caller to vmallocinfo

On Mon, Oct 02, 2017 at 03:01:55PM +0200, Matthieu CASTET wrote: > For example on arm64 board, this add info to "user" entries in vmallocinfo > > Before : > [...] > 0xff8008997000 0xff80089d8000 266240 user > [...] > > Afer : > [...] > 0xff8008997000 0xff80089d8000 266240

Re: [v4,2/9] brcmsmac: split up wlc_phy_workarounds_nphy

Arnd Bergmann wrote: > The stack consumption in this driver is still relatively high, with one > remaining warning if the warning level is lowered to 1536 bytes: > > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: > the frame size of 1880 bytes is

Re: [v4,2/9] brcmsmac: split up wlc_phy_workarounds_nphy

Arnd Bergmann wrote: > The stack consumption in this driver is still relatively high, with one > remaining warning if the warning level is lowered to 1536 bytes: > > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: > the frame size of 1880 bytes is larger than 1536

Re: [v4, 1/9] brcmsmac: make some local variables 'static const' to reduce stack size

Arnd Bergmann wrote: > With KASAN and a couple of other patches applied, this driver is one > of the few remaining ones that actually use more than 2048 bytes of > kernel stack: > > broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_gainctrl': >

Re: [v4, 1/9] brcmsmac: make some local variables 'static const' to reduce stack size

Arnd Bergmann wrote: > With KASAN and a couple of other patches applied, this driver is one > of the few remaining ones that actually use more than 2048 bytes of > kernel stack: > > broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_gainctrl': >

Re: [PATCH] kvm/x86: Handle async PF in RCU read-side critical sections

On Mon, Oct 02, 2017 at 02:45:34PM +0200, Paolo Bonzini wrote: > On 30/09/2017 19:15, Paul E. McKenney wrote: > > On Sat, Sep 30, 2017 at 07:41:56AM +0800, Boqun Feng wrote: > >> On Fri, Sep 29, 2017 at 04:43:39PM +, Paul E. McKenney wrote: > >>> Not to be repetitive, but if the schedule() is

Re: [PATCH] kvm/x86: Handle async PF in RCU read-side critical sections

On Mon, Oct 02, 2017 at 02:45:34PM +0200, Paolo Bonzini wrote: > On 30/09/2017 19:15, Paul E. McKenney wrote: > > On Sat, Sep 30, 2017 at 07:41:56AM +0800, Boqun Feng wrote: > >> On Fri, Sep 29, 2017 at 04:43:39PM +, Paul E. McKenney wrote: > >>> Not to be repetitive, but if the schedule() is

Re: [PATCH V7 6/6] SCSI: set block queue at preempt only when SCSI device is put into quiesce

> + /* > + * Simply quiesing SCSI device isn't safe, it is easy > + * to use up requests because all these allocated requests > + * can't be dispatched when device is put in QIUESCE. > + * Then no request can be allocated and we may hang > + * somewhere, such as system

Re: [PATCH V7 6/6] SCSI: set block queue at preempt only when SCSI device is put into quiesce

> + /* > + * Simply quiesing SCSI device isn't safe, it is easy > + * to use up requests because all these allocated requests > + * can't be dispatched when device is put in QIUESCE. > + * Then no request can be allocated and we may hang > + * somewhere, such as system

Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On Mon, Oct 02, 2017 at 08:44:21AM -0500, Tom Lendacky wrote: > I think we're talking about the same thing. You want sev_enabled to > indicate whether you can launch an SEV guest. We would still need an > sev_active variable to distinguish between SME and SEV during kernel > execution when the

Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On Mon, Oct 02, 2017 at 08:44:21AM -0500, Tom Lendacky wrote: > I think we're talking about the same thing. You want sev_enabled to > indicate whether you can launch an SEV guest. We would still need an > sev_active variable to distinguish between SME and SEV during kernel > execution when the

Re: [PATCH V7 5/6] block: support PREEMPT_ONLY

> +void blk_set_preempt_only(struct request_queue *q, bool preempt_only) > +{ > + blk_mq_freeze_queue(q); > + if (preempt_only) > + queue_flag_set_unlocked(QUEUE_FLAG_PREEMPT_ONLY, q); > + else > + queue_flag_clear_unlocked(QUEUE_FLAG_PREEMPT_ONLY, q); > +

Re: [PATCH V7 5/6] block: support PREEMPT_ONLY

> +void blk_set_preempt_only(struct request_queue *q, bool preempt_only) > +{ > + blk_mq_freeze_queue(q); > + if (preempt_only) > + queue_flag_set_unlocked(QUEUE_FLAG_PREEMPT_ONLY, q); > + else > + queue_flag_clear_unlocked(QUEUE_FLAG_PREEMPT_ONLY, q); > +

Re: [PATCH v3 1/6] perf header: Record first sample time and last sample time in perf file header

On 10/2/2017 9:00 PM, Jiri Olsa wrote: > On Mon, Oct 02, 2017 at 08:52:59PM +0800, Jin, Yao wrote: >> >> >> On 10/2/2017 7:50 PM, Jiri Olsa wrote: >>> On Thu, Sep 28, 2017 at 08:45:16PM +0800, Jin Yao wrote: >>> >>> SNIP >>> + return ret; + + return do_write(ff,

Re: [PATCH v3 1/6] perf header: Record first sample time and last sample time in perf file header

On 10/2/2017 9:00 PM, Jiri Olsa wrote: > On Mon, Oct 02, 2017 at 08:52:59PM +0800, Jin, Yao wrote: >> >> >> On 10/2/2017 7:50 PM, Jiri Olsa wrote: >>> On Thu, Sep 28, 2017 at 08:45:16PM +0800, Jin Yao wrote: >>> >>> SNIP >>> + return ret; + + return do_write(ff,

Re: [PATCH] iommu/iova: Don't try to copy anchor nodes

On Mon, Oct 02, 2017 at 11:53:31AM +0100, Robin Murphy wrote: > Anchor nodes are not reserved IOVAs in the way that copy_reserved_iova() > cares about - while the failure from reserve_iova() is benign since the > target domain will already have its own anchor, we still don't want to > be

Re: [PATCH] iommu/iova: Don't try to copy anchor nodes

On Mon, Oct 02, 2017 at 11:53:31AM +0100, Robin Murphy wrote: > Anchor nodes are not reserved IOVAs in the way that copy_reserved_iova() > cares about - while the failure from reserve_iova() is benign since the > target domain will already have its own anchor, we still don't want to > be

Re: [PATCH 05/18] net: use ARRAY_SIZE

Jérémy Lefaure writes: > Using the ARRAY_SIZE macro improves the readability of the code. Also, > it is not always useful to use a variable to store this constant > calculated at compile time. > > Found with Coccinelle with the following semantic patch: > @r depends

Re: [PATCH 05/18] net: use ARRAY_SIZE

Jérémy Lefaure writes: > Using the ARRAY_SIZE macro improves the readability of the code. Also, > it is not always useful to use a variable to store this constant > calculated at compile time. > > Found with Coccinelle with the following semantic patch: > @r depends on (org || report)@ > type T;

[PATCH v2] dt-bindings: fsl-imx-drm: Remove incorrect "@di0" usage

Improve the binding example by removing the '@di0' notation, which fixes the following build warning: Warning (unit_address_vs_reg): Node /display@di0 has a unit name, but no reg property Signed-off-by: Marco Franchi --- Change since v1: -change 'display-di0' to 'disp0'.

[PATCH v2] dt-bindings: fsl-imx-drm: Remove incorrect "@di0" usage

Improve the binding example by removing the '@di0' notation, which fixes the following build warning: Warning (unit_address_vs_reg): Node /display@di0 has a unit name, but no reg property Signed-off-by: Marco Franchi --- Change since v1: -change 'display-di0' to 'disp0'.

Re: [PATCH V7 4/6] block: prepare for passing RQF_PREEMPT to request allocation

As mentioned in the reply to Bart, I'd much rather use BLK_MQ_REQ_* for the sane blk_get_request version (which should have the same prototype as blk_mq_alloc_request) instead of having another flags namespace.

Re: [PATCH V7 4/6] block: prepare for passing RQF_PREEMPT to request allocation

As mentioned in the reply to Bart, I'd much rather use BLK_MQ_REQ_* for the sane blk_get_request version (which should have the same prototype as blk_mq_alloc_request) instead of having another flags namespace.

Re: [PATCH v16 3/5] virtio-balloon: VIRTIO_BALLOON_F_SG

On Mon, Oct 02, 2017 at 12:39:30PM +, Wang, Wei W wrote: > On Monday, October 2, 2017 12:30 PM, Michael S. Tsirkin wrote: > > On Sat, Sep 30, 2017 at 12:05:52PM +0800, Wei Wang wrote: > > > +static int send_balloon_page_sg(struct virtio_balloon *vb, > > > + struct

Re: [PATCH v2 2/2] pid: Remove pidhash

On Mon, 2017-10-02 at 09:35 -0400, Rik van Riel wrote: > On Wed, 2017-09-27 at 17:45 +0200, Oleg Nesterov wrote: > > On 09/27, Gargi Sharma wrote: > > > > > > -#define find_next_offset(map, off) > > > > > > \ > > > - find_next_zero_bit((map)->page,

Re: [PATCH v2 2/2] pid: Remove pidhash

On Mon, 2017-10-02 at 09:35 -0400, Rik van Riel wrote: > On Wed, 2017-09-27 at 17:45 +0200, Oleg Nesterov wrote: > > On 09/27, Gargi Sharma wrote: > > > > > > -#define find_next_offset(map, off) > > > > > > \ > > > - find_next_zero_bit((map)->page,

Re: [PATCH v16 3/5] virtio-balloon: VIRTIO_BALLOON_F_SG

On Mon, Oct 02, 2017 at 12:39:30PM +, Wang, Wei W wrote: > On Monday, October 2, 2017 12:30 PM, Michael S. Tsirkin wrote: > > On Sat, Sep 30, 2017 at 12:05:52PM +0800, Wei Wang wrote: > > > +static int send_balloon_page_sg(struct virtio_balloon *vb, > > > + struct

Re: v4.14-rc2/arm64 misaligned atomic in ip_expire() / skb_clone()

void a userfaultfd bug. The userfaultfd syscall appears in > all of the Syzkaller logs, so there is the chance that this is related, > but as I've not seen any other issues I suspect that's unlikely. > > Thanks, > Mark. > > [1] > https://www.kernel.org/pub/linux/kernel/pe

Re: v4.14-rc2/arm64 misaligned atomic in ip_expire() / skb_clone()

void a userfaultfd bug. The userfaultfd syscall appears in > all of the Syzkaller logs, so there is the chance that this is related, > but as I've not seen any other issues I suspect that's unlikely. > > Thanks, > Mark. > > [1] > https://www.kernel.org/pub/linux/kernel/pe

Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On 10/1/2017 12:16 PM, Borislav Petkov wrote: On Sun, Oct 01, 2017 at 12:00:31PM -0500, Brijesh Singh wrote: When SEV feature is disabled, KVM will not be able to launch any SEV guests.  When SEV support is available, KVM can enable it in a specific VM by setting SEV bit before executing the

Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On 10/1/2017 12:16 PM, Borislav Petkov wrote: On Sun, Oct 01, 2017 at 12:00:31PM -0500, Brijesh Singh wrote: When SEV feature is disabled, KVM will not be able to launch any SEV guests.  When SEV support is available, KVM can enable it in a specific VM by setting SEV bit before executing the

Re: [PATCH v3 10/15] [media] vb2: add 'ordered' property to queues

Hi, On Thu, Sep 07, 2017 at 03:42:21PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan For explicit synchronization (and soon for HAL3/Request API) we need the v4l2-driver to guarantee the ordering in which the buffers were queued by userspace. This is

Re: [PATCH v3 10/15] [media] vb2: add 'ordered' property to queues

Hi, On Thu, Sep 07, 2017 at 03:42:21PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan For explicit synchronization (and soon for HAL3/Request API) we need the v4l2-driver to guarantee the ordering in which the buffers were queued by userspace. This is already true for many drivers, but

Re: [PATCH v3 04/15] [media] vb2: add in-fence support to QBUF

Hi, On Thu, Sep 07, 2017 at 03:42:15PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan Receive in-fence from userspace and add support for waiting on them before queueing the buffer to the driver. Buffers are only queued to the driver once they are ready. A

Re: [PATCH v3 04/15] [media] vb2: add in-fence support to QBUF

Hi, On Thu, Sep 07, 2017 at 03:42:15PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan Receive in-fence from userspace and add support for waiting on them before queueing the buffer to the driver. Buffers are only queued to the driver once they are ready. A buffer is ready when its

Re: [PATCH v3 02/15] [media] vb2: add explicit fence user API

Hi, On Thu, Sep 07, 2017 at 03:42:13PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan Turn the reserved2 field into fence_fd that we will use to send an in-fence to the kernel and return an out-fence from the kernel to userspace. Two new flags were added,

Re: [PATCH v3 02/15] [media] vb2: add explicit fence user API

Hi, On Thu, Sep 07, 2017 at 03:42:13PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan Turn the reserved2 field into fence_fd that we will use to send an in-fence to the kernel and return an out-fence from the kernel to userspace. Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that

Re: [PATCH v3 6/6] perf script: support time percent and multiple time ranges

On 10/2/2017 7:58 PM, Jiri Olsa wrote: > On Thu, Sep 28, 2017 at 08:45:21PM +0800, Jin Yao wrote: > > SNIP > >> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c >> index 9092de0..7fd3063 100644 >> --- a/tools/perf/builtin-script.c >> +++ b/tools/perf/builtin-script.c >>

Re: [PATCH v3 6/6] perf script: support time percent and multiple time ranges

On 10/2/2017 7:58 PM, Jiri Olsa wrote: > On Thu, Sep 28, 2017 at 08:45:21PM +0800, Jin Yao wrote: > > SNIP > >> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c >> index 9092de0..7fd3063 100644 >> --- a/tools/perf/builtin-script.c >> +++ b/tools/perf/builtin-script.c >>

Re: [PATCH v3 00/15] V4L2 Explicit Synchronization support

Hi Gustavo, On Thu, Sep 07, 2017 at 03:42:11PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan Hi, Refer to the documentation on the first patch for the details. The previous iteration is here:

Re: [PATCH v3 00/15] V4L2 Explicit Synchronization support

Hi Gustavo, On Thu, Sep 07, 2017 at 03:42:11PM -0300, Gustavo Padovan wrote: From: Gustavo Padovan Hi, Refer to the documentation on the first patch for the details. The previous iteration is here: https://www.mail-archive.com/linux-media@vger.kernel.org/msg118077.html The 2nd patch

Re: [PATCH v2] kvm/x86: Handle async PF in RCU read-side critical sections

On 01/10/2017 03:31, Boqun Feng wrote: > Sasha Levin reported a WARNING: > > | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 > | rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline] > | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 > |

Re: [PATCH v2] kvm/x86: Handle async PF in RCU read-side critical sections

On 01/10/2017 03:31, Boqun Feng wrote: > Sasha Levin reported a WARNING: > > | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 > | rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline] > | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329 > |

Re: [PATCH V7 3/6] block: pass flags to blk_queue_enter()

On Sat, Sep 30, 2017 at 02:12:11PM +0800, Ming Lei wrote: > We need to pass PREEMPT flags to blk_queue_enter() > for allocating request with RQF_PREEMPT in the > following patch. I don't like having another name space for flags. It seems like we should simply pass ops on, and then map the nowait

Re: [PATCH V7 3/6] block: pass flags to blk_queue_enter()

On Sat, Sep 30, 2017 at 02:12:11PM +0800, Ming Lei wrote: > We need to pass PREEMPT flags to blk_queue_enter() > for allocating request with RQF_PREEMPT in the > following patch. I don't like having another name space for flags. It seems like we should simply pass ops on, and then map the nowait

[PATCH] [media] ov5645: I2C address change

As soon as the sensor is powered on, change the I2C address to the one specified in DT. This allows to use multiple physical sensors connected to the same I2C bus. Signed-off-by: Todor Tomov --- drivers/media/i2c/ov5645.c | 42 ++

[PATCH] [media] ov5645: I2C address change

As soon as the sensor is powered on, change the I2C address to the one specified in DT. This allows to use multiple physical sensors connected to the same I2C bus. Signed-off-by: Todor Tomov --- drivers/media/i2c/ov5645.c | 42 ++ 1 file changed, 42

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

, the > userfaultfd syscall wasn't invoked, so I don't believe that should > matter. > > Thanks, > Mark. > > [1] > https://www.kernel.org/pub/linux/kernel/people/mark/bugs/20171002-skbuff-bug/ > [2] https://lkml.kernel.org/r/20170920180413.26713-1-aarca...@redhat.

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

call wasn't invoked, so I don't believe that should > matter. > > Thanks, > Mark. > > [1] > https://www.kernel.org/pub/linux/kernel/people/mark/bugs/20171002-skbuff-bug/ > [2] https://lkml.kernel.org/r/20170920180413.26713-1-aarca...@redhat.com > > [ cut

Re: [PATCH v2 2/2] pid: Remove pidhash

On Wed, 2017-09-27 at 17:45 +0200, Oleg Nesterov wrote: > On 09/27, Gargi Sharma wrote: > > > > -#define find_next_offset(map, off) > > \ > > - find_next_zero_bit((map)->page, BITS_PER_PAGE, > > off) > > - > > this should go into the previous patch, but

Re: [PATCH v2 2/2] pid: Remove pidhash

On Wed, 2017-09-27 at 17:45 +0200, Oleg Nesterov wrote: > On 09/27, Gargi Sharma wrote: > > > > -#define find_next_offset(map, off) > > \ > > - find_next_zero_bit((map)->page, BITS_PER_PAGE, > > off) > > - > > this should go into the previous patch, but

Re: [PATCH V7 2/6] block: tracking request allocation with q_usage_counter

I think I already gate it to basically the same patch as queued up by Bart, but here again: Reviewed-by: Christoph Hellwig

Re: [PATCH V7 2/6] block: tracking request allocation with q_usage_counter

I think I already gate it to basically the same patch as queued up by Bart, but here again: Reviewed-by: Christoph Hellwig

Re: [PATCH V7 1/6] blk-mq: only run hw queues for blk-mq

Looks fine, Reviewed-by: Christoph Hellwig

Re: [PATCH V7 1/6] blk-mq: only run hw queues for blk-mq

Looks fine, Reviewed-by: Christoph Hellwig

RE: [PATCH v3 8/8] platform/x86: dell-wmi-smbios: clean up wmi descriptor check

> -Original Message- > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > Sent: Monday, October 2, 2017 8:16 AM > To: Limonciello, Mario > Cc: dvh...@infradead.org; LKML ; Platform Driver >

RE: [PATCH v3 8/8] platform/x86: dell-wmi-smbios: clean up wmi descriptor check

> -Original Message- > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > Sent: Monday, October 2, 2017 8:16 AM > To: Limonciello, Mario > Cc: dvh...@infradead.org; LKML ; Platform Driver > ; Andy Lutomirski ; > quasi...@google.com; Pali Rohár > Subject: Re: [PATCH v3 8/8]

Re: [PATCH v2] drivers/ide/pci: Fix legacy IRQ assignment

On 10/02/2017 03:52 AM, Lorenzo Pieralisi wrote: Through struct pci_host_bridge->{map/swizzle}_irq() hooks is now possible to define IRQ mapping functions on a per PCI host bridge basis. Actual IRQ allocation is carried out by the pci_assign_irq() function in pci_device_probe() - to make sure a

Re: [PATCH v2] drivers/ide/pci: Fix legacy IRQ assignment

On 10/02/2017 03:52 AM, Lorenzo Pieralisi wrote: Through struct pci_host_bridge->{map/swizzle}_irq() hooks is now possible to define IRQ mapping functions on a per PCI host bridge basis. Actual IRQ allocation is carried out by the pci_assign_irq() function in pci_device_probe() - to make sure a

Re: [Part2 PATCH v4 01/29] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)

On Mon, Oct 02, 2017 at 06:52:01AM -0500, Brijesh Singh wrote: > Thank you for the patch. One of feedback in RFC patches was to put the > command id and their definitions in amd-memory-encryption.txt hence I > was trying to follow that recommendation. Most of ioctls I have seen in > api.txt are

Re: [Part2 PATCH v4 01/29] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)

On Mon, Oct 02, 2017 at 06:52:01AM -0500, Brijesh Singh wrote: > Thank you for the patch. One of feedback in RFC patches was to put the > command id and their definitions in amd-memory-encryption.txt hence I > was trying to follow that recommendation. Most of ioctls I have seen in > api.txt are

Re: keyboard backlight max_brightness bug on Dell Latitude E6410

On Mon, Oct 2, 2017 at 4:15 PM, Pali Rohár wrote: > On Monday 02 October 2017 13:06:46 mario.limoncie...@dell.com wrote: > Ok! Gabriel, can you provide us your DMI information about your machine? > > They are included in following files: > /sys/class/dmi/id/sys_vendor >

Re: keyboard backlight max_brightness bug on Dell Latitude E6410

On Mon, Oct 2, 2017 at 4:15 PM, Pali Rohár wrote: > On Monday 02 October 2017 13:06:46 mario.limoncie...@dell.com wrote: > Ok! Gabriel, can you provide us your DMI information about your machine? > > They are included in following files: > /sys/class/dmi/id/sys_vendor >

Re: keyboard backlight max_brightness bug on Dell Latitude E6410

On Monday 02 October 2017 13:06:46 mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Pali Rohár [mailto:pali.ro...@gmail.com] > > Sent: Monday, October 2, 2017 6:53 AM > > To: Andy Shevchenko > > Cc: Gabriel M. Elder ;

Re: keyboard backlight max_brightness bug on Dell Latitude E6410

On Monday 02 October 2017 13:06:46 mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Pali Rohár [mailto:pali.ro...@gmail.com] > > Sent: Monday, October 2, 2017 6:53 AM > > To: Andy Shevchenko > > Cc: Gabriel M. Elder ; Gabriele Mazzotta > > ; Limonciello, Mario ; > >

Re: [PATCH v3 8/8] platform/x86: dell-wmi-smbios: clean up wmi descriptor check

On Thu, Sep 28, 2017 at 7:02 AM, Mario Limonciello wrote: > Some cases the wrong type was used for errors and checks can be > done more cleanly. Oops, I forgot about this patch, so, please, disregard my comment WRT to strncmp() use to the other patch. >

Re: [PATCH v3 8/8] platform/x86: dell-wmi-smbios: clean up wmi descriptor check

On Thu, Sep 28, 2017 at 7:02 AM, Mario Limonciello wrote: > Some cases the wrong type was used for errors and checks can be > done more cleanly. Oops, I forgot about this patch, so, please, disregard my comment WRT to strncmp() use to the other patch. > Signed-off-by: Mario Limonciello >

Re: [PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

On Sun, 2017-10-01 at 16:05 +0530, Gargi Sharma wrote: > On Sun, Oct 1, 2017 at 2:45 PM, Christoph Hellwig > wrote: > > > - task_active_pid_ns(current)->last_pid); > > > + task_active_pid_ns(current)->idr.idr_next-1); > > > > I think we want a well

Re: [PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

On Sun, 2017-10-01 at 16:05 +0530, Gargi Sharma wrote: > On Sun, Oct 1, 2017 at 2:45 PM, Christoph Hellwig > wrote: > > > - task_active_pid_ns(current)->last_pid); > > > + task_active_pid_ns(current)->idr.idr_next-1); > > > > I think we want a well documented helper for

Re: [PATCH 05/18] net: use ARRAY_SIZE

On Sun, Oct 1, 2017 at 10:30 PM, Jérémy Lefaure wrote: > Using the ARRAY_SIZE macro improves the readability of the code. Also, > it is not always useful to use a variable to store this constant > calculated at compile time. > > + {_lut_core0_rev0,

Re: [PATCH 05/18] net: use ARRAY_SIZE

On Sun, Oct 1, 2017 at 10:30 PM, Jérémy Lefaure wrote: > Using the ARRAY_SIZE macro improves the readability of the code. Also, > it is not always useful to use a variable to store this constant > calculated at compile time. > > + {_lut_core0_rev0, ARRAY_SIZE(gainctrl_lut_core0_rev0), 26,

RE: keyboard backlight max_brightness bug on Dell Latitude E6410

> -Original Message- > From: Pali Rohár [mailto:pali.ro...@gmail.com] > Sent: Monday, October 2, 2017 6:53 AM > To: Andy Shevchenko > Cc: Gabriel M. Elder ; Gabriele Mazzotta > ; Limonciello, Mario

RE: keyboard backlight max_brightness bug on Dell Latitude E6410

> -Original Message- > From: Pali Rohár [mailto:pali.ro...@gmail.com] > Sent: Monday, October 2, 2017 6:53 AM > To: Andy Shevchenko > Cc: Gabriel M. Elder ; Gabriele Mazzotta > ; Limonciello, Mario ; > Darren Hart ; Andy Shevchenko ; > platform-driver-...@vger.kernel.org;

Re: [PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

On Sun, 2017-10-01 at 02:15 -0700, Christoph Hellwig wrote: > > - task_active_pid_ns(current)->last_pid); > > + task_active_pid_ns(current)->idr.idr_next-1); > > I think we want a well documented helper for this pattern instead > of poking into the internals. > > Also is last

Re: [PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

On Sun, 2017-10-01 at 02:15 -0700, Christoph Hellwig wrote: > > - task_active_pid_ns(current)->last_pid); > > + task_active_pid_ns(current)->idr.idr_next-1); > > I think we want a well documented helper for this pattern instead > of poking into the internals. > > Also is last

Re: [PATCH v2 5/5] thermal: Add Tegra BPMP thermal sensor driver

On 08/30/2017 12:32 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Mon, Aug 21, 2017 at 10:40:44AM +0800, Wei Ni wrote: >> >> >> On Friday, August 11, 2017 10:57 AM, Zhang Rui wrote: >>> On Mon, 2017-07-24 at 19:29 +0300, Mikko Perttunen wrote: On Tegra186, the BPMP

Re: [PATCH v2 5/5] thermal: Add Tegra BPMP thermal sensor driver

On 08/30/2017 12:32 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Mon, Aug 21, 2017 at 10:40:44AM +0800, Wei Ni wrote: >> >> >> On Friday, August 11, 2017 10:57 AM, Zhang Rui wrote: >>> On Mon, 2017-07-24 at 19:29 +0300, Mikko Perttunen wrote: On Tegra186, the BPMP

Re: [PATCH v3 03/14] drm/sun4i: tcon: Add variant callback for TCON output muxing

On Fri, Sep 29, 2017 at 6:19 PM, Maxime Ripard wrote: > On Fri, Sep 29, 2017 at 08:22:55AM +, Chen-Yu Tsai wrote: >> static const struct sun4i_tcon_quirks sun5i_a13_quirks = { >> - .has_unknown_mux = true, >> - .has_channel_1 = true, >> +

Re: [PATCH v3 03/14] drm/sun4i: tcon: Add variant callback for TCON output muxing

On Fri, Sep 29, 2017 at 6:19 PM, Maxime Ripard wrote: > On Fri, Sep 29, 2017 at 08:22:55AM +, Chen-Yu Tsai wrote: >> static const struct sun4i_tcon_quirks sun5i_a13_quirks = { >> - .has_unknown_mux = true, >> - .has_channel_1 = true, >> + .has_unknown_mux= true, >> +

Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

On Mon 2017-10-02 14:06:03, Linus Walleij wrote: > On Mon, Oct 2, 2017 at 10:41 AM, Pavel Machek wrote: > > >> Bounce buffers are being removed from v4.15 > > As Adrian states, this would make any last bugs go away. I would > even consider putting this patch this into fixes if it

Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

On Mon 2017-10-02 14:06:03, Linus Walleij wrote: > On Mon, Oct 2, 2017 at 10:41 AM, Pavel Machek wrote: > > >> Bounce buffers are being removed from v4.15 > > As Adrian states, this would make any last bugs go away. I would > even consider putting this patch this into fixes if it solves the

[PATCH] [DEV] dma mapping : export caller to vmallocinfo

For example on arm64 board, this add info to "user" entries in vmallocinfo Before : [...] 0xff8008997000 0xff80089d8000 266240 user [...] Afer : [...] 0xff8008997000 0xff80089d8000 266240 atomic_pool_init+0x0/0x1d8 user [...] This help to debug mapping issues, and is consistent

[PATCH] [DEV] dma mapping : export caller to vmallocinfo

For example on arm64 board, this add info to "user" entries in vmallocinfo Before : [...] 0xff8008997000 0xff80089d8000 266240 user [...] Afer : [...] 0xff8008997000 0xff80089d8000 266240 atomic_pool_init+0x0/0x1d8 user [...] This help to debug mapping issues, and is consistent

Re: [PATCH] HID: hid-multitouch: forward MSC_TIMESTAMP

On Oct 02 2017 or thereabouts, Jiri Kosina wrote: > On Tue, 22 Aug 2017, Nicolas Boichat wrote: > > > Computes and forwards the device timestamp according to the > > specification. > > > > Many devices use a 16-bit timestamp field, with a resolution > > of 100us, therefore rolling around very

Re: [PATCH] HID: hid-multitouch: forward MSC_TIMESTAMP

On Oct 02 2017 or thereabouts, Jiri Kosina wrote: > On Tue, 22 Aug 2017, Nicolas Boichat wrote: > > > Computes and forwards the device timestamp according to the > > specification. > > > > Many devices use a 16-bit timestamp field, with a resolution > > of 100us, therefore rolling around very

Re: [PATCH v3 1/6] perf header: Record first sample time and last sample time in perf file header

On Mon, Oct 02, 2017 at 08:52:59PM +0800, Jin, Yao wrote: > > > On 10/2/2017 7:50 PM, Jiri Olsa wrote: > > On Thu, Sep 28, 2017 at 08:45:16PM +0800, Jin Yao wrote: > > > > SNIP > > > >> + return ret; > >> + > >> + return do_write(ff, >last_sample_time, > >> +

Re: [PATCH v3 1/6] perf header: Record first sample time and last sample time in perf file header

On Mon, Oct 02, 2017 at 08:52:59PM +0800, Jin, Yao wrote: > > > On 10/2/2017 7:50 PM, Jiri Olsa wrote: > > On Thu, Sep 28, 2017 at 08:45:16PM +0800, Jin Yao wrote: > > > > SNIP > > > >> + return ret; > >> + > >> + return do_write(ff, >last_sample_time, > >> +

Memory Leak in nf_conntrack_in

Hi, I am fuzzing linux 4.13-rc7 and I got a report about a memory leak. Here is the alloc stack: 2017/10/01 02:08:59 BUG: memory leak: unreferenced object 0x880069cf0300 (size 312): comm "syz-executor0", pid 3032, jiffies 4294722144 (age 10.773s) hex dump (first 32 bytes): 01 00 00

Memory Leak in nf_conntrack_in

Hi, I am fuzzing linux 4.13-rc7 and I got a report about a memory leak. Here is the alloc stack: 2017/10/01 02:08:59 BUG: memory leak: unreferenced object 0x880069cf0300 (size 312): comm "syz-executor0", pid 3032, jiffies 4294722144 (age 10.773s) hex dump (first 32 bytes): 01 00 00

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