date:20160916

Re: [PATHC v2 0/9] ima: carry the measurement list across kexec

2016-09-16 Thread Eric W. Biederman

Thiago Jung Bauermann  writes:

> Hello Eric,
>
> Am Freitag, 16 September 2016, 14:47:13 schrieb Eric W. Biederman:
>> Mimi Zohar  writes:
>> > Hi Andrew,
>> > 
>> > On Wed, 2016-08-31 at 18:38 -0400, Mimi Zohar wrote:
>> >> On Wed, 2016-08-31 at 13:50 -0700, Andrew Morton wrote:
>> >> > On Tue, 30 Aug 2016 18:40:02 -0400 Mimi Zohar 
>  wrote:
>> >> > > The TPM PCRs are only reset on a hard reboot.  In order to validate
>> >> > > a
>> >> > > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement
>> >> > > list
>> >> > > of the running kernel must be saved and then restored on the
>> >> > > subsequent
>> >> > > boot, possibly of a different architecture.
>> >> > > 
>> >> > > The existing securityfs binary_runtime_measurements file
>> >> > > conveniently
>> >> > > provides a serialized format of the IMA measurement list. This
>> >> > > patch
>> >> > > set serializes the measurement list in this format and restores it.
>> >> > > 
>> >> > > Up to now, the binary_runtime_measurements was defined as
>> >> > > architecture
>> >> > > native format.  The assumption being that userspace could and would
>> >> > > handle any architecture conversions.  With the ability of carrying
>> >> > > the
>> >> > > measurement list across kexec, possibly from one architecture to a
>> >> > > different one, the per boot architecture information is lost and
>> >> > > with it
>> >> > > the ability of recalculating the template digest hash.  To resolve
>> >> > > this
>> >> > > problem, without breaking the existing ABI, this patch set
>> >> > > introduces
>> >> > > the boot command line option "ima_canonical_fmt", which is
>> >> > > arbitrarily
>> >> > > defined as little endian.
>> >> > > 
>> >> > > The need for this boot command line option will be limited to the
>> >> > > existing version 1 format of the binary_runtime_measurements.
>> >> > > Subsequent formats will be defined as canonical format (eg. TPM 2.0
>> >> > > support for larger digests).
>> >> > > 
>> >> > > This patch set pre-req's Thiago Bauermann's "kexec_file: Add buffer
>> >> > > hand-over for the next kernel" patch set.
>> >> > > 
>> >> > > These patches can also be found in the next-kexec-restore branch
>> >> > > of:
>> >> > > git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity
>> >> > > .git
>> >> > 
>> >> > I'll merge these into -mm to get some linux-next exposure.  I don't
>> >> > know what your upstream merge plans will be?
>> >> 
>> >> Sounds good.  I'm hoping to get some review/comments on this patch set
>> >> as well.  At the moment, I'm chasing down a kernel test robot report
>> >> from this afternoon.
>> > 
>> > My concern about changing the canonical format as originally defined in
>> > patch 9/9 from big endian to little endian never materialized.  Andreas
>> > Steffan, the patch author, is happy either way.
>> > 
>> > We proposed two methods of addressing Eric Biederman's concerns of not
>> > including the IMA measurement list segment in the kexec hash as
>> > described in  https://lkml.org/lkml/2016/9/9/355.
>> > 
>> > - defer calculating and verifying the serialized IMA measurement list
>> > buffer hash to IMA
>> > - calculate the kexec hash on load, verify it on the kexec execute,
>> > before re-calculating and updating it.
>> 
>> I need to ask: How this is anticipated to interact with kexec on panic?
>> Because honestly I can't see this ever working in that case.  The
>> assumption is that the original kernel has gone crazy.  So from a
>> practical standpoint any trusted path should have been invalided.
>
> We are not interested in carrying the measurement list in the case of kexec 
> on panic. I see that the code is adding a hand-over buffer to the crash 
> image as well, but that is a bug.
>
> The fix is to do nothing in ima_add_kexec_buffer if image->type != 
> KEXEC_TYPE_DEFAULT.
>  
>> This entire idea of updating the kexec image makes me extremely
>> extremely nervious.  It feels like sticking a screw driver through the
>> spokes of your bicicle tires while ridding down the road.
>> 
>> I can see tracking to see if the list has changed at some
>> point and causing a reboot(LINUX_REBOOT_CMD_KEXEC) to fail.
>
> Yes, that is an interesting feature that I can add using the checksum-
> verifying part of my code. I can submit a patch for that if there's 
> interest, adding a reboot notifier that verifies the checksum and causes a 
> regular reboot instead of a kexec reboot if the checksum fails.

I was thinking an early failure instead of getting all of the way down
into a kernel an discovering the tpm/ima subsystem would not
initialized.  But where that falls in the reboot pathway I don't expect
there is much value in it.

>> At least the common bootloader cases that I know of using kexec are very
>> minimal distributions that live in a ramdisk and as such it should be
>> very straight forward to measure what is needed at or before
>>

Re: [PATHC v2 0/9] ima: carry the measurement list across kexec

2016-09-16 Thread Eric W. Biederman

Thiago Jung Bauermann  writes:

> Hello Eric,
>
> Am Freitag, 16 September 2016, 14:47:13 schrieb Eric W. Biederman:
>> Mimi Zohar  writes:
>> > Hi Andrew,
>> > 
>> > On Wed, 2016-08-31 at 18:38 -0400, Mimi Zohar wrote:
>> >> On Wed, 2016-08-31 at 13:50 -0700, Andrew Morton wrote:
>> >> > On Tue, 30 Aug 2016 18:40:02 -0400 Mimi Zohar 
>  wrote:
>> >> > > The TPM PCRs are only reset on a hard reboot.  In order to validate
>> >> > > a
>> >> > > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement
>> >> > > list
>> >> > > of the running kernel must be saved and then restored on the
>> >> > > subsequent
>> >> > > boot, possibly of a different architecture.
>> >> > > 
>> >> > > The existing securityfs binary_runtime_measurements file
>> >> > > conveniently
>> >> > > provides a serialized format of the IMA measurement list. This
>> >> > > patch
>> >> > > set serializes the measurement list in this format and restores it.
>> >> > > 
>> >> > > Up to now, the binary_runtime_measurements was defined as
>> >> > > architecture
>> >> > > native format.  The assumption being that userspace could and would
>> >> > > handle any architecture conversions.  With the ability of carrying
>> >> > > the
>> >> > > measurement list across kexec, possibly from one architecture to a
>> >> > > different one, the per boot architecture information is lost and
>> >> > > with it
>> >> > > the ability of recalculating the template digest hash.  To resolve
>> >> > > this
>> >> > > problem, without breaking the existing ABI, this patch set
>> >> > > introduces
>> >> > > the boot command line option "ima_canonical_fmt", which is
>> >> > > arbitrarily
>> >> > > defined as little endian.
>> >> > > 
>> >> > > The need for this boot command line option will be limited to the
>> >> > > existing version 1 format of the binary_runtime_measurements.
>> >> > > Subsequent formats will be defined as canonical format (eg. TPM 2.0
>> >> > > support for larger digests).
>> >> > > 
>> >> > > This patch set pre-req's Thiago Bauermann's "kexec_file: Add buffer
>> >> > > hand-over for the next kernel" patch set.
>> >> > > 
>> >> > > These patches can also be found in the next-kexec-restore branch
>> >> > > of:
>> >> > > git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity
>> >> > > .git
>> >> > 
>> >> > I'll merge these into -mm to get some linux-next exposure.  I don't
>> >> > know what your upstream merge plans will be?
>> >> 
>> >> Sounds good.  I'm hoping to get some review/comments on this patch set
>> >> as well.  At the moment, I'm chasing down a kernel test robot report
>> >> from this afternoon.
>> > 
>> > My concern about changing the canonical format as originally defined in
>> > patch 9/9 from big endian to little endian never materialized.  Andreas
>> > Steffan, the patch author, is happy either way.
>> > 
>> > We proposed two methods of addressing Eric Biederman's concerns of not
>> > including the IMA measurement list segment in the kexec hash as
>> > described in  https://lkml.org/lkml/2016/9/9/355.
>> > 
>> > - defer calculating and verifying the serialized IMA measurement list
>> > buffer hash to IMA
>> > - calculate the kexec hash on load, verify it on the kexec execute,
>> > before re-calculating and updating it.
>> 
>> I need to ask: How this is anticipated to interact with kexec on panic?
>> Because honestly I can't see this ever working in that case.  The
>> assumption is that the original kernel has gone crazy.  So from a
>> practical standpoint any trusted path should have been invalided.
>
> We are not interested in carrying the measurement list in the case of kexec 
> on panic. I see that the code is adding a hand-over buffer to the crash 
> image as well, but that is a bug.
>
> The fix is to do nothing in ima_add_kexec_buffer if image->type != 
> KEXEC_TYPE_DEFAULT.
>  
>> This entire idea of updating the kexec image makes me extremely
>> extremely nervious.  It feels like sticking a screw driver through the
>> spokes of your bicicle tires while ridding down the road.
>> 
>> I can see tracking to see if the list has changed at some
>> point and causing a reboot(LINUX_REBOOT_CMD_KEXEC) to fail.
>
> Yes, that is an interesting feature that I can add using the checksum-
> verifying part of my code. I can submit a patch for that if there's 
> interest, adding a reboot notifier that verifies the checksum and causes a 
> regular reboot instead of a kexec reboot if the checksum fails.

I was thinking an early failure instead of getting all of the way down
into a kernel an discovering the tpm/ima subsystem would not
initialized.  But where that falls in the reboot pathway I don't expect
there is much value in it.

>> At least the common bootloader cases that I know of using kexec are very
>> minimal distributions that live in a ramdisk and as such it should be
>> very straight forward to measure what is needed at or before
>> sys_kexec_load.  But that was completely dismissed as unrealistic so I
>> don't have

Re: TRIM/UNMAP/DISCARD via ATA Passthrough

2016-09-16 Thread James Bottomley

On Fri, 2016-09-16 at 13:06 -0400, Austin S. Hemmelgarn wrote:
> On 2016-09-16 12:21, James Bottomley wrote:
> > On Fri, 2016-09-16 at 11:53 -0400, Austin S. Hemmelgarn wrote:
> > > On 2016-09-16 07:16, Hannes Reinecke wrote:
> > > > On 09/15/2016 10:52 PM, Jason A. Donenfeld wrote:
> > > > > Hi Martin,
> > > > > 
> > > > > On Thu, Sep 15, 2016 at 6:07 PM, Martin K. Petersen
> > > > > > But how do they signal that ATA passthrough is possible? Is
> > > > > > there an ATA Information VPD page? Is REPORT SUPPORTED
> > > > > > OPERATION CODES supported?
> > > > > > 
> > > > > > We need really solid discovery data before we can entertain
> > > > > > enabling something like this.
> > > > > 
> > > > > `sg_opcodes` said invalid request, so I think there isn't REPORT
> > > > > SUPPORTED OPERATION CODES, and `sg_vpd -p ai` came up illegal
> > > > > too.
> > > > > 
> > > > > However, sg_sat_identify worked reliably, which means a solid way
> > > > > of probing this would be to send IDENTIFY DEVICE ATA via
> > > > > SG_ATA_16 or SG_ATA_12.
> > > > > 
> > > > > Let me know and I can give you access to the hardware if you're
> > > > > curious.
> > > > > 
> > > > Sadly, that's not sufficient.
> > > > linux is not the only provider of an SATL (mpt3sas being the most
> > > > prominent other one).
> > > > And while they might support ATA_12/ATA_16, there is no indication
> > > > that you can pass DSM TRIM that way.
> > > So it's better to not support it at all than to support it on
> > > hardware we can reliably identify?
> > > 
> > > I get that having feature parity is a good thing, but the discussion
> > > isn't about providing support for all SATL devices, it's specifically
> > > about UAS connected SATL devices.  Last I checked, mpt3sas doesn't do
> > > anything with UAS, which means it's kind of irrelevant WRT supporting
> > > this for UAS devices.
> > 
> > We're getting a bit off topic on mptsas and it's eccentric SATL.
> > 
> > The point is, you're asking for UAS devices which each have an internal
> > SATL which you say potentially doesn't support discard.  The three
> > problems we have are
> > 
> >1. How do we identify if the UAS SATL doesn't support discard.  If it
> >   does, we really don't want to cause further SATL related issues by
> >   bypassing it, so we need a way of telling this.
> >2. If the SATL doesn't support discard, will it reliably support the
> >   ATA_12 or ATA_16 pass through (and which one) .. we need a way of
> >   checking this because there are known SATLs that don't do pass
> >   through.
> >3. How do we actually configure it?  Presumably if the SATL doesn't
> >   support discard, it also doesn't give us the useful mode page
> >   indications we use to configure TRIM, so we're going to have to do
> >   some pass through discovery as well.
> I assume by 'discard' here you're referring to SCSI UNMAP, as 
> anything that supports ATA_12 or ATA_16 pass through correctly will 
> support ATA TRIM/DISCARD on drives that support it.

discard is the block layer terminology it's mapped per transport to
UNMAP or WRITE SAME on SCSI and TRIM on ATA.

>   If that's the case, then:
> 1. If SCSI UNMAP fails, it doesn't support UNMAP.  This is of course 
> non-trivial to verify safely (we pretty much have to assume it is 
> supported if we have no clear indication it isn't, and then switch 
> based on what happens the first time we try to use it).

It's not quite that simple: to get us to configure discard in the first
place, you have to indicate support in READ CAPACITY (16): the LBPME
bit.  The chances are your UAS SATL isn't setting this.

> 2. Unless there are SATL's out there that write garbage to the device 
> or die when sent an ATA_12 or ATA_16 pass through command


Yes, there are; the problems with USB devices that fail to speak
standard versions of SCSI are legion.

> encapsulating an ATA DEVICE IDENTIFY command, this isn't an issue. 
>  Even if such SATL's exist, they can easily be blacklisted.
> 3. This isn't hard, a SATL which actually supports ATA pass through 
> will almost always pass through the mode page unmodified.

You mean the ATA Information VPD page?  Yes, that's feasible because we
already queried the supported VPD pages, so we can tell if this one's
there.

> On the note of UAS SATL's, all of them that I've seen fall into one 
> of four categories:
> 1. Supports one or both of ATA_12 or ATA_16 pass through, and 
> supports passing through ATA TRIM/DISCARD, but not SCSI UNMAP.
> 2. Supports one of ATA_12 or ATA_16 pass through, and does not 
> support passing through ATA TRIM/DISCARD or translating SCSI UNMAP. 
>  All devices I've seen that fit this will modify the ATA DEVICE 
> IDENTIFY data so it doesn't report DISCARD support, or will simply 
> return an error for DISCARD requests.  I haven't seen any like this 
> that were manufactured after UAS became standardized.
> 3. Supports neither ATA_12 or ATA_16 pass through, and doesn't 
>

Re: TRIM/UNMAP/DISCARD via ATA Passthrough

2016-09-16 Thread James Bottomley

On Fri, 2016-09-16 at 13:06 -0400, Austin S. Hemmelgarn wrote:
> On 2016-09-16 12:21, James Bottomley wrote:
> > On Fri, 2016-09-16 at 11:53 -0400, Austin S. Hemmelgarn wrote:
> > > On 2016-09-16 07:16, Hannes Reinecke wrote:
> > > > On 09/15/2016 10:52 PM, Jason A. Donenfeld wrote:
> > > > > Hi Martin,
> > > > > 
> > > > > On Thu, Sep 15, 2016 at 6:07 PM, Martin K. Petersen
> > > > > > But how do they signal that ATA passthrough is possible? Is
> > > > > > there an ATA Information VPD page? Is REPORT SUPPORTED
> > > > > > OPERATION CODES supported?
> > > > > > 
> > > > > > We need really solid discovery data before we can entertain
> > > > > > enabling something like this.
> > > > > 
> > > > > `sg_opcodes` said invalid request, so I think there isn't REPORT
> > > > > SUPPORTED OPERATION CODES, and `sg_vpd -p ai` came up illegal
> > > > > too.
> > > > > 
> > > > > However, sg_sat_identify worked reliably, which means a solid way
> > > > > of probing this would be to send IDENTIFY DEVICE ATA via
> > > > > SG_ATA_16 or SG_ATA_12.
> > > > > 
> > > > > Let me know and I can give you access to the hardware if you're
> > > > > curious.
> > > > > 
> > > > Sadly, that's not sufficient.
> > > > linux is not the only provider of an SATL (mpt3sas being the most
> > > > prominent other one).
> > > > And while they might support ATA_12/ATA_16, there is no indication
> > > > that you can pass DSM TRIM that way.
> > > So it's better to not support it at all than to support it on
> > > hardware we can reliably identify?
> > > 
> > > I get that having feature parity is a good thing, but the discussion
> > > isn't about providing support for all SATL devices, it's specifically
> > > about UAS connected SATL devices.  Last I checked, mpt3sas doesn't do
> > > anything with UAS, which means it's kind of irrelevant WRT supporting
> > > this for UAS devices.
> > 
> > We're getting a bit off topic on mptsas and it's eccentric SATL.
> > 
> > The point is, you're asking for UAS devices which each have an internal
> > SATL which you say potentially doesn't support discard.  The three
> > problems we have are
> > 
> >1. How do we identify if the UAS SATL doesn't support discard.  If it
> >   does, we really don't want to cause further SATL related issues by
> >   bypassing it, so we need a way of telling this.
> >2. If the SATL doesn't support discard, will it reliably support the
> >   ATA_12 or ATA_16 pass through (and which one) .. we need a way of
> >   checking this because there are known SATLs that don't do pass
> >   through.
> >3. How do we actually configure it?  Presumably if the SATL doesn't
> >   support discard, it also doesn't give us the useful mode page
> >   indications we use to configure TRIM, so we're going to have to do
> >   some pass through discovery as well.
> I assume by 'discard' here you're referring to SCSI UNMAP, as 
> anything that supports ATA_12 or ATA_16 pass through correctly will 
> support ATA TRIM/DISCARD on drives that support it.

discard is the block layer terminology it's mapped per transport to
UNMAP or WRITE SAME on SCSI and TRIM on ATA.

>   If that's the case, then:
> 1. If SCSI UNMAP fails, it doesn't support UNMAP.  This is of course 
> non-trivial to verify safely (we pretty much have to assume it is 
> supported if we have no clear indication it isn't, and then switch 
> based on what happens the first time we try to use it).

It's not quite that simple: to get us to configure discard in the first
place, you have to indicate support in READ CAPACITY (16): the LBPME
bit.  The chances are your UAS SATL isn't setting this.

> 2. Unless there are SATL's out there that write garbage to the device 
> or die when sent an ATA_12 or ATA_16 pass through command


Yes, there are; the problems with USB devices that fail to speak
standard versions of SCSI are legion.

> encapsulating an ATA DEVICE IDENTIFY command, this isn't an issue. 
>  Even if such SATL's exist, they can easily be blacklisted.
> 3. This isn't hard, a SATL which actually supports ATA pass through 
> will almost always pass through the mode page unmodified.

You mean the ATA Information VPD page?  Yes, that's feasible because we
already queried the supported VPD pages, so we can tell if this one's
there.

> On the note of UAS SATL's, all of them that I've seen fall into one 
> of four categories:
> 1. Supports one or both of ATA_12 or ATA_16 pass through, and 
> supports passing through ATA TRIM/DISCARD, but not SCSI UNMAP.
> 2. Supports one of ATA_12 or ATA_16 pass through, and does not 
> support passing through ATA TRIM/DISCARD or translating SCSI UNMAP. 
>  All devices I've seen that fit this will modify the ATA DEVICE 
> IDENTIFY data so it doesn't report DISCARD support, or will simply 
> return an error for DISCARD requests.  I haven't seen any like this 
> that were manufactured after UAS became standardized.
> 3. Supports neither ATA_12 or ATA_16 pass through, and doesn't 
>

Re: [PATCH v1 3/3] ARM: dts: imx6qdl-apalis: Use enable-gpios property for backlight

2016-09-16 Thread maitysanchayan

Hello Marcel,

On 16-09-16 13:38:54, Marcel Ziswiler wrote:
> On Wed, 2016-09-14 at 12:05 +0530, Sanchayan Maity wrote:
> > Use enable-gpios property of PWM backlight driver for backlight
> > control. While at it also fix the use of brightness levels required
> > by EDT displays which require inverted PWM's.
> 
> That part I am missing below. Did you forget to include it?

No, actually I missed fixing the commit message. Currently PWM polarity
inversion is not supported and while checking, I kept the brightness
levels as is currently but did not change the commit message.

Will send a v2 and fix this.

Regards,
Sanchayan.

> 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/imx6qdl-apalis.dtsi | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > index 8c67dd8..9100bde 100644
> > --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > @@ -49,7 +49,10 @@
> >  
> >     backlight: backlight {
> >     compatible = "pwm-backlight";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_gpio_bl_on>;
> >     pwms = < 0 500>;
> > +   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
> >     status = "disabled";
> >     };
> >  
> > @@ -614,6 +617,12 @@
> >     >;
> >     };
> >  
> > +   pinctrl_gpio_bl_on: gpioblon {
> > +   fsl,pins = <
> > +   MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x1b0b0
> > +   >;
> > +   };
> > +
> >     pinctrl_gpio_keys: gpio1io04grp {
> >     fsl,pins = <
> >     /* Power button */

Re: [PATCH v1 3/3] ARM: dts: imx6qdl-apalis: Use enable-gpios property for backlight

2016-09-16 Thread maitysanchayan

Hello Marcel,

On 16-09-16 13:38:54, Marcel Ziswiler wrote:
> On Wed, 2016-09-14 at 12:05 +0530, Sanchayan Maity wrote:
> > Use enable-gpios property of PWM backlight driver for backlight
> > control. While at it also fix the use of brightness levels required
> > by EDT displays which require inverted PWM's.
> 
> That part I am missing below. Did you forget to include it?

No, actually I missed fixing the commit message. Currently PWM polarity
inversion is not supported and while checking, I kept the brightness
levels as is currently but did not change the commit message.

Will send a v2 and fix this.

Regards,
Sanchayan.

> 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/imx6qdl-apalis.dtsi | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > index 8c67dd8..9100bde 100644
> > --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > @@ -49,7 +49,10 @@
> >  
> >     backlight: backlight {
> >     compatible = "pwm-backlight";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_gpio_bl_on>;
> >     pwms = < 0 500>;
> > +   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
> >     status = "disabled";
> >     };
> >  
> > @@ -614,6 +617,12 @@
> >     >;
> >     };
> >  
> > +   pinctrl_gpio_bl_on: gpioblon {
> > +   fsl,pins = <
> > +   MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x1b0b0
> > +   >;
> > +   };
> > +
> >     pinctrl_gpio_keys: gpio1io04grp {
> >     fsl,pins = <
> >     /* Power button */

RE: [PATCH 0/2] PCI/AER: Remove module parameters

2016-09-16 Thread Tang, CQ

Bjorn,
 Can we extend this aerdriver to support AER from a root complex integrated 
endpoint? Root complex event collector has the same job as root port in this 
case.

 It looks that both port driver and aer driver check 
PCI_EXP_TYPE_ROOT_PORT/PCI_EXP_TYPE_UPSTREAM/PCI_EXP_TYPE_DOWNSTREAM only.
portdrv_pci.c:127, aerdrv.c:86

  Is it just a simple addition of PCI_EXP_TYPE_RC_EC to above two places?  
Is there any difference to recover a root complex integrated endpoint? 
(compared with devices connected to root port).

Thanks.
--CQ

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Bjorn Helgaas
> Sent: Wednesday, September 14, 2016 1:30 PM
> To: Bjorn Helgaas 
> Cc: linux-...@vger.kernel.org; Lance Ortiz ; Betty Dall
> ; Hidetoshi Seto ;
> Chen Gong ; keithbuschkeith.bu...@intel.com;
> Rafael J. Wysocki ; linux-kernel@vger.kernel.org; Shuah
> Khan ; Huang, Ying ;
> Vijay Mohan Pandarathil ; Derrick,
> Jonathan 
> Subject: Re: [PATCH 0/2] PCI/AER: Remove module parameters
> 
> On Tue, Sep 06, 2016 at 05:19:22PM -0500, Bjorn Helgaas wrote:
> > I'd like to remove the aerdriver.nosourceid and aerdriver.forceload
> > kernel parameters.  They seem like basically debugging things that are
> > not really supportable upstream.
> >
> > "nosourceid" may have some legitimate uses, but I'd rather it were
> > done via quirks with the flag Jon Derrick recently added so it happens
> > automatically, without users having to specify the parameter.
> >
> > I don't *know* of any actual users of either of these, but obviously
> > that doesn't mean there are none.  Comments welcome.
> >
> > ---
> >
> > Bjorn Helgaas (2):
> >   PCI/AER: Remove aerdriver.nosourceid kernel parameter
> >   PCI/AER: Remove aerdriver.forceload kernel parameter
> >
> >
> >  Documentation/PCI/pcieaer-howto.txt |   26 +-
> >  drivers/pci/pcie/aer/aerdrv.c   |7 +--
> >  drivers/pci/pcie/aer/aerdrv.h   |8 
> >  drivers/pci/pcie/aer/aerdrv_core.c  |   31 ---
> >  4 files changed, 14 insertions(+), 58 deletions(-)
> 
> I'm going to go out on a limb a little bit and apply these to pci/aer for 
> v4.9.
> Please let me know if you trip over any issues.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in the
> body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

RE: [PATCH 0/2] PCI/AER: Remove module parameters

2016-09-16 Thread Tang, CQ

Bjorn,
 Can we extend this aerdriver to support AER from a root complex integrated 
endpoint? Root complex event collector has the same job as root port in this 
case.

 It looks that both port driver and aer driver check 
PCI_EXP_TYPE_ROOT_PORT/PCI_EXP_TYPE_UPSTREAM/PCI_EXP_TYPE_DOWNSTREAM only.
portdrv_pci.c:127, aerdrv.c:86

  Is it just a simple addition of PCI_EXP_TYPE_RC_EC to above two places?  
Is there any difference to recover a root complex integrated endpoint? 
(compared with devices connected to root port).

Thanks.
--CQ

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Bjorn Helgaas
> Sent: Wednesday, September 14, 2016 1:30 PM
> To: Bjorn Helgaas 
> Cc: linux-...@vger.kernel.org; Lance Ortiz ; Betty Dall
> ; Hidetoshi Seto ;
> Chen Gong ; keithbuschkeith.bu...@intel.com;
> Rafael J. Wysocki ; linux-kernel@vger.kernel.org; Shuah
> Khan ; Huang, Ying ;
> Vijay Mohan Pandarathil ; Derrick,
> Jonathan 
> Subject: Re: [PATCH 0/2] PCI/AER: Remove module parameters
> 
> On Tue, Sep 06, 2016 at 05:19:22PM -0500, Bjorn Helgaas wrote:
> > I'd like to remove the aerdriver.nosourceid and aerdriver.forceload
> > kernel parameters.  They seem like basically debugging things that are
> > not really supportable upstream.
> >
> > "nosourceid" may have some legitimate uses, but I'd rather it were
> > done via quirks with the flag Jon Derrick recently added so it happens
> > automatically, without users having to specify the parameter.
> >
> > I don't *know* of any actual users of either of these, but obviously
> > that doesn't mean there are none.  Comments welcome.
> >
> > ---
> >
> > Bjorn Helgaas (2):
> >   PCI/AER: Remove aerdriver.nosourceid kernel parameter
> >   PCI/AER: Remove aerdriver.forceload kernel parameter
> >
> >
> >  Documentation/PCI/pcieaer-howto.txt |   26 +-
> >  drivers/pci/pcie/aer/aerdrv.c   |7 +--
> >  drivers/pci/pcie/aer/aerdrv.h   |8 
> >  drivers/pci/pcie/aer/aerdrv_core.c  |   31 ---
> >  4 files changed, 14 insertions(+), 58 deletions(-)
> 
> I'm going to go out on a limb a little bit and apply these to pci/aer for 
> v4.9.
> Please let me know if you trip over any issues.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in the
> body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

2016-09-16 Thread Anshuman Khandual

On 09/12/2016 11:43 PM, David Rientjes wrote:
> On Mon, 12 Sep 2016, Anshuman Khandual wrote:
> 
> after memory or node hot[un]plug is desirable. This change adds one
> new sysfs interface (/sys/devices/system/memory/system_zone_details)
> which will fetch and dump this information.
>>> Doesn't this violate the "one value per file" sysfs rule?  Does it
>>> belong in debugfs instead?
>>
>> Yeah sure. Will make it a debugfs interface.
>>
> 
> So the intended reader of this file is running as root?

Yeah.

> 
>>> I also really question the need to dump kernel addresses out, filtered 
>>> or not.  What's the point?
>>
>> Hmm, thought it to be an additional information. But yes its additional
>> and can be dropped.
>>
> 
> I'm questioning if this information can be inferred from information 
> already in /proc/zoneinfo and sysfs.  We know the no-fallback zonelist is 
> going to include the local node, and we know the other zonelists are 
> either node ordered or zone ordered (or do we need to extend 
> vm.numa_zonelist_order for default?).  I may have missed what new 
> knowledge this interface is imparting on us.

IIUC /proc/zoneinfo lists down zone internal state and statistics for
all zones on the system at any given point of time. The no-fallback
list contains the zones from the local node and fallback (which gets
used more often than the no-fallback) list contains all zones either
in node-ordered or zone-ordered manner. In most of the platforms the
default being the node order but the sequence of present nodes in
that order is determined by various factors like NUMA distance, load,
presence of CPUs on the node etc. This order of nodes in the fallback
list is the most important information derived out of this interface.

Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

2016-09-16 Thread Anshuman Khandual

On 09/12/2016 11:43 PM, David Rientjes wrote:
> On Mon, 12 Sep 2016, Anshuman Khandual wrote:
> 
> after memory or node hot[un]plug is desirable. This change adds one
> new sysfs interface (/sys/devices/system/memory/system_zone_details)
> which will fetch and dump this information.
>>> Doesn't this violate the "one value per file" sysfs rule?  Does it
>>> belong in debugfs instead?
>>
>> Yeah sure. Will make it a debugfs interface.
>>
> 
> So the intended reader of this file is running as root?

Yeah.

> 
>>> I also really question the need to dump kernel addresses out, filtered 
>>> or not.  What's the point?
>>
>> Hmm, thought it to be an additional information. But yes its additional
>> and can be dropped.
>>
> 
> I'm questioning if this information can be inferred from information 
> already in /proc/zoneinfo and sysfs.  We know the no-fallback zonelist is 
> going to include the local node, and we know the other zonelists are 
> either node ordered or zone ordered (or do we need to extend 
> vm.numa_zonelist_order for default?).  I may have missed what new 
> knowledge this interface is imparting on us.

IIUC /proc/zoneinfo lists down zone internal state and statistics for
all zones on the system at any given point of time. The no-fallback
list contains the zones from the local node and fallback (which gets
used more often than the no-fallback) list contains all zones either
in node-ordered or zone-ordered manner. In most of the platforms the
default being the node order but the sequence of present nodes in
that order is determined by various factors like NUMA distance, load,
presence of CPUs on the node etc. This order of nodes in the fallback
list is the most important information derived out of this interface.

Re: [REGRESSION] RLIMIT_DATA crashes named

2016-09-16 Thread Joe Perches

On Fri, 2016-09-16 at 17:040700, Linus Torvalds wrote:
> On Fri, Sep 16, 2016 at 4:58 PM, Linus Torvalds 
>  wrote:
> > Here's a totally untested patch. What do people say?
> Heh. It looks like "pr_xyz_once()" is used in places that haven't
> included "ratelimit.h", so this doesn't actually build for everything.
> But I guess as a concept patch it's not hard to understand, even if
> the implementation needs a bit of tweaking.

do_just_once just isn't a good name for a global
rate limited mechanism that does something very
different than the name.

Maybe allow_once_per_ratelimit or the like

There could be an equivalent do_once

https://lkml.org/lkml/2009/5/22/3

Re: [REGRESSION] RLIMIT_DATA crashes named

2016-09-16 Thread Joe Perches

On Fri, 2016-09-16 at 17:040700, Linus Torvalds wrote:
> On Fri, Sep 16, 2016 at 4:58 PM, Linus Torvalds 
>  wrote:
> > Here's a totally untested patch. What do people say?
> Heh. It looks like "pr_xyz_once()" is used in places that haven't
> included "ratelimit.h", so this doesn't actually build for everything.
> But I guess as a concept patch it's not hard to understand, even if
> the implementation needs a bit of tweaking.

do_just_once just isn't a good name for a global
rate limited mechanism that does something very
different than the name.

Maybe allow_once_per_ratelimit or the like

There could be an equivalent do_once

https://lkml.org/lkml/2009/5/22/3

Re: [PATCH v7 0/5] mfd: tps65218: Clean ups

2016-09-16 Thread Keerthy

On Friday 16 September 2016 11:06 PM, Mark Brown wrote:

On Fri, Sep 16, 2016 at 09:51:38PM +0530, Keerthy wrote:

On Friday 16 September 2016 07:01 PM, Mark Brown wrote:

On Fri, Sep 16, 2016 at 05:12:38PM +0530, Keerthy wrote:

Should i repost this series? I do not see this series in linux-next yet.

Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so

I should have been clearer.
The last Lee Jones conveyed that:

"I can't take this series yet, since it relies on a change which was
taken into Mark's Regulator tree"

https://lkml.org/lkml/2016/8/31/312

So wanted to check if i needed to re-base/repost this series again.
Sorry about the confusion i think that is because of $Subject goof up in the
0th patch of the series.

I'm afraid I've no real idea what this series is about or what patches
it might depend on, sorry. If you're waiting for me to do something
you'll need to tell me what it is but if it's a dependency that needs
cross merging then reposting this series isn't going to be needed.

The series cleans up mainly the regulator driver and implements
the device tree parsing using the regulator framework. Removes
all the redundant compatibles for the individual regulators.
Adds platform_device_id table for the gpio and power button modules.

This has been reviewed extensively.

Looks like v7 no longer applies directly on the linux-next branch as it
conflicts with:

https://kernel.googlesource.com/pub/scm/linux/kernel/git/dtor/input/+/722dc54628ca5cffd3b4581b523775aa422b55df

I will rebase and repost on the current linux-next and post v8.

Re: [PATCH v7 0/5] mfd: tps65218: Clean ups

2016-09-16 Thread Keerthy

On Friday 16 September 2016 11:06 PM, Mark Brown wrote:

On Fri, Sep 16, 2016 at 09:51:38PM +0530, Keerthy wrote:

On Friday 16 September 2016 07:01 PM, Mark Brown wrote:

On Fri, Sep 16, 2016 at 05:12:38PM +0530, Keerthy wrote:

Should i repost this series? I do not see this series in linux-next yet.

Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so

I should have been clearer.
The last Lee Jones conveyed that:

"I can't take this series yet, since it relies on a change which was
taken into Mark's Regulator tree"

https://lkml.org/lkml/2016/8/31/312

So wanted to check if i needed to re-base/repost this series again.
Sorry about the confusion i think that is because of $Subject goof up in the
0th patch of the series.

This has been reviewed extensively.

Looks like v7 no longer applies directly on the linux-next branch as it
conflicts with:

https://kernel.googlesource.com/pub/scm/linux/kernel/git/dtor/input/+/722dc54628ca5cffd3b4581b523775aa422b55df

I will rebase and repost on the current linux-next and post v8.

[PATCH 2/2] power: bq27xxx_battery: allow kernel poll_interval parameter runtime update

2016-09-16 Thread Matt Ranostay

Fix issue with poll_interval being not updated till the previous
interval expired.

Signed-off-by: Matt Ranostay 
---
 drivers/power/supply/bq27xxx_battery.c | 38 +-
 include/linux/power/bq27xxx_battery.h  |  1 +
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/power/supply/bq27xxx_battery.c 
b/drivers/power/supply/bq27xxx_battery.c
index 955424e10ae2..96fd3eec98da 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -39,6 +39,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -390,8 +391,35 @@ static struct {
BQ27XXX_PROP(BQ27421, bq27421_battery_props),
 };
 
+static DEFINE_MUTEX(param_lock);
+static LIST_HEAD(bq27xxx_battery_devices);
+
+static int poll_interval_param_set(const char *val, const struct kernel_param 
*kp)
+{
+   struct bq27xxx_device_info *di;
+   int ret;
+
+   ret = param_set_uint(val, kp);
+   if (ret < 0)
+   return ret;
+
+   mutex_lock(_lock);
+   list_for_each_entry(di, _battery_devices, list) {
+   cancel_delayed_work_sync(>work);
+   schedule_delayed_work(>work, 0);
+   }
+   mutex_unlock(_lock);
+
+   return ret;
+}
+
+static const struct kernel_param_ops param_ops_poll_interval = {
+   .get = param_get_ushort,
+   .set = poll_interval_param_set,
+};
+
 static unsigned int poll_interval = 360;
-module_param(poll_interval, uint, 0644);
+module_param_cb(poll_interval, _ops_poll_interval, _interval, 0644);
 MODULE_PARM_DESC(poll_interval,
 "battery poll interval in seconds - 0 disables polling");
 
@@ -1011,6 +1039,10 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
 
bq27xxx_battery_update(di);
 
+   mutex_lock(_lock);
+   list_add(>list, _battery_devices);
+   mutex_unlock(_lock);
+
return 0;
 
 err_out:
@@ -1036,6 +1068,10 @@ void bq27xxx_battery_teardown(struct bq27xxx_device_info 
*di)
 
power_supply_unregister(di->bat);
 
+   mutex_lock(_lock);
+   list_del(>list);
+   mutex_unlock(_lock);
+
mutex_destroy(>lock);
 }
 EXPORT_SYMBOL_GPL(bq27xxx_battery_teardown);
diff --git a/include/linux/power/bq27xxx_battery.h 
b/include/linux/power/bq27xxx_battery.h
index b50c0492629d..e30deb046156 100644
--- a/include/linux/power/bq27xxx_battery.h
+++ b/include/linux/power/bq27xxx_battery.h
@@ -58,6 +58,7 @@ struct bq27xxx_device_info {
unsigned long last_update;
struct delayed_work work;
struct power_supply *bat;
+   struct list_head list;
struct mutex lock;
u8 *regs;
 };
-- 
2.7.4

[PATCH 2/2] power: bq27xxx_battery: allow kernel poll_interval parameter runtime update

2016-09-16 Thread Matt Ranostay

Fix issue with poll_interval being not updated till the previous
interval expired.

Signed-off-by: Matt Ranostay 
---
 drivers/power/supply/bq27xxx_battery.c | 38 +-
 include/linux/power/bq27xxx_battery.h  |  1 +
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/power/supply/bq27xxx_battery.c 
b/drivers/power/supply/bq27xxx_battery.c
index 955424e10ae2..96fd3eec98da 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -39,6 +39,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -390,8 +391,35 @@ static struct {
BQ27XXX_PROP(BQ27421, bq27421_battery_props),
 };
 
+static DEFINE_MUTEX(param_lock);
+static LIST_HEAD(bq27xxx_battery_devices);
+
+static int poll_interval_param_set(const char *val, const struct kernel_param 
*kp)
+{
+   struct bq27xxx_device_info *di;
+   int ret;
+
+   ret = param_set_uint(val, kp);
+   if (ret < 0)
+   return ret;
+
+   mutex_lock(_lock);
+   list_for_each_entry(di, _battery_devices, list) {
+   cancel_delayed_work_sync(>work);
+   schedule_delayed_work(>work, 0);
+   }
+   mutex_unlock(_lock);
+
+   return ret;
+}
+
+static const struct kernel_param_ops param_ops_poll_interval = {
+   .get = param_get_ushort,
+   .set = poll_interval_param_set,
+};
+
 static unsigned int poll_interval = 360;
-module_param(poll_interval, uint, 0644);
+module_param_cb(poll_interval, _ops_poll_interval, _interval, 0644);
 MODULE_PARM_DESC(poll_interval,
 "battery poll interval in seconds - 0 disables polling");
 
@@ -1011,6 +1039,10 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
 
bq27xxx_battery_update(di);
 
+   mutex_lock(_lock);
+   list_add(>list, _battery_devices);
+   mutex_unlock(_lock);
+
return 0;
 
 err_out:
@@ -1036,6 +1068,10 @@ void bq27xxx_battery_teardown(struct bq27xxx_device_info 
*di)
 
power_supply_unregister(di->bat);
 
+   mutex_lock(_lock);
+   list_del(>list);
+   mutex_unlock(_lock);
+
mutex_destroy(>lock);
 }
 EXPORT_SYMBOL_GPL(bq27xxx_battery_teardown);
diff --git a/include/linux/power/bq27xxx_battery.h 
b/include/linux/power/bq27xxx_battery.h
index b50c0492629d..e30deb046156 100644
--- a/include/linux/power/bq27xxx_battery.h
+++ b/include/linux/power/bq27xxx_battery.h
@@ -58,6 +58,7 @@ struct bq27xxx_device_info {
unsigned long last_update;
struct delayed_work work;
struct power_supply *bat;
+   struct list_head list;
struct mutex lock;
u8 *regs;
 };
-- 
2.7.4

[PATCH 1/2] power: bq27xxx_battery: add configurable poll_interval by sysfs

2016-09-16 Thread Matt Ranostay

Allow the poll_interval to be runtime configurable via an sysfs entry.
This is needed for udev control of the poll interval.

Signed-off-by: Matt Ranostay 
---
 drivers/power/supply/bq27xxx_battery.c | 48 +-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/power/supply/bq27xxx_battery.c 
b/drivers/power/supply/bq27xxx_battery.c
index 3f57dd54803a..955424e10ae2 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -395,6 +395,36 @@ module_param(poll_interval, uint, 0644);
 MODULE_PARM_DESC(poll_interval,
 "battery poll interval in seconds - 0 disables polling");
 
+
+static ssize_t show_poll_interval(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   return sprintf(buf, "%d\n", poll_interval);
+}
+
+static ssize_t store_poll_interval(struct device *dev,
+  struct device_attribute *attr,
+  const char *buf, size_t size)
+{
+   struct bq27xxx_device_info *di = dev_get_drvdata(dev);
+   int tmp = poll_interval;
+
+   if (sscanf(buf, "%d\n", _interval) != 1)
+   return -EINVAL;
+
+   if (poll_interval < 0)
+   return -EINVAL;
+
+   if (tmp != poll_interval) {
+   cancel_delayed_work_sync(>work);
+   schedule_delayed_work(>work, 0);
+   }
+
+   return size;
+}
+
+static DEVICE_ATTR(poll_interval, 0644, show_poll_interval, 
store_poll_interval);
+
 /*
  * Common code for BQ27xxx devices
  */
@@ -946,6 +976,7 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
 {
struct power_supply_desc *psy_desc;
struct power_supply_config psy_cfg = { .drv_data = di, };
+   int ret;
 
INIT_DELAYED_WORK(>work, bq27xxx_battery_poll);
mutex_init(>lock);
@@ -961,11 +992,19 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
psy_desc->num_properties = bq27xxx_battery_props[di->chip].size;
psy_desc->get_property = bq27xxx_battery_get_property;
psy_desc->external_power_changed = bq27xxx_external_power_changed;
+   dev_set_drvdata(di->dev, di);
+
+   ret = sysfs_create_file(>dev->kobj, _attr_poll_interval.attr);
+   if (ret) {
+   dev_err(di->dev, "failed to register poll_interval sysfs 
entry");
+   return ret;
+   }
 
di->bat = power_supply_register_no_ws(di->dev, psy_desc, _cfg);
if (IS_ERR(di->bat)) {
dev_err(di->dev, "failed to register battery\n");
-   return PTR_ERR(di->bat);
+   ret = PTR_ERR(di->bat);
+   goto err_out;
}
 
dev_info(di->dev, "support ver. %s enabled\n", DRIVER_VERSION);
@@ -973,6 +1012,11 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
bq27xxx_battery_update(di);
 
return 0;
+
+err_out:
+   sysfs_remove_file(>dev->kobj, _attr_poll_interval.attr);
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(bq27xxx_battery_setup);
 
@@ -988,6 +1032,8 @@ void bq27xxx_battery_teardown(struct bq27xxx_device_info 
*di)
 
cancel_delayed_work_sync(>work);
 
+   sysfs_remove_file(>dev->kobj, _attr_poll_interval.attr);
+
power_supply_unregister(di->bat);
 
mutex_destroy(>lock);
-- 
2.7.4

[PATCH 1/2] power: bq27xxx_battery: add configurable poll_interval by sysfs

2016-09-16 Thread Matt Ranostay

Allow the poll_interval to be runtime configurable via an sysfs entry.
This is needed for udev control of the poll interval.

Signed-off-by: Matt Ranostay 
---
 drivers/power/supply/bq27xxx_battery.c | 48 +-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/power/supply/bq27xxx_battery.c 
b/drivers/power/supply/bq27xxx_battery.c
index 3f57dd54803a..955424e10ae2 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -395,6 +395,36 @@ module_param(poll_interval, uint, 0644);
 MODULE_PARM_DESC(poll_interval,
 "battery poll interval in seconds - 0 disables polling");
 
+
+static ssize_t show_poll_interval(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   return sprintf(buf, "%d\n", poll_interval);
+}
+
+static ssize_t store_poll_interval(struct device *dev,
+  struct device_attribute *attr,
+  const char *buf, size_t size)
+{
+   struct bq27xxx_device_info *di = dev_get_drvdata(dev);
+   int tmp = poll_interval;
+
+   if (sscanf(buf, "%d\n", _interval) != 1)
+   return -EINVAL;
+
+   if (poll_interval < 0)
+   return -EINVAL;
+
+   if (tmp != poll_interval) {
+   cancel_delayed_work_sync(>work);
+   schedule_delayed_work(>work, 0);
+   }
+
+   return size;
+}
+
+static DEVICE_ATTR(poll_interval, 0644, show_poll_interval, 
store_poll_interval);
+
 /*
  * Common code for BQ27xxx devices
  */
@@ -946,6 +976,7 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
 {
struct power_supply_desc *psy_desc;
struct power_supply_config psy_cfg = { .drv_data = di, };
+   int ret;
 
INIT_DELAYED_WORK(>work, bq27xxx_battery_poll);
mutex_init(>lock);
@@ -961,11 +992,19 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
psy_desc->num_properties = bq27xxx_battery_props[di->chip].size;
psy_desc->get_property = bq27xxx_battery_get_property;
psy_desc->external_power_changed = bq27xxx_external_power_changed;
+   dev_set_drvdata(di->dev, di);
+
+   ret = sysfs_create_file(>dev->kobj, _attr_poll_interval.attr);
+   if (ret) {
+   dev_err(di->dev, "failed to register poll_interval sysfs 
entry");
+   return ret;
+   }
 
di->bat = power_supply_register_no_ws(di->dev, psy_desc, _cfg);
if (IS_ERR(di->bat)) {
dev_err(di->dev, "failed to register battery\n");
-   return PTR_ERR(di->bat);
+   ret = PTR_ERR(di->bat);
+   goto err_out;
}
 
dev_info(di->dev, "support ver. %s enabled\n", DRIVER_VERSION);
@@ -973,6 +1012,11 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
bq27xxx_battery_update(di);
 
return 0;
+
+err_out:
+   sysfs_remove_file(>dev->kobj, _attr_poll_interval.attr);
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(bq27xxx_battery_setup);
 
@@ -988,6 +1032,8 @@ void bq27xxx_battery_teardown(struct bq27xxx_device_info 
*di)
 
cancel_delayed_work_sync(>work);
 
+   sysfs_remove_file(>dev->kobj, _attr_poll_interval.attr);
+
power_supply_unregister(di->bat);
 
mutex_destroy(>lock);
-- 
2.7.4

[PATCH 0/2] power: bq27xxx_battery: add configurable poll_interval

2016-09-16 Thread Matt Ranostay

Patchset series fixes the kernel_parameter poll_interval not scheduling
the next event with the new interval. Also creates a sysfs entry that is
useful for udev attribute assignment.

Matt Ranostay (2):
  power: bq27xxx_battery: add configurable poll_interval by sysfs
  power: bq27xxx_battery: allow kernel poll_interval parameter runtime
update

 drivers/power/supply/bq27xxx_battery.c | 87 +-
 include/linux/power/bq27xxx_battery.h  |  1 +
 2 files changed, 86 insertions(+), 2 deletions(-)

-- 
2.7.4

[PATCH 0/2] power: bq27xxx_battery: add configurable poll_interval

2016-09-16 Thread Matt Ranostay

Patchset series fixes the kernel_parameter poll_interval not scheduling
the next event with the new interval. Also creates a sysfs entry that is
useful for udev attribute assignment.

Matt Ranostay (2):
  power: bq27xxx_battery: add configurable poll_interval by sysfs
  power: bq27xxx_battery: allow kernel poll_interval parameter runtime
update

 drivers/power/supply/bq27xxx_battery.c | 87 +-
 include/linux/power/bq27xxx_battery.h  |  1 +
 2 files changed, 86 insertions(+), 2 deletions(-)

-- 
2.7.4

Re: qemu:metag image runtime failure in -next due to 'kthread: allow to cancel kthread work'

2016-09-16 Thread Kees Cook

On Fri, Sep 16, 2016 at 4:32 PM, James Hogan  wrote:
> On Fri, Sep 16, 2016 at 02:37:18PM -0700, Guenter Roeck wrote:
>> On Fri, Sep 16, 2016 at 10:27:20PM +0100, James Hogan wrote:
>> > On Fri, Sep 16, 2016 at 01:38:19PM -0700, Guenter Roeck wrote:
>> > > Hi,
>> > >
>> > > I see the following runtime error in -next when running a metag qemu 
>> > > emulation.
>> > >
>> > > [ ... ]
>> > > workingset: timestamp_bits=30 max_order=16 bucket_order=0
>> > > io scheduler noop registered (default)
>> > > brd: module loaded
>> > > Warning: unable to open an initial console.
>> > > List of all partitions:
>> > > 0100   16384 ram0  (driver?)
>> > > No filesystem could mount root, tried:
>> > > Kernel panic - not syncing: VFS: Unable to mount root fs on 
>> > > unknown-block(1,0)
>> > >
>> > > An example for a complete log is at:
>> > > http://kerneltests.org/builders/qemu-metag-next/builds/489/steps/qemubuildcommand/logs/stdio
>> > >
>> > > bisect points to commit ef98de028afde ("kthread: allow to cancel kthread 
>> > > work").
>> > > I don't know (yet) if other architectures are affected. bisect log is 
>> > > attached.
>> > >
>> > > The scripts to run this test are available at
>> > > https://github.com/groeck/linux-build-test/tree/master/rootfs/metag.
>> > >
>> > > Guenter
>> >
>> > Thanks Guenter,
>> >
>> > It appears to be related to the command line. After that commit the
>> > command line is shown as empty (rather than your "rdinit=/sbin/init
>> > doreboot"), but it can still be overridden in the config and then it
>> > continues to work.
>> >
>> Weird.
>
> Previously the Elf had a single load program header:
>
> Program Headers:
>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD   0x004000 0x4000 0x4000 0x34b304 0x376230 RWE 0x4000
>   NOTE   0x1ecc08 0x401e8c08 0x401e8c08 0x0 0x0 R   0x4
>
> QEMU puts the args at 40376230, straight after the load region (unlike a
> real Meta Linux bootloader).
>
> After the above commit the ELF gets two load program headers, with a
> small alignment gap in the middle:
>
> Program Headers:
>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD   0x004000 0x4000 0x4000 0x18f118 0x18f118 R E 0x4000
>   LOAD   0x194000 0x4019 0x4019 0x1bd304 0x1e8230 RWE 0x4000
>   NOTE   0x1eec08 0x401eac08 0x401eac08 0x0 0x0 R   0x4
>
> Here this version of QEMU puts the args at where it thinks the end of
> the loaded image is, which is based on the number of bytes copied from
> the ELF, i.e. the total MemSiz's, not taking into account the alignment
> gap in between, so it puts them at 0x40377348.
>
> But of course:
> 40378230 B ___bss_stop
>
> so it wipes them out while clearing bss during early init.
>
> Previously:
> 4018ebd0 T __sdata
> 4018f000 R ___start_rodata
>
> now:
> 4018ed98 T __sdata
> 4019 R ___start_rodata
>
> So I'm thinking this may have been triggered by c74ba8b3480d ("arch:
> Introduce post-init read-only memory").
>
> The hack below does indeed reduce it to a single load section and this
> version of QEMU then succeeds:
>
> Program Headers:
>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD   0x004000 0x4000 0x4000 0x34d304 0x378230 RWE 0x4000
>   NOTE   0x1eec88 0x401eac88 0x401eac88 0x0 0x0 R   0x4
>
> diff --git a/arch/metag/include/asm/cache.h b/arch/metag/include/asm/cache.h
> index a43b650cfdc0..b5c7364a94da 100644
> --- a/arch/metag/include/asm/cache.h
> +++ b/arch/metag/include/asm/cache.h
> @@ -20,4 +20,6 @@
>
>  #define __read_mostly __attribute__((__section__(".data..read_mostly")))
>
> +#define __ro_after_init__read_mostly
> +
>  #endif
>
> Kees: Is it expected to get multiple load headers like this since your
> patch c74ba8b3480d ("arch: Introduce post-init read-only memory"),
> depending on alignment of the read only section?

I'm not expecting that, and I'm especially not expecting any LOAD to
have "RWE" flags. It looks like metag's vmlinux.lds.S is using the
common RO_DATA_SECTION, so that doesn't jump out at me as a reason for
RO_AFTER_INIT_DATA to end up in the wrong place. Also the second LOAD
in the ELF is really huge, so it's not just the RO_AFTER_INIT_DATA
section (which is currently very small).

Could the metag linker be failing to override the section flags when
putting RO_AFTER_INIT_DATA into RO_DATA_SECTION and this cuts the LOAD
in half? This smells like a linker glitch.

However, since metag doesn't support CONFIG_DEBUG_RODATA, your above
patch is likely correct. If metag marks memory read-only at kernel
load time, it's doing it early enough that __ro_after_init will fail
to work. If it never marks memory read-only, then __ro_after_init will
have no effect. (i.e. Both situations need the proposed patch).

Probably the best solution for all architectures is to invent a new
CONFIG_ARCH_HAS... to

Re: [PATCH v3) posix-timers: make it configurable

2016-09-16 Thread Nicolas Pitre

On Fri, 16 Sep 2016, Richard Cochran wrote:

> On Thu, Sep 15, 2016 at 02:56:49PM -0700, Josh Triplett wrote:
> > > I suspect there is more of a case for having net drivers _without_ ptp 
> > > support.  This could be implemented with a ptp_clock_register() stub 
> > > returning NULL when ptp is not configured.  I didn't look at most 
> > > drivers but at least broadcom/tg3.c seems to be fine with such an 
> > > approach.
> 
> (I wouldn't be suprised if some drivers fail to deal with NULL
> gracefully, but those can always be fixed ;)

I've looked at all of them and I think they should be fine with the 
minor changes I've included below.  Tested with allyesconfig and 
CONFIG_POSIX_TIMERS=n.

- >8
Subject: [PATCH] ptp_clock: allow for it to be optional

In order to break the hard dependency between the PTP clock subsystem and
ethernet drivers capable of being clock providers, this patch provides
simple PTP stub functions to allow linkage of those drivers into the
kernel even when the PTP subsystem is configured out.

And to make it possible for PTP to be configured out, the select statement
in the Kconfig entry for those ethernet drivers is changed from selecting
PTP_1588_CLOCK to PTP_1588_CLOCK_DEFAULT whose purpose is to indicate the
default Kconfig value for the PTP subsystem.

This way the PTP subsystem may have Kconfig dependencies of its own, such
as POSIX_TIMERS, without making those ethernet drivers unavailable if
POSIX timers are cconfigured out. And when support for POSIX timers is
selected again then PTP clock support will also be selected accordingly.

Drivers must be ready to accept NULL from ptp_clock_register().
The pch_gbe driver is a bit special as it relies on extra code in
drivers/ptp/ptp_pch.c. Therefore we let the make process descend into
drivers/ptp/ even if PTP_1588_CLOCK is unselected.

Signed-off-by: Nicolas Pitre 

diff --git a/drivers/Makefile b/drivers/Makefile
index 53abb4a5f7..8a538d0856 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -105,7 +105,7 @@ obj-$(CONFIG_INPUT) += input/
 obj-$(CONFIG_RTC_LIB)  += rtc/
 obj-y  += i2c/ media/
 obj-$(CONFIG_PPS)  += pps/
-obj-$(CONFIG_PTP_1588_CLOCK)   += ptp/
+obj-y  += ptp/
 obj-$(CONFIG_W1)   += w1/
 obj-y  += power/
 obj-$(CONFIG_HWMON)+= hwmon/
diff --git a/drivers/net/ethernet/adi/Kconfig b/drivers/net/ethernet/adi/Kconfig
index 6b94ba6103..eea414337c 100644
--- a/drivers/net/ethernet/adi/Kconfig
+++ b/drivers/net/ethernet/adi/Kconfig
@@ -55,10 +55,14 @@ config BFIN_RX_DESC_NUM
---help---
  Set the number of buffer packets used in driver.
 
+config BFIN_MAC_HAS_HWSTAMP
+   def_tristate BFIN_MAC
+   depends on BF518
+   select PTP_1588_CLOCK_DEFAULT
+
 config BFIN_MAC_USE_HWSTAMP
bool "Use IEEE 1588 hwstamp"
-   depends on BFIN_MAC && BF518
-   select PTP_1588_CLOCK
+   depends on BFIN_MAC_HAS_HWSTAMP && PTP_1588_CLOCK
default y
---help---
  To support the IEEE 1588 Precision Time Protocol (PTP), select y here
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 0038709fd3..c2aaa5f949 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -177,7 +177,7 @@ config AMD_XGBE
depends on ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
-   select PTP_1588_CLOCK
+   select PTP_1588_CLOCK_DEFAULT
---help---
  This driver supports the AMD 10GbE Ethernet device found on an
  AMD SoC.
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-main.c 
b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
index 3eee3201b5..4aeeb018b6 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-main.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
@@ -773,7 +773,8 @@ static int xgbe_probe(struct platform_device *pdev)
goto err_wq;
}
 
-   xgbe_ptp_register(pdata);
+   if (IS_REACHABLE(CONFIG_PTP_1588_CLOCK))
+   xgbe_ptp_register(pdata);
 
xgbe_debugfs_init(pdata);
 
@@ -812,7 +813,8 @@ static int xgbe_remove(struct platform_device *pdev)
 
xgbe_debugfs_exit(pdata);
 
-   xgbe_ptp_unregister(pdata);
+   if (IS_REACHABLE(CONFIG_PTP_1588_CLOCK))
+   xgbe_ptp_unregister(pdata);
 
flush_workqueue(pdata->an_workqueue);
destroy_workqueue(pdata->an_workqueue);
diff --git a/drivers/net/ethernet/broadcom/Kconfig 
b/drivers/net/ethernet/broadcom/Kconfig
index bd8c80c0b7..9c53786a5c 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -110,7 +110,7 @@ config TIGON3
depends on PCI
select PHYLIB
select HWMON
-   select PTP_1588_CLOCK
+   select PTP_1588_CLOCK_DEFAULT
---help---
  This driver supports Broadcom Tigon3 based gigabit Ethernet cards.
 
@@ -120,7

Re: qemu:metag image runtime failure in -next due to 'kthread: allow to cancel kthread work'

2016-09-16 Thread Kees Cook

On Fri, Sep 16, 2016 at 4:32 PM, James Hogan  wrote:
> On Fri, Sep 16, 2016 at 02:37:18PM -0700, Guenter Roeck wrote:
>> On Fri, Sep 16, 2016 at 10:27:20PM +0100, James Hogan wrote:
>> > On Fri, Sep 16, 2016 at 01:38:19PM -0700, Guenter Roeck wrote:
>> > > Hi,
>> > >
>> > > I see the following runtime error in -next when running a metag qemu 
>> > > emulation.
>> > >
>> > > [ ... ]
>> > > workingset: timestamp_bits=30 max_order=16 bucket_order=0
>> > > io scheduler noop registered (default)
>> > > brd: module loaded
>> > > Warning: unable to open an initial console.
>> > > List of all partitions:
>> > > 0100   16384 ram0  (driver?)
>> > > No filesystem could mount root, tried:
>> > > Kernel panic - not syncing: VFS: Unable to mount root fs on 
>> > > unknown-block(1,0)
>> > >
>> > > An example for a complete log is at:
>> > > http://kerneltests.org/builders/qemu-metag-next/builds/489/steps/qemubuildcommand/logs/stdio
>> > >
>> > > bisect points to commit ef98de028afde ("kthread: allow to cancel kthread 
>> > > work").
>> > > I don't know (yet) if other architectures are affected. bisect log is 
>> > > attached.
>> > >
>> > > The scripts to run this test are available at
>> > > https://github.com/groeck/linux-build-test/tree/master/rootfs/metag.
>> > >
>> > > Guenter
>> >
>> > Thanks Guenter,
>> >
>> > It appears to be related to the command line. After that commit the
>> > command line is shown as empty (rather than your "rdinit=/sbin/init
>> > doreboot"), but it can still be overridden in the config and then it
>> > continues to work.
>> >
>> Weird.
>
> Previously the Elf had a single load program header:
>
> Program Headers:
>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD   0x004000 0x4000 0x4000 0x34b304 0x376230 RWE 0x4000
>   NOTE   0x1ecc08 0x401e8c08 0x401e8c08 0x0 0x0 R   0x4
>
> QEMU puts the args at 40376230, straight after the load region (unlike a
> real Meta Linux bootloader).
>
> After the above commit the ELF gets two load program headers, with a
> small alignment gap in the middle:
>
> Program Headers:
>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD   0x004000 0x4000 0x4000 0x18f118 0x18f118 R E 0x4000
>   LOAD   0x194000 0x4019 0x4019 0x1bd304 0x1e8230 RWE 0x4000
>   NOTE   0x1eec08 0x401eac08 0x401eac08 0x0 0x0 R   0x4
>
> Here this version of QEMU puts the args at where it thinks the end of
> the loaded image is, which is based on the number of bytes copied from
> the ELF, i.e. the total MemSiz's, not taking into account the alignment
> gap in between, so it puts them at 0x40377348.
>
> But of course:
> 40378230 B ___bss_stop
>
> so it wipes them out while clearing bss during early init.
>
> Previously:
> 4018ebd0 T __sdata
> 4018f000 R ___start_rodata
>
> now:
> 4018ed98 T __sdata
> 4019 R ___start_rodata
>
> So I'm thinking this may have been triggered by c74ba8b3480d ("arch:
> Introduce post-init read-only memory").
>
> The hack below does indeed reduce it to a single load section and this
> version of QEMU then succeeds:
>
> Program Headers:
>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD   0x004000 0x4000 0x4000 0x34d304 0x378230 RWE 0x4000
>   NOTE   0x1eec88 0x401eac88 0x401eac88 0x0 0x0 R   0x4
>
> diff --git a/arch/metag/include/asm/cache.h b/arch/metag/include/asm/cache.h
> index a43b650cfdc0..b5c7364a94da 100644
> --- a/arch/metag/include/asm/cache.h
> +++ b/arch/metag/include/asm/cache.h
> @@ -20,4 +20,6 @@
>
>  #define __read_mostly __attribute__((__section__(".data..read_mostly")))
>
> +#define __ro_after_init__read_mostly
> +
>  #endif
>
> Kees: Is it expected to get multiple load headers like this since your
> patch c74ba8b3480d ("arch: Introduce post-init read-only memory"),
> depending on alignment of the read only section?

I'm not expecting that, and I'm especially not expecting any LOAD to
have "RWE" flags. It looks like metag's vmlinux.lds.S is using the
common RO_DATA_SECTION, so that doesn't jump out at me as a reason for
RO_AFTER_INIT_DATA to end up in the wrong place. Also the second LOAD
in the ELF is really huge, so it's not just the RO_AFTER_INIT_DATA
section (which is currently very small).

Could the metag linker be failing to override the section flags when
putting RO_AFTER_INIT_DATA into RO_DATA_SECTION and this cuts the LOAD
in half? This smells like a linker glitch.

However, since metag doesn't support CONFIG_DEBUG_RODATA, your above
patch is likely correct. If metag marks memory read-only at kernel
load time, it's doing it early enough that __ro_after_init will fail
to work. If it never marks memory read-only, then __ro_after_init will
have no effect. (i.e. Both situations need the proposed patch).

Probably the best solution for all architectures is to invent a new
CONFIG_ARCH_HAS... to identify the style of

Re: [PATCH v3) posix-timers: make it configurable

2016-09-16 Thread Nicolas Pitre

On Fri, 16 Sep 2016, Richard Cochran wrote:

> On Thu, Sep 15, 2016 at 02:56:49PM -0700, Josh Triplett wrote:
> > > I suspect there is more of a case for having net drivers _without_ ptp 
> > > support.  This could be implemented with a ptp_clock_register() stub 
> > > returning NULL when ptp is not configured.  I didn't look at most 
> > > drivers but at least broadcom/tg3.c seems to be fine with such an 
> > > approach.
> 
> (I wouldn't be suprised if some drivers fail to deal with NULL
> gracefully, but those can always be fixed ;)

I've looked at all of them and I think they should be fine with the 
minor changes I've included below.  Tested with allyesconfig and 
CONFIG_POSIX_TIMERS=n.

- >8
Subject: [PATCH] ptp_clock: allow for it to be optional

In order to break the hard dependency between the PTP clock subsystem and
ethernet drivers capable of being clock providers, this patch provides
simple PTP stub functions to allow linkage of those drivers into the
kernel even when the PTP subsystem is configured out.

And to make it possible for PTP to be configured out, the select statement
in the Kconfig entry for those ethernet drivers is changed from selecting
PTP_1588_CLOCK to PTP_1588_CLOCK_DEFAULT whose purpose is to indicate the
default Kconfig value for the PTP subsystem.

This way the PTP subsystem may have Kconfig dependencies of its own, such
as POSIX_TIMERS, without making those ethernet drivers unavailable if
POSIX timers are cconfigured out. And when support for POSIX timers is
selected again then PTP clock support will also be selected accordingly.

Drivers must be ready to accept NULL from ptp_clock_register().
The pch_gbe driver is a bit special as it relies on extra code in
drivers/ptp/ptp_pch.c. Therefore we let the make process descend into
drivers/ptp/ even if PTP_1588_CLOCK is unselected.

Signed-off-by: Nicolas Pitre 

diff --git a/drivers/Makefile b/drivers/Makefile
index 53abb4a5f7..8a538d0856 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -105,7 +105,7 @@ obj-$(CONFIG_INPUT) += input/
 obj-$(CONFIG_RTC_LIB)  += rtc/
 obj-y  += i2c/ media/
 obj-$(CONFIG_PPS)  += pps/
-obj-$(CONFIG_PTP_1588_CLOCK)   += ptp/
+obj-y  += ptp/
 obj-$(CONFIG_W1)   += w1/
 obj-y  += power/
 obj-$(CONFIG_HWMON)+= hwmon/
diff --git a/drivers/net/ethernet/adi/Kconfig b/drivers/net/ethernet/adi/Kconfig
index 6b94ba6103..eea414337c 100644
--- a/drivers/net/ethernet/adi/Kconfig
+++ b/drivers/net/ethernet/adi/Kconfig
@@ -55,10 +55,14 @@ config BFIN_RX_DESC_NUM
---help---
  Set the number of buffer packets used in driver.
 
+config BFIN_MAC_HAS_HWSTAMP
+   def_tristate BFIN_MAC
+   depends on BF518
+   select PTP_1588_CLOCK_DEFAULT
+
 config BFIN_MAC_USE_HWSTAMP
bool "Use IEEE 1588 hwstamp"
-   depends on BFIN_MAC && BF518
-   select PTP_1588_CLOCK
+   depends on BFIN_MAC_HAS_HWSTAMP && PTP_1588_CLOCK
default y
---help---
  To support the IEEE 1588 Precision Time Protocol (PTP), select y here
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 0038709fd3..c2aaa5f949 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -177,7 +177,7 @@ config AMD_XGBE
depends on ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
-   select PTP_1588_CLOCK
+   select PTP_1588_CLOCK_DEFAULT
---help---
  This driver supports the AMD 10GbE Ethernet device found on an
  AMD SoC.
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-main.c 
b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
index 3eee3201b5..4aeeb018b6 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-main.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
@@ -773,7 +773,8 @@ static int xgbe_probe(struct platform_device *pdev)
goto err_wq;
}
 
-   xgbe_ptp_register(pdata);
+   if (IS_REACHABLE(CONFIG_PTP_1588_CLOCK))
+   xgbe_ptp_register(pdata);
 
xgbe_debugfs_init(pdata);
 
@@ -812,7 +813,8 @@ static int xgbe_remove(struct platform_device *pdev)
 
xgbe_debugfs_exit(pdata);
 
-   xgbe_ptp_unregister(pdata);
+   if (IS_REACHABLE(CONFIG_PTP_1588_CLOCK))
+   xgbe_ptp_unregister(pdata);
 
flush_workqueue(pdata->an_workqueue);
destroy_workqueue(pdata->an_workqueue);
diff --git a/drivers/net/ethernet/broadcom/Kconfig 
b/drivers/net/ethernet/broadcom/Kconfig
index bd8c80c0b7..9c53786a5c 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -110,7 +110,7 @@ config TIGON3
depends on PCI
select PHYLIB
select HWMON
-   select PTP_1588_CLOCK
+   select PTP_1588_CLOCK_DEFAULT
---help---
  This driver supports Broadcom Tigon3 based gigabit Ethernet cards.
 
@@ -120,7 +120,7 @@ config

Re: [PATCH -next] ASoC: rt5663: fix sparse warnings

2016-09-16 Thread kbuild test robot

Hi Wei,

[auto build test WARNING on next-20160916]

url:
https://github.com/0day-ci/linux/commits/Wei-Yongjun/ASoC-rt5663-fix-sparse-warnings/20160917-094530


coccinelle warnings: (new ones prefixed by >>)

>> sound/soc/codecs/rt5663.c:3203:3-8: No need to set .owner here. The core 
>> will do it.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[PATCH] ASoC: rt5663: fix platform_no_drv_owner.cocci warnings

2016-09-16 Thread kbuild test robot

sound/soc/codecs/rt5663.c:3203:3-8: No need to set .owner here. The core will 
do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Wei Yongjun 
Signed-off-by: Fengguang Wu 
---

 rt5663.c |1 -
 1 file changed, 1 deletion(-)

--- a/sound/soc/codecs/rt5663.c
+++ b/sound/soc/codecs/rt5663.c
@@ -3200,7 +3200,6 @@ static void rt5663_i2c_shutdown(struct i
 static struct i2c_driver rt5663_i2c_driver = {
.driver = {
.name = "rt5663",
-   .owner = THIS_MODULE,
.acpi_match_table = ACPI_PTR(rt5663_acpi_match),
.of_match_table = of_match_ptr(rt5663_of_match),
},

Re: [PATCH -next] ASoC: rt5663: fix sparse warnings

2016-09-16 Thread kbuild test robot

Hi Wei,

[auto build test WARNING on next-20160916]

url:
https://github.com/0day-ci/linux/commits/Wei-Yongjun/ASoC-rt5663-fix-sparse-warnings/20160917-094530


coccinelle warnings: (new ones prefixed by >>)

>> sound/soc/codecs/rt5663.c:3203:3-8: No need to set .owner here. The core 
>> will do it.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[PATCH] ASoC: rt5663: fix platform_no_drv_owner.cocci warnings

2016-09-16 Thread kbuild test robot

sound/soc/codecs/rt5663.c:3203:3-8: No need to set .owner here. The core will 
do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Wei Yongjun 
Signed-off-by: Fengguang Wu 
---

 rt5663.c |1 -
 1 file changed, 1 deletion(-)

--- a/sound/soc/codecs/rt5663.c
+++ b/sound/soc/codecs/rt5663.c
@@ -3200,7 +3200,6 @@ static void rt5663_i2c_shutdown(struct i
 static struct i2c_driver rt5663_i2c_driver = {
.driver = {
.name = "rt5663",
-   .owner = THIS_MODULE,
.acpi_match_table = ACPI_PTR(rt5663_acpi_match),
.of_match_table = of_match_ptr(rt5663_of_match),
},

Re: [PATCH v2] scripts: add script for translating stack dump function offsets

2016-09-16 Thread Linus Torvalds

On Fri, Sep 16, 2016 at 6:59 PM, Linus Torvalds
 wrote:
>
> And finally, I suspect (5) is not reasonably fixable. Oh well. It
> would require some kind of "figure out the largest common prefix of
> all the filenames in the whole object file". So I'm *not* talking
> about just passing "--basenames" to addr2line.
>
> Hmm. Maybe looking up the "DW_AT_comp_dir" tag in the debug info would
> work? And just stripping that off?

Thinking more about this, that actually sounds like it might be the
right thing to do.

It doesn't work for most projects, but the way the kernel build system
is set up, we don't actually recursively descend into subdirectories,
we always build at the top level. So DW_AT_comp_dir should always (?)
be the actual top-level build directory, and we could just scrape that
off from the addr2line output.

That said, I don't even know what the "real" way to dump the debug
symbol data is. I do *not* believe that you should use

  readelf -W --debug-dump vmlinux | grep DW_AT_comp_dir | head -1

to get the information. There is bound to be something much better.
Somebody who knows the ELF tools can now pipe in and show the world
what a maroon I am.

   Linus

Re: [PATCH v2] scripts: add script for translating stack dump function offsets

2016-09-16 Thread Linus Torvalds

On Fri, Sep 16, 2016 at 6:59 PM, Linus Torvalds
 wrote:
>
> And finally, I suspect (5) is not reasonably fixable. Oh well. It
> would require some kind of "figure out the largest common prefix of
> all the filenames in the whole object file". So I'm *not* talking
> about just passing "--basenames" to addr2line.
>
> Hmm. Maybe looking up the "DW_AT_comp_dir" tag in the debug info would
> work? And just stripping that off?

Thinking more about this, that actually sounds like it might be the
right thing to do.

It doesn't work for most projects, but the way the kernel build system
is set up, we don't actually recursively descend into subdirectories,
we always build at the top level. So DW_AT_comp_dir should always (?)
be the actual top-level build directory, and we could just scrape that
off from the addr2line output.

That said, I don't even know what the "real" way to dump the debug
symbol data is. I do *not* believe that you should use

  readelf -W --debug-dump vmlinux | grep DW_AT_comp_dir | head -1

to get the information. There is bound to be something much better.
Somebody who knows the ELF tools can now pipe in and show the world
what a maroon I am.

   Linus

Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

2016-09-16 Thread Guenter Roeck


On 09/16/2016 04:32 PM, Rich Felker wrote:
[ ... ]


It would be useful to know what compiler version was used to build the
kernel. I wouldn't be surprised if some are buggy.


4.6.3 from kernel.org.


That is utterly ancient and probaby very buggy. I would recommend 5.x+
or at the very least 4.7 or 4.8.


I found a toolchain with 5.3.0, and using it the problem disappears. Oh well.
Sorry for the noise.

Guenter

Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

2016-09-16 Thread Guenter Roeck


On 09/16/2016 04:32 PM, Rich Felker wrote:
[ ... ]


It would be useful to know what compiler version was used to build the
kernel. I wouldn't be surprised if some are buggy.


4.6.3 from kernel.org.


That is utterly ancient and probaby very buggy. I would recommend 5.x+
or at the very least 4.7 or 4.8.


I found a toolchain with 5.3.0, and using it the problem disappears. Oh well.
Sorry for the noise.

Guenter

Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

2016-09-16 Thread Guenter Roeck


On 09/16/2016 04:32 PM, Rich Felker wrote:

4.6.3 from kernel.org.


That is utterly ancient and probaby very buggy. I would recommend 5.x+
or at the very least 4.7 or 4.8.


Unfortunately that is the latest one available from kernel.org :-(.
I'll try to build one myself.

Thanks,
Guenter

Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

2016-09-16 Thread Guenter Roeck


On 09/16/2016 04:32 PM, Rich Felker wrote:

4.6.3 from kernel.org.


That is utterly ancient and probaby very buggy. I would recommend 5.x+
or at the very least 4.7 or 4.8.


Unfortunately that is the latest one available from kernel.org :-(.
I'll try to build one myself.

Thanks,
Guenter

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1654 matches

Mail list logo