Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping

On Tue, Aug 30, 2016 at 04:33:12PM +0200, Oleg Nesterov wrote: > > + inode = ramfs_get_inode(sb, NULL, S_IFREG | S_IRUGO | S_IXUGO, 0); > Not sure... I think alloc_anon_inode() makes more sense. Compared to this, you mean? It's going to give you the wrong permissions/i_op/a_ops, and

Re: [PATCH v2 0/2] arm64: dts: rockchip: Support PMU for rk3399 SoCs

Heiko, What do you think of it? Maybe I need re-update these patches on next kernel, and re-test them. On 2016年07月06日 16:05, Caesar Wang wrote: Hello Heiko, Marc & ARM guys When Jay first submitted the rk3399.dtsi upstream he had the PMU node in

Re: [PATCH v4 0/6] Support the rk3399 gmac and pd function

From: Caesar Wang Date: Fri, 2 Sep 2016 01:49:58 +0800 > This patch have the following changes: > > 7edf13e net: stmmac: dwmac-rk: add rk3366 & rk3399 specific data > 26e004e net: stmmac: dwmac-rk: fixes the gmac resume after PD on/off > b216c2f net: stmmac: dwmac-rk: add

Re: [PATCH v4 0/6] Support the rk3399 gmac and pd function

From: Caesar Wang Date: Fri, 2 Sep 2016 01:49:58 +0800 > This patch have the following changes: > > 7edf13e net: stmmac: dwmac-rk: add rk3366 & rk3399 specific data > 26e004e net: stmmac: dwmac-rk: fixes the gmac resume after PD on/off > b216c2f net: stmmac: dwmac-rk: add pd_gmac support for

Re: cmsg newgroup alt.sex.fetish.bool (was Re: [PATCH] arch: all: include: asm: bitops: Use bool instead of int for all bit test functions)

On 09/02/2016 04:33 PM, Chen Gang wrote: > On 9/2/16 04:43, Al Viro wrote: >> > On Tue, Aug 30, 2016 at 05:49:05AM +0800, Chen Gang wrote: >> > >>> >> Could you provide the related proof? >>> >> >>> >> Or shall I try to analyze about it and get proof? >> > >> > Can you show a proof that it

Re: cmsg newgroup alt.sex.fetish.bool (was Re: [PATCH] arch: all: include: asm: bitops: Use bool instead of int for all bit test functions)

On 09/02/2016 04:33 PM, Chen Gang wrote: > On 9/2/16 04:43, Al Viro wrote: >> > On Tue, Aug 30, 2016 at 05:49:05AM +0800, Chen Gang wrote: >> > >>> >> Could you provide the related proof? >>> >> >>> >> Or shall I try to analyze about it and get proof? >> > >> > Can you show a proof that it

Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping

On Mon, Aug 29, 2016 at 02:28:08AM -0700, Andy Lutomirski wrote: > On Thu, Aug 25, 2016 at 8:21 AM, Dmitry Safonov > wrote: > > I added here a new in-kernel fs with ramfs-like options. > > Created vdso file in this fs (yet for testing, only 64-bit vdso). > > Mapped this

Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping

On Mon, Aug 29, 2016 at 02:28:08AM -0700, Andy Lutomirski wrote: > On Thu, Aug 25, 2016 at 8:21 AM, Dmitry Safonov > wrote: > > I added here a new in-kernel fs with ramfs-like options. > > Created vdso file in this fs (yet for testing, only 64-bit vdso). > > Mapped this file to process's mm on

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

On Thu, Aug 25, 2016 at 09:41:33PM +0200, Luis R. Rodriguez wrote: > On Thu, Aug 25, 2016 at 01:05:44PM +0200, Daniel Vetter wrote: > > On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez > > wrote: > > Some users want a fully running gfx stack 2s after power-on. There's > >

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

On Thu, Aug 25, 2016 at 09:41:33PM +0200, Luis R. Rodriguez wrote: > On Thu, Aug 25, 2016 at 01:05:44PM +0200, Daniel Vetter wrote: > > On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez > > wrote: > > Some users want a fully running gfx stack 2s after power-on. There's > > not even enough time

Re: [PATCH v2 0/3] Add Platform MHU mailbox driver for Amlogic GXBB

Hi Jassi, Neil Armstrong writes: > In order to support Mailbox links for the Amlogic GXBB SoC, add a generic > platform MHU driver based on arm_mhu.c. > > This patchset follows a RFC thread along the GXBB SCPI support at : >

Re: [PATCH v2 0/3] Add Platform MHU mailbox driver for Amlogic GXBB

Hi Jassi, Neil Armstrong writes: > In order to support Mailbox links for the Amlogic GXBB SoC, add a generic > platform MHU driver based on arm_mhu.c. > > This patchset follows a RFC thread along the GXBB SCPI support at : >

Re: cmsg newgroup alt.sex.fetish.bool (was Re: [PATCH] arch: all: include: asm: bitops: Use bool instead of int for all bit test functions)

On 9/2/16 04:43, Al Viro wrote: > On Tue, Aug 30, 2016 at 05:49:05AM +0800, Chen Gang wrote: > >> Could you provide the related proof? >> >> Or shall I try to analyze about it and get proof? > > Can you show a proof that it actually improves anything? He who proposes > a patch gets to defend

Re: cmsg newgroup alt.sex.fetish.bool (was Re: [PATCH] arch: all: include: asm: bitops: Use bool instead of int for all bit test functions)

On 9/2/16 04:43, Al Viro wrote: > On Tue, Aug 30, 2016 at 05:49:05AM +0800, Chen Gang wrote: > >> Could you provide the related proof? >> >> Or shall I try to analyze about it and get proof? > > Can you show a proof that it actually improves anything? He who proposes > a patch gets to defend

How does the size field work in IOCTL numbers?

Hi folks, this is more of a general linux question, but since I noticed it while looking perf_events code, I'm ccing perf_events folks in case the answer is perf_events specific (hope that's ok). uapi/linux/perf_event.h has the following: #define PERF_EVENT_IOC_PERIOD _IOW('$', 4, __u64) #define

How does the size field work in IOCTL numbers?

Hi folks, this is more of a general linux question, but since I noticed it while looking perf_events code, I'm ccing perf_events folks in case the answer is perf_events specific (hope that's ok). uapi/linux/perf_event.h has the following: #define PERF_EVENT_IOC_PERIOD _IOW('$', 4, __u64) #define

[PATCH] crypto: mv_cesa: remove NO_IRQ reference

Drivers should not use NO_IRQ, as we are trying to get rid of that. In this case, the call to irq_of_parse_and_map() is both wrong (as it returns '0' on failure, not NO_IRQ) and unnecessary (as platform_get_irq() does the same thing) This removes the call to irq_of_parse_and_map() and checks for

[PATCH] crypto: mv_cesa: remove NO_IRQ reference

Drivers should not use NO_IRQ, as we are trying to get rid of that. In this case, the call to irq_of_parse_and_map() is both wrong (as it returns '0' on failure, not NO_IRQ) and unnecessary (as platform_get_irq() does the same thing) This removes the call to irq_of_parse_and_map() and checks for

[PATCH] dmaengine: ipu: remove bogus NO_IRQ reference

A workaround for a warning introduced a use of the NO_IRQ macro that should have been gone for a long time. It is clear from the code that the value cannot actually be used, but apparently there was a configuration at some point that caused a warning, so instead of just reverting that patch, this

[PATCH] dmaengine: ipu: remove bogus NO_IRQ reference

A workaround for a warning introduced a use of the NO_IRQ macro that should have been gone for a long time. It is clear from the code that the value cannot actually be used, but apparently there was a configuration at some point that caused a warning, so instead of just reverting that patch, this

[PATCH] dmaengine: sirf: fix irq number error check

irq_of_parse_and_map() returns 0 on error, no NO_IRQ, so the failure condition can never be met. This changes the comparison to check for zero instead. Signed-off-by: Arnd Bergmann --- drivers/dma/sirf-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] dmaengine: sirf: fix irq number error check

irq_of_parse_and_map() returns 0 on error, no NO_IRQ, so the failure condition can never be met. This changes the comparison to check for zero instead. Signed-off-by: Arnd Bergmann --- drivers/dma/sirf-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] dmaengine: mxs: remove NO_IRQ check

The mxs_chan->chan_irq variable is guaranteed to never be NO_IRQ, as it gets assigned the result of platform_get_irq() that returns either a valid positive interrupt number, or a negative failure code that leads to the channel not being used. This removes the redundant check, eliminating one more

[PATCH] dmaengine: mxs: remove NO_IRQ check

The mxs_chan->chan_irq variable is guaranteed to never be NO_IRQ, as it gets assigned the result of platform_get_irq() that returns either a valid positive interrupt number, or a negative failure code that leads to the channel not being used. This removes the redundant check, eliminating one more

[PATCH 2/2] hso: Convert printk to pr_

Use a more common logging style Miscellanea: o Add pr_fmt to prefix each output message o Realign arguments Signed-off-by: Joe Perches --- drivers/net/usb/hso.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/net/usb/hso.c

[PATCH 1/2] hso: Use a more common logging style

Macros that end in an underscore are just odd. Add hso_dbg(level, fmt, ...) and use it everwhere instead. Several uses had additional unnecessary newlines as the macro added a newline. Remove the newline from the macro and add newlines to each use as appropriate. Remove now unused D macros.

[PATCH 2/2] hso: Convert printk to pr_

Use a more common logging style Miscellanea: o Add pr_fmt to prefix each output message o Realign arguments Signed-off-by: Joe Perches --- drivers/net/usb/hso.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/net/usb/hso.c

[PATCH 1/2] hso: Use a more common logging style

Macros that end in an underscore are just odd. Add hso_dbg(level, fmt, ...) and use it everwhere instead. Several uses had additional unnecessary newlines as the macro added a newline. Remove the newline from the macro and add newlines to each use as appropriate. Remove now unused D macros.

[PATCH 0/2] hso: neatening

This seems to be the only code in the kernel that uses macro defines with a trailing underscore. Fix that. Joe Perches (2): hso: Use a more common logging style hso: Convert printk to pr_ drivers/net/usb/hso.c | 118 +++--- 1 file changed, 55

[PATCH 0/2] hso: neatening

This seems to be the only code in the kernel that uses macro defines with a trailing underscore. Fix that. Joe Perches (2): hso: Use a more common logging style hso: Convert printk to pr_ drivers/net/usb/hso.c | 118 +++--- 1 file changed, 55

Re: [PATCH] virtio-blk: Generate uevent after attribute available

On Wed, Jun 29, 2016 at 09:24:15AM +0800, Fam Zheng wrote: > On Tue, 06/28 04:45, Christoph Hellwig wrote: > > On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > > > Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that > > > point we haven't created the serial

Re: [PATCH] virtio-blk: Generate uevent after attribute available

On Wed, Jun 29, 2016 at 09:24:15AM +0800, Fam Zheng wrote: > On Tue, 06/28 04:45, Christoph Hellwig wrote: > > On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > > > Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that > > > point we haven't created the serial

Re: screen rotation flipped in 4.8-rc

On Tue, 2016-08-30 at 22:42 +, Pandruvada, Srinivas wrote: > Hi All, > > I observed that using iio-sensor-proxy.service, the auto screen > rotation flipped on my laptop (Normal -> vertical, vertical->normal) > using kernel v4.8. > > Anyone else has seen this? > > I did a bisect and found a

Re: screen rotation flipped in 4.8-rc

On Tue, 2016-08-30 at 22:42 +, Pandruvada, Srinivas wrote: > Hi All, > > I observed that using iio-sensor-proxy.service, the auto screen > rotation flipped on my laptop (Normal -> vertical, vertical->normal) > using kernel v4.8. > > Anyone else has seen this? > > I did a bisect and found a

Re: [PATCH] tpm: move struct tpm_class_ops to drivers/char/tpm/tpm.h

On Sat, Sep 03, 2016 at 01:35:22AM +0300, Jarkko Sakkinen wrote: > On Fri, Sep 02, 2016 at 04:11:22PM -0600, Jason Gunthorpe wrote: > > On Sat, Sep 03, 2016 at 12:48:03AM +0300, Jarkko Sakkinen wrote: > > > The struct tpm_class_ops is not used outside the TPM driver. Thus, > > > it can be safely

Re: [PATCH] tpm: move struct tpm_class_ops to drivers/char/tpm/tpm.h

On Sat, Sep 03, 2016 at 01:35:22AM +0300, Jarkko Sakkinen wrote: > On Fri, Sep 02, 2016 at 04:11:22PM -0600, Jason Gunthorpe wrote: > > On Sat, Sep 03, 2016 at 12:48:03AM +0300, Jarkko Sakkinen wrote: > > > The struct tpm_class_ops is not used outside the TPM driver. Thus, > > > it can be safely

Re: [PATCH] doc: ioctl: Add some clarifications to botching-up-ioctls

On Friday, September 2, 2016 3:42:24 PM CEST Laura Abbott wrote: > - The guide currently says to pad the structure to a multiple of > 64-bits. This is not necessary in cases where the structure contains > no 64-bit types. Clarify this concept to avoid unnecessary padding. > - When using __u64

Re: [PATCH] doc: ioctl: Add some clarifications to botching-up-ioctls

On Friday, September 2, 2016 3:42:24 PM CEST Laura Abbott wrote: > - The guide currently says to pad the structure to a multiple of > 64-bits. This is not necessary in cases where the structure contains > no 64-bit types. Clarify this concept to avoid unnecessary padding. > - When using __u64

[PATCH] doc: ioctl: Add some clarifications to botching-up-ioctls

- The guide currently says to pad the structure to a multiple of 64-bits. This is not necessary in cases where the structure contains no 64-bit types. Clarify this concept to avoid unnecessary padding. - When using __u64 to hold user pointers, blindly trying to do a cast to a void __user *

[PATCH] doc: ioctl: Add some clarifications to botching-up-ioctls

- The guide currently says to pad the structure to a multiple of 64-bits. This is not necessary in cases where the structure contains no 64-bit types. Clarify this concept to avoid unnecessary padding. - When using __u64 to hold user pointers, blindly trying to do a cast to a void __user *

Re: [PATCH] tpm: move struct tpm_class_ops to drivers/char/tpm/tpm.h

On Fri, Sep 02, 2016 at 04:11:22PM -0600, Jason Gunthorpe wrote: > On Sat, Sep 03, 2016 at 12:48:03AM +0300, Jarkko Sakkinen wrote: > > The struct tpm_class_ops is not used outside the TPM driver. Thus, > > it can be safely move to drivers/char/tpm/tpm.h. > > No, this is the wrong direction. > >

Re: [PATCH] tpm: move struct tpm_class_ops to drivers/char/tpm/tpm.h

On Fri, Sep 02, 2016 at 04:11:22PM -0600, Jason Gunthorpe wrote: > On Sat, Sep 03, 2016 at 12:48:03AM +0300, Jarkko Sakkinen wrote: > > The struct tpm_class_ops is not used outside the TPM driver. Thus, > > it can be safely move to drivers/char/tpm/tpm.h. > > No, this is the wrong direction. > >

[GIT PULL] TPM bugfix

Please pull this fix for the TPM code. The following changes since commit 15301a570754c7af60335d094dd2d1808b0641a5: x86/paravirt: Do not trace _paravirt_ident_*() functions (2016-09-02 09:40:47 -0700) are available in the git repository at:

[GIT PULL] TPM bugfix

Please pull this fix for the TPM code. The following changes since commit 15301a570754c7af60335d094dd2d1808b0641a5: x86/paravirt: Do not trace _paravirt_ident_*() functions (2016-09-02 09:40:47 -0700) are available in the git repository at:

[RESEND PATCH] Fix sysrq emergency thaw

"SYSRQ + J" triggers a call to emergency_thaw_all(). Currently, this is an infinite loop. Once we trigger it, we'll need to do a hard power-cycle. There are users reporting this bug from 2012 to 2016, for example, at https://bugzilla.kernel.org/show_bug.cgi?id=47741. This happens because

[RESEND PATCH] Fix sysrq emergency thaw

"SYSRQ + J" triggers a call to emergency_thaw_all(). Currently, this is an infinite loop. Once we trigger it, we'll need to do a hard power-cycle. There are users reporting this bug from 2012 to 2016, for example, at https://bugzilla.kernel.org/show_bug.cgi?id=47741. This happens because

Re: [PATCH v2 3/3] nvme: Enable autonomous power state transitions

On Fri, 2016-09-02 at 14:43 -0700, Andy Lutomirski wrote: > On Fri, Sep 2, 2016 at 2:15 PM, J Freyensee > wrote: > > > > On Tue, 2016-08-30 at 14:59 -0700, Andy Lutomirski wrote: > > > > > > NVME devices can advertise multiple power states.  These states > > >

Re: [PATCH v2 3/3] nvme: Enable autonomous power state transitions

On Fri, 2016-09-02 at 14:43 -0700, Andy Lutomirski wrote: > On Fri, Sep 2, 2016 at 2:15 PM, J Freyensee > wrote: > > > > On Tue, 2016-08-30 at 14:59 -0700, Andy Lutomirski wrote: > > > > > > NVME devices can advertise multiple power states.  These states > > > can > > > be either "operational"

Re: Memory barrier needed with wake_up_process()?

On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote: > Felipe, your tests will show whether my guess was totally off-base. > For the new people, Felipe is tracking down a problem that involves > exactly the code sequence listed at the top of the email, where we know > that the wakeup

Re: Memory barrier needed with wake_up_process()?

On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote: > Felipe, your tests will show whether my guess was totally off-base. > For the new people, Felipe is tracking down a problem that involves > exactly the code sequence listed at the top of the email, where we know > that the wakeup

Re: Memory barrier needed with wake_up_process()?

On Sat, Sep 03, 2016 at 12:14:13AM +0200, Peter Zijlstra wrote: > On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote: > > > > Actually, that's not entirely true (although presumably it works okay > > for most architectures). > > Yeah, all load-store archs (with exception of PowerPC and

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Fri, Sep 2, 2016 at 5:43 AM, Arnd Bergmann wrote: > On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote: >> >> Hi Felipe and Arnd, >> >> It has been a while since the last response to this discussion, but we >> haven't reached an agreement yet! Can we get to a

Re: Memory barrier needed with wake_up_process()?

On Sat, Sep 03, 2016 at 12:14:13AM +0200, Peter Zijlstra wrote: > On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote: > > > > Actually, that's not entirely true (although presumably it works okay > > for most architectures). > > Yeah, all load-store archs (with exception of PowerPC and

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Fri, Sep 2, 2016 at 5:43 AM, Arnd Bergmann wrote: > On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote: >> >> Hi Felipe and Arnd, >> >> It has been a while since the last response to this discussion, but we >> haven't reached an agreement yet! Can we get to a conclusion on if it >>

Re: [PATCH v2 01/15] Remove unused symbols, unnecessary parens, other minor comments from

On Fri, Sep 02, 2016 at 02:42:56PM -0700, Guenter Roeck wrote: > On Fri, Sep 02, 2016 at 10:53:58AM -0500, Bjorn Helgaas wrote: > > Guenter. > > Kind of an odd patch description ;-) Yeah :) These are just things you commented on initially. I'm going to squash all these and throw away these

Re: [PATCH v2 01/15] Remove unused symbols, unnecessary parens, other minor comments from

On Fri, Sep 02, 2016 at 02:42:56PM -0700, Guenter Roeck wrote: > On Fri, Sep 02, 2016 at 10:53:58AM -0500, Bjorn Helgaas wrote: > > Guenter. > > Kind of an odd patch description ;-) Yeah :) These are just things you commented on initially. I'm going to squash all these and throw away these

Re: Memory barrier needed with wake_up_process()?

On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote: > > Actually, that's not entirely true (although presumably it works okay > for most architectures). Yeah, all load-store archs (with exception of PowerPC and ARM64 and possibly MIPS) implement ACQUIRE with a general fence (after the

Re: Memory barrier needed with wake_up_process()?

On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote: > > Actually, that's not entirely true (although presumably it works okay > for most architectures). Yeah, all load-store archs (with exception of PowerPC and ARM64 and possibly MIPS) implement ACQUIRE with a general fence (after the

Re: [Linaro-mm-sig] [PATCHv2 3/4] staging: android: ion: Add an ioctl for ABI checking

On 09/02/2016 02:33 PM, Arnd Bergmann wrote: On Friday, September 2, 2016 1:33:44 PM CEST Laura Abbott wrote: On 09/02/2016 02:02 AM, Arnd Bergmann wrote: On Thursday, September 1, 2016 3:40:43 PM CEST Laura Abbott wrote: --- a/drivers/staging/android/ion/ion-ioctl.c +++

Re: [Linaro-mm-sig] [PATCHv2 3/4] staging: android: ion: Add an ioctl for ABI checking

On 09/02/2016 02:33 PM, Arnd Bergmann wrote: On Friday, September 2, 2016 1:33:44 PM CEST Laura Abbott wrote: On 09/02/2016 02:02 AM, Arnd Bergmann wrote: On Thursday, September 1, 2016 3:40:43 PM CEST Laura Abbott wrote: --- a/drivers/staging/android/ion/ion-ioctl.c +++

Re: [PATCH] tpm: move struct tpm_class_ops to drivers/char/tpm/tpm.h

On Sat, Sep 03, 2016 at 12:48:03AM +0300, Jarkko Sakkinen wrote: > The struct tpm_class_ops is not used outside the TPM driver. Thus, > it can be safely move to drivers/char/tpm/tpm.h. No, this is the wrong direction. The goal is to make things more like other subsystems, so we should be moving

Re: [PATCH v3] power: bq24735-charger: Request status GPIO with initial input setup

Hi, Le vendredi 02 septembre 2016 à 17:27 +0200, Sebastian Reichel a écrit : > Hi Paul, > > This looks mostly fine now. I have a few more comments, that I > missed last time: Thanks for the review and for the useful suggestions. I have applied them to v4. > On Thu, Sep 01, 2016 at 11:27:00PM

Re: [PATCH] tpm: move struct tpm_class_ops to drivers/char/tpm/tpm.h

On Sat, Sep 03, 2016 at 12:48:03AM +0300, Jarkko Sakkinen wrote: > The struct tpm_class_ops is not used outside the TPM driver. Thus, > it can be safely move to drivers/char/tpm/tpm.h. No, this is the wrong direction. The goal is to make things more like other subsystems, so we should be moving

Re: [PATCH v3] power: bq24735-charger: Request status GPIO with initial input setup

Hi, Le vendredi 02 septembre 2016 à 17:27 +0200, Sebastian Reichel a écrit : > Hi Paul, > > This looks mostly fine now. I have a few more comments, that I > missed last time: Thanks for the review and for the useful suggestions. I have applied them to v4. > On Thu, Sep 01, 2016 at 11:27:00PM

[PATCH v4] power: bq24735-charger: Request status GPIO with initial input setup

This requests the status GPIO with initial input setup. it is required to read the GPIO status at probe time and thus correctly avoid sending i2c messages when AC is not plugged. When requesting the GPIO without initial input setup, it always reads 0 which causes probe to fail as it assumes the

[PATCH v4] power: bq24735-charger: Request status GPIO with initial input setup

This requests the status GPIO with initial input setup. it is required to read the GPIO status at probe time and thus correctly avoid sending i2c messages when AC is not plugged. When requesting the GPIO without initial input setup, it always reads 0 which causes probe to fail as it assumes the

Re: [PATCH v2 07/15] Simplify the confusing HIWORD_UPDATE scheme.

On Fri, Sep 02, 2016 at 02:38:06PM -0700, Guenter Roeck wrote: > On Fri, Sep 02, 2016 at 10:54:53AM -0500, Bjorn Helgaas wrote: > > +#define HIWORD_UPDATE(mask, val) ((mask << 16) | val) > > + > > +#define ENCODE_LANES(x)(((x >> 1) & 3) << 4) > > (x) ? Done, thanks! (And

Re: [PATCH v2 07/15] Simplify the confusing HIWORD_UPDATE scheme.

On Fri, Sep 02, 2016 at 02:38:06PM -0700, Guenter Roeck wrote: > On Fri, Sep 02, 2016 at 10:54:53AM -0500, Bjorn Helgaas wrote: > > +#define HIWORD_UPDATE(mask, val) ((mask << 16) | val) > > + > > +#define ENCODE_LANES(x)(((x >> 1) & 3) << 4) > > (x) ? Done, thanks! (And

[tip:timers/core 6/6] alarmtimer.c:undefined reference to `rtc_ktime_to_tm'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core head: a0a6e06d545a753740c9d8d5ce2c4fdd3ab1c021 commit: a0a6e06d545a753740c9d8d5ce2c4fdd3ab1c021 [6/6] time: alarmtimer: Add tracepoints for alarmtimers config: s390-allyesconfig (attached as .config) compiler:

[tip:timers/core 6/6] alarmtimer.c:undefined reference to `rtc_ktime_to_tm'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core head: a0a6e06d545a753740c9d8d5ce2c4fdd3ab1c021 commit: a0a6e06d545a753740c9d8d5ce2c4fdd3ab1c021 [6/6] time: alarmtimer: Add tracepoints for alarmtimers config: s390-allyesconfig (attached as .config) compiler:

[PATCH] ARM: fix linker call for ARM_MODULE_PLTS

module.lds script doesn't get called when CONFIG_ARM_MODULE_PLTS is enabled. Use KBUILD_LDFLAGS_MODULE to fix it. Signed-off-by: Wladislav Wiebe --- arch/arm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Makefile

[PATCH] ARM: fix linker call for ARM_MODULE_PLTS

module.lds script doesn't get called when CONFIG_ARM_MODULE_PLTS is enabled. Use KBUILD_LDFLAGS_MODULE to fix it. Signed-off-by: Wladislav Wiebe --- arch/arm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 61f6ccc..01c6025

Re: [Linaro-mm-sig] [PATCHv2 4/4] staging: android: ion: Add ioctl to query available heaps

On 09/02/2016 02:37 PM, Arnd Bergmann wrote: On Friday, September 2, 2016 2:27:21 PM CEST Laura Abbott wrote: All warnings (new ones prefixed by >>): drivers/staging/android/ion/ion.c: In function 'ion_query_heaps': drivers/staging/android/ion/ion.c:1181:3: warning: cast to pointer from

Re: [Linaro-mm-sig] [PATCHv2 4/4] staging: android: ion: Add ioctl to query available heaps

On 09/02/2016 02:37 PM, Arnd Bergmann wrote: On Friday, September 2, 2016 2:27:21 PM CEST Laura Abbott wrote: All warnings (new ones prefixed by >>): drivers/staging/android/ion/ion.c: In function 'ion_query_heaps': drivers/staging/android/ion/ion.c:1181:3: warning: cast to pointer from

Re: [PATCH v3] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

Since this patch has been on hold for a little bit, I did a bit of thinking of how we could this a little more cleanly. Unfortunately I couldn't think of a way, however I did think of an alternative solution: I'm planning on backporting all of the skl wm fixes already, so I'm going to use this

Re: [PATCH v3] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

Since this patch has been on hold for a little bit, I did a bit of thinking of how we could this a little more cleanly. Unfortunately I couldn't think of a way, however I did think of an alternative solution: I'm planning on backporting all of the skl wm fixes already, so I'm going to use this

[PATCH] tpm: move struct tpm_class_ops to drivers/char/tpm/tpm.h

The struct tpm_class_ops is not used outside the TPM driver. Thus, it can be safely move to drivers/char/tpm/tpm.h. Signed-off-by: Jarkko Sakkinen --- drivers/char/tpm/tpm.h | 13 + include/linux/tpm.h| 14 -- 2 files changed, 13

[PATCH] tpm: move struct tpm_class_ops to drivers/char/tpm/tpm.h

The struct tpm_class_ops is not used outside the TPM driver. Thus, it can be safely move to drivers/char/tpm/tpm.h. Signed-off-by: Jarkko Sakkinen --- drivers/char/tpm/tpm.h | 13 + include/linux/tpm.h| 14 -- 2 files changed, 13 insertions(+), 14 deletions(-) diff

Re: [PATCH] dt-binding: remoteproc: Document generic properties

On 08/12/2016 05:42 PM, Bjorn Andersson wrote: > On Fri 12 Aug 11:34 PDT 2016, Rob Herring wrote: > >> On Wed, Aug 10, 2016 at 10:37:02AM -0700, Bjorn Andersson wrote: >>> This documents the generic properties "rprocs" and "rproc-names", used >>> for consumer drivers to reference a remoteproc

Re: [PATCH] dt-binding: remoteproc: Document generic properties

On 08/12/2016 05:42 PM, Bjorn Andersson wrote: > On Fri 12 Aug 11:34 PDT 2016, Rob Herring wrote: > >> On Wed, Aug 10, 2016 at 10:37:02AM -0700, Bjorn Andersson wrote: >>> This documents the generic properties "rprocs" and "rproc-names", used >>> for consumer drivers to reference a remoteproc

[GIT PULL] ACPI fixes for v4.8-rc5

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.8-rc5 to receive ACPI fixes for v4.8-rc5. The top-most commit is 5331d9cab32ef640b4cd38a43b0858874fbb7168 ACPI / drivers: replace acpi_probe_lock spinlock with mutex and the base

Re: [PATCH v2 3/3] nvme: Enable autonomous power state transitions

On Fri, Sep 2, 2016 at 2:15 PM, J Freyensee wrote: > On Tue, 2016-08-30 at 14:59 -0700, Andy Lutomirski wrote: >> NVME devices can advertise multiple power states. These states can >> be either "operational" (the device is fully functional but possibly >> slow)

[GIT PULL] ACPI fixes for v4.8-rc5

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.8-rc5 to receive ACPI fixes for v4.8-rc5. The top-most commit is 5331d9cab32ef640b4cd38a43b0858874fbb7168 ACPI / drivers: replace acpi_probe_lock spinlock with mutex and the base

Re: [PATCH v2 3/3] nvme: Enable autonomous power state transitions

On Fri, Sep 2, 2016 at 2:15 PM, J Freyensee wrote: > On Tue, 2016-08-30 at 14:59 -0700, Andy Lutomirski wrote: >> NVME devices can advertise multiple power states. These states can >> be either "operational" (the device is fully functional but possibly >> slow) or "non-operational" (the device

Re: [PATCH v2 01/15] Remove unused symbols, unnecessary parens, other minor comments from

On Fri, Sep 02, 2016 at 10:53:58AM -0500, Bjorn Helgaas wrote: > Guenter. Kind of an odd patch description ;-) Guenter > --- > drivers/pci/host/pcie-rockchip.c | 69 > -- > 1 file changed, 21 insertions(+), 48 deletions(-) > > diff --git

[GIT PULL] Power management fixes for v4.8-rc5

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.8-rc5 to receive power management fixes for v4.8-rc5. The top-most commit is b654c62e7734cdcd507a5751cd940077be2ad373 Merge branches 'pm-cpufreq-fixes' and 'pm-core-fixes' and the

Re: [PATCH v2 01/15] Remove unused symbols, unnecessary parens, other minor comments from

On Fri, Sep 02, 2016 at 10:53:58AM -0500, Bjorn Helgaas wrote: > Guenter. Kind of an odd patch description ;-) Guenter > --- > drivers/pci/host/pcie-rockchip.c | 69 > -- > 1 file changed, 21 insertions(+), 48 deletions(-) > > diff --git

[GIT PULL] Power management fixes for v4.8-rc5

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.8-rc5 to receive power management fixes for v4.8-rc5. The top-most commit is b654c62e7734cdcd507a5751cd940077be2ad373 Merge branches 'pm-cpufreq-fixes' and 'pm-core-fixes' and the

[PATCH] dmaengine: moxart: remove NO_IRQ

The use of NO_IRQ is incorrect here and should never have been there, as irq_of_parse_and_map() returns '0' on failure, not NO_IRQ. Signed-off-by: Arnd Bergmann --- drivers/dma/moxart-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] dmaengine: moxart: remove NO_IRQ

The use of NO_IRQ is incorrect here and should never have been there, as irq_of_parse_and_map() returns '0' on failure, not NO_IRQ. Signed-off-by: Arnd Bergmann --- drivers/dma/moxart-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/moxart-dma.c

Re: [PATCH v2 10/15] Group related CSR definitions together.

On Fri, Sep 02, 2016 at 10:55:19AM -0500, Bjorn Helgaas wrote: > > --- > drivers/pci/host/pcie-rockchip.c | 148 > +++--- > 1 file changed, 74 insertions(+), 74 deletions(-) > > diff --git a/drivers/pci/host/pcie-rockchip.c > b/drivers/pci/host/pcie-rockchip.c

Re: [PATCH v2 10/15] Group related CSR definitions together.

On Fri, Sep 02, 2016 at 10:55:19AM -0500, Bjorn Helgaas wrote: > > --- > drivers/pci/host/pcie-rockchip.c | 148 > +++--- > 1 file changed, 74 insertions(+), 74 deletions(-) > > diff --git a/drivers/pci/host/pcie-rockchip.c > b/drivers/pci/host/pcie-rockchip.c

Re: [PATCH v2 07/15] Simplify the confusing HIWORD_UPDATE scheme.

On Fri, Sep 02, 2016 at 10:54:53AM -0500, Bjorn Helgaas wrote: > > --- > drivers/pci/host/pcie-rockchip.c | 70 > +- > 1 file changed, 24 insertions(+), 46 deletions(-) > > diff --git a/drivers/pci/host/pcie-rockchip.c > b/drivers/pci/host/pcie-rockchip.c

Re: [PATCH v2 07/15] Simplify the confusing HIWORD_UPDATE scheme.

On Fri, Sep 02, 2016 at 10:54:53AM -0500, Bjorn Helgaas wrote: > > --- > drivers/pci/host/pcie-rockchip.c | 70 > +- > 1 file changed, 24 insertions(+), 46 deletions(-) > > diff --git a/drivers/pci/host/pcie-rockchip.c > b/drivers/pci/host/pcie-rockchip.c

Re: [Linaro-mm-sig] [PATCHv2 4/4] staging: android: ion: Add ioctl to query available heaps

On Friday, September 2, 2016 2:27:21 PM CEST Laura Abbott wrote: > > > > All warnings (new ones prefixed by >>): > > > >drivers/staging/android/ion/ion.c: In function 'ion_query_heaps': > >>> drivers/staging/android/ion/ion.c:1181:3: warning: cast to pointer from > >>> integer of different

Re: [Linaro-mm-sig] [PATCHv2 4/4] staging: android: ion: Add ioctl to query available heaps

On Friday, September 2, 2016 2:27:21 PM CEST Laura Abbott wrote: > > > > All warnings (new ones prefixed by >>): > > > >drivers/staging/android/ion/ion.c: In function 'ion_query_heaps': > >>> drivers/staging/android/ion/ion.c:1181:3: warning: cast to pointer from > >>> integer of different

Re: [Linaro-mm-sig] [PATCHv2 3/4] staging: android: ion: Add an ioctl for ABI checking

On Friday, September 2, 2016 1:33:44 PM CEST Laura Abbott wrote: > On 09/02/2016 02:02 AM, Arnd Bergmann wrote: > > On Thursday, September 1, 2016 3:40:43 PM CEST Laura Abbott wrote: > > > >> --- a/drivers/staging/android/ion/ion-ioctl.c > >> +++ b/drivers/staging/android/ion/ion-ioctl.c > >> @@

Re: [Linaro-mm-sig] [PATCHv2 3/4] staging: android: ion: Add an ioctl for ABI checking

On Friday, September 2, 2016 1:33:44 PM CEST Laura Abbott wrote: > On 09/02/2016 02:02 AM, Arnd Bergmann wrote: > > On Thursday, September 1, 2016 3:40:43 PM CEST Laura Abbott wrote: > > > >> --- a/drivers/staging/android/ion/ion-ioctl.c > >> +++ b/drivers/staging/android/ion/ion-ioctl.c > >> @@

Re: [PATCHv2 4/4] staging: android: ion: Add ioctl to query available heaps

ion-Drop-heap-type-masks/20160902-071022 config: mips-allyesconfig (attached as .config) compiler: mips-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/

Re: [PATCHv2 4/4] staging: android: ion: Add ioctl to query available heaps

ion-Drop-heap-type-masks/20160902-071022 config: mips-allyesconfig (attached as .config) compiler: mips-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/

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