linux-next: manual merge of the scsi-mkp tree with Linus' tree

[Stephen Rothwell]

Hi Martin,

Today's linux-next merge of the scsi-mkp tree got a conflict in:

  drivers/scsi/qla2xxx/qla_os.c

between commit:

  2b5b96473efc ("scsi: qla2xxx: Fix FC-NVMe LUN discovery")

from Linus' tree and commit:

  33b28357dd00 ("scsi: qla2xxx: Fix Async GPN_FT for FCP and FC-NVMe scan")

from the scsi-mkp tree.

I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpAoQJDoZnav.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the scsi-mkp tree with Linus' tree

[Stephen Rothwell]

Hi Martin,

Today's linux-next merge of the scsi-mkp tree got a conflict in:

  drivers/scsi/qla2xxx/qla_os.c

between commit:

  2b5b96473efc ("scsi: qla2xxx: Fix FC-NVMe LUN discovery")

from Linus' tree and commit:

  33b28357dd00 ("scsi: qla2xxx: Fix Async GPN_FT for FCP and FC-NVMe scan")

from the scsi-mkp tree.

I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpAoQJDoZnav.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the sound-asoc tree

[Mukunda,Vijendar]

On Thursday 22 March 2018 07:08 AM, Mark Brown wrote:

On Wed, Mar 21, 2018 at 11:15:16AM +0530, Mukunda,Vijendar wrote:


There is a patch dependency .
Below patch not merged yet. We submitted for upstream review.
[PATCH V2] ASoC: dwc: I2S Controller instance param added

You need to mention dependencies between patches when publishing and I
don't seem to have a copy of that patch, according to the list archives
Alex asked you to make some chnages to it.


   Changes suggested by Alex already implemented and posted .
   Current patch (https://patchwork.kernel.org/patch/10298281/ ) is
   dependent on below patch.

   https://patchwork.kernel.org/patch/10296597/

   We will publish patch dependencies while sending patches.

Re: linux-next: build failure after merge of the sound-asoc tree

[Mukunda,Vijendar]

On Thursday 22 March 2018 07:08 AM, Mark Brown wrote:

On Wed, Mar 21, 2018 at 11:15:16AM +0530, Mukunda,Vijendar wrote:


There is a patch dependency .
Below patch not merged yet. We submitted for upstream review.
[PATCH V2] ASoC: dwc: I2S Controller instance param added

You need to mention dependencies between patches when publishing and I
don't seem to have a copy of that patch, according to the list archives
Alex asked you to make some chnages to it.


   Changes suggested by Alex already implemented and posted .
   Current patch (https://patchwork.kernel.org/patch/10298281/ ) is
   dependent on below patch.

   https://patchwork.kernel.org/patch/10296597/

   We will publish patch dependencies while sending patches.

[RESEND PATCH] mfd: sprd: Add one syscon cell to access PMIC global registers

[Baolin Wang]

There are some global registers in Spreadtrum sc27xx PMICs, which will
be accessed by other drivers. So this patch adds one syscon cell to
help to access the PMIC's global registers.

Signed-off-by: Baolin Wang 
---
 drivers/mfd/sprd-sc27xx-spi.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mfd/sprd-sc27xx-spi.c b/drivers/mfd/sprd-sc27xx-spi.c
index 56a4782..3460ef0 100644
--- a/drivers/mfd/sprd-sc27xx-spi.c
+++ b/drivers/mfd/sprd-sc27xx-spi.c
@@ -111,6 +111,9 @@ struct sprd_pmic_data {
}, {
.name = "sc27xx-poweroff",
.of_compatible = "sprd,sc27xx-poweroff",
+   }, {
+   .name = "sc27xx-syscon",
+   .of_compatible = "sprd,sc27xx-syscon",
},
 };
 
-- 
1.7.9.5

[RESEND PATCH] mfd: sprd: Add one syscon cell to access PMIC global registers

[Baolin Wang]

There are some global registers in Spreadtrum sc27xx PMICs, which will
be accessed by other drivers. So this patch adds one syscon cell to
help to access the PMIC's global registers.

Signed-off-by: Baolin Wang 
---
 drivers/mfd/sprd-sc27xx-spi.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mfd/sprd-sc27xx-spi.c b/drivers/mfd/sprd-sc27xx-spi.c
index 56a4782..3460ef0 100644
--- a/drivers/mfd/sprd-sc27xx-spi.c
+++ b/drivers/mfd/sprd-sc27xx-spi.c
@@ -111,6 +111,9 @@ struct sprd_pmic_data {
}, {
.name = "sc27xx-poweroff",
.of_compatible = "sprd,sc27xx-poweroff",
+   }, {
+   .name = "sc27xx-syscon",
+   .of_compatible = "sprd,sc27xx-syscon",
},
 };
 
-- 
1.7.9.5

RE: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add documentation for controller and driver

[Naga Sureshkumar Relli]

Hi Miquel,

Thanks for reviewing the patch series.
Please see my comments below.

> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Tuesday, March 20, 2018 2:38 AM
> To: nagasureshkumarre...@gmail.com
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com;
> cyrille.pitc...@wedev4u.fr; linux-...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Michal Simek ; Punnaiah
> Choudary Kalluri ; Naga Sureshkumar Relli
> 
> Subject: Re: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add
> documentation for controller and driver
> 
> Hi naga,
> 
> On Wed, 14 Mar 2018 16:18:14 +0530, 
> wrote:
> 
> > From: Naga Sureshkumar Relli 
> >
> > Added notes about the controller and driver
> >
> > Signed-off-by: Naga Sureshkumar Relli 
> > ---
> > Changes in v8
> >  - None
> > Changes in v7:
> > - None
> > Changes in v6:
> > - None
> > Changes in v5:
> > - Fixed the review comments
> > Changes in v4:
> > - None
> > ---
> >  Documentation/mtd/nand/pl353-nand.txt | 92
> > +++
> >  1 file changed, 92 insertions(+)
> >  create mode 100644 Documentation/mtd/nand/pl353-nand.txt
> >
> > diff --git a/Documentation/mtd/nand/pl353-nand.txt
> > b/Documentation/mtd/nand/pl353-nand.txt
> > new file mode 100644
> > index 000..ac6fbd5
> > --- /dev/null
> > +++ b/Documentation/mtd/nand/pl353-nand.txt
> > @@ -0,0 +1,92 @@
> > +This documents provides some notes about the ARM pl353 smc controller
> > +used in Zynq SOC and confined to NAND specific details.
> > +
> > +Overview of the controller
> > +==
> > +   The SMC (PL353) supports two memory interfaces:
> > +   Interface 0 type SRAM.
> > +   Interface 1 type NAND.
> > +   This configuration supports the following configurable options:
> > +  . 32-bit or 64-bit AXI data width
> > +  . 8-bit, 16-bit, or 32-bit memory data width for interface 0
> > +  . 8-bit, or 16-bit memory data width for interface 1
> > +  . 1-4 chip selects on each interface
> > +  . SLC ECC block for interface 1
> > +
> > +For more information, refer the below link for TRM
> > +http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/
> > +DDI0380G_smc_pl350_series_r2p1_trm.pdf
> 
> I think it is better to do not break the links?
I will correct it in next patch.
> 
> > +
> > +NAND memory accesses
> > +
> > +   . Two phase NAND accesses
> > +   . NAND command phase transfers
> > +   . NAND data phase transfers
> > +
> > +Two phase NAND accesses
> > +   The SMC defines two phases of commands when transferring data to or
> > +from NAND flash.
> > +
> > +Command phase
> > +   Commands and optional address information are written to the NAND
> flash.
> > +The command and address can be associated with either a data phase
> > +operation to write to or read from the array, or a status/ID register 
> > transfer.
> > +
> > +Data phase
> > + Data is either written to or read from the NAND flash. This data can
> > +be either data transferred to or from the array, or status/ID register
> information.
> > +
> > +NAND AXI address setup
> > +   AXI address  Command phase  Data phase
> > +   [31:24] Chip address   Chip address
> > +   [23]NoOfAddCycles_2Reserved
> > +   [22]NoOfAddCycles_1Reserved
> > +   [21]NoOfAddCycles_0ClearCS
> > +   [20]End command valid  End command valid
> > +   [19]0  1
> > +   [18:11] End commandEnd command
> > +   [10:3]  Start command  [10] ECC Last
> > +  [9:3] Reserved
> > +   [2:0]   Reserved   Reserved
> > +
> > +ECC
> > +===
> > +It operates on a number of 512 byte blocks of NAND memory and can
> > +be programmed to store the ECC codes after the data in memory. For
> > +writes, the ECC is written to the spare area of the page. For reads,
> > +the result of a block ECC check are made available to the device driver.
> > +
> > +-
> > +---
> > +|   n * 512 blocks  | extra  | ecc| |
> > +|   | block  | codes  | |
> > +-
> > +---
> > +
> > +The ECC calculation uses a simple Hamming code, using 1-bit
> > +correction 2-bit detection. It starts when a valid read or write
> > +command with a 512 byte aligned address is detected on the memory
> interface.
> > +
> > +Driver details
> > +==
> > +   The NAND driver has dependency with the pl353_smc memory
> controller
> > +driver for intializing the nand timing parameters, bus width, ECC
> > 

RE: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add documentation for controller and driver

[Naga Sureshkumar Relli]

Hi Miquel,

Thanks for reviewing the patch series.
Please see my comments below.

> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Tuesday, March 20, 2018 2:38 AM
> To: nagasureshkumarre...@gmail.com
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com;
> cyrille.pitc...@wedev4u.fr; linux-...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Michal Simek ; Punnaiah
> Choudary Kalluri ; Naga Sureshkumar Relli
> 
> Subject: Re: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add
> documentation for controller and driver
> 
> Hi naga,
> 
> On Wed, 14 Mar 2018 16:18:14 +0530, 
> wrote:
> 
> > From: Naga Sureshkumar Relli 
> >
> > Added notes about the controller and driver
> >
> > Signed-off-by: Naga Sureshkumar Relli 
> > ---
> > Changes in v8
> >  - None
> > Changes in v7:
> > - None
> > Changes in v6:
> > - None
> > Changes in v5:
> > - Fixed the review comments
> > Changes in v4:
> > - None
> > ---
> >  Documentation/mtd/nand/pl353-nand.txt | 92
> > +++
> >  1 file changed, 92 insertions(+)
> >  create mode 100644 Documentation/mtd/nand/pl353-nand.txt
> >
> > diff --git a/Documentation/mtd/nand/pl353-nand.txt
> > b/Documentation/mtd/nand/pl353-nand.txt
> > new file mode 100644
> > index 000..ac6fbd5
> > --- /dev/null
> > +++ b/Documentation/mtd/nand/pl353-nand.txt
> > @@ -0,0 +1,92 @@
> > +This documents provides some notes about the ARM pl353 smc controller
> > +used in Zynq SOC and confined to NAND specific details.
> > +
> > +Overview of the controller
> > +==
> > +   The SMC (PL353) supports two memory interfaces:
> > +   Interface 0 type SRAM.
> > +   Interface 1 type NAND.
> > +   This configuration supports the following configurable options:
> > +  . 32-bit or 64-bit AXI data width
> > +  . 8-bit, 16-bit, or 32-bit memory data width for interface 0
> > +  . 8-bit, or 16-bit memory data width for interface 1
> > +  . 1-4 chip selects on each interface
> > +  . SLC ECC block for interface 1
> > +
> > +For more information, refer the below link for TRM
> > +http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/
> > +DDI0380G_smc_pl350_series_r2p1_trm.pdf
> 
> I think it is better to do not break the links?
I will correct it in next patch.
> 
> > +
> > +NAND memory accesses
> > +
> > +   . Two phase NAND accesses
> > +   . NAND command phase transfers
> > +   . NAND data phase transfers
> > +
> > +Two phase NAND accesses
> > +   The SMC defines two phases of commands when transferring data to or
> > +from NAND flash.
> > +
> > +Command phase
> > +   Commands and optional address information are written to the NAND
> flash.
> > +The command and address can be associated with either a data phase
> > +operation to write to or read from the array, or a status/ID register 
> > transfer.
> > +
> > +Data phase
> > + Data is either written to or read from the NAND flash. This data can
> > +be either data transferred to or from the array, or status/ID register
> information.
> > +
> > +NAND AXI address setup
> > +   AXI address  Command phase  Data phase
> > +   [31:24] Chip address   Chip address
> > +   [23]NoOfAddCycles_2Reserved
> > +   [22]NoOfAddCycles_1Reserved
> > +   [21]NoOfAddCycles_0ClearCS
> > +   [20]End command valid  End command valid
> > +   [19]0  1
> > +   [18:11] End commandEnd command
> > +   [10:3]  Start command  [10] ECC Last
> > +  [9:3] Reserved
> > +   [2:0]   Reserved   Reserved
> > +
> > +ECC
> > +===
> > +It operates on a number of 512 byte blocks of NAND memory and can
> > +be programmed to store the ECC codes after the data in memory. For
> > +writes, the ECC is written to the spare area of the page. For reads,
> > +the result of a block ECC check are made available to the device driver.
> > +
> > +-
> > +---
> > +|   n * 512 blocks  | extra  | ecc| |
> > +|   | block  | codes  | |
> > +-
> > +---
> > +
> > +The ECC calculation uses a simple Hamming code, using 1-bit
> > +correction 2-bit detection. It starts when a valid read or write
> > +command with a 512 byte aligned address is detected on the memory
> interface.
> > +
> > +Driver details
> > +==
> > +   The NAND driver has dependency with the pl353_smc memory
> controller
> > +driver for intializing the nand timing parameters, bus width, ECC
> > +modes,
> 
>   ^NAND
> 
> > +control and status information.
> > +
> > +Since the controller expects that the 

Re: [RFC PATCH] cpufreq: Calling init() of cpufreq_driver when policy inactive cpu online

[Yang, Shunyong]

Hi, Kumar

On Thu, 2018-03-22 at 11:30 +0800, Viresh Kumar wrote:
> On 21-03-18, 18:21, Shunyong Yang wrote:
> > 
> > When multiple cpus are related in one cpufreq policy, the first
> > online cpu
> > will be chosen by default to handle cpufreq operations. In a CPPC
> > case,
> > let's take two related cpus, cpu0 and cpu1 as an example.
> > 
> > After system start, cpu0 is the first online cpu. Cpufreq policy
> > will be
> > allocated and init() in cpufreq_driver will be called to initialize
> > cpu0's
> > perf capabilities and policy parameters.
> Not exactly. The init() is called to initialize stuff for all the
> CPUs that
> should be part of policy->related_cpus after init() has returned. So
> you should
> initialize perf capabilities for all of them.

In page 533 of ACPI 6.2 specificaiton, it says,

"Starting with ACPI Specification 6.2, all _CPC registers can be in
PCC, System Memory, System IO, or Functional Fixed Hardware address
spaces. OSPM support for this more flexible register space scheme is
indicated by the “Flexible Address Space for CPPC Registers” _OSC bit."

As _CPC register maybe in System Memory, System IO, or Functional Fixed
Hardware address spaces. I am not sure all architecture implementing
CPPC can return correct value before CPU come into online. That's the
reason I add the extra init() call.

BTW, I've tested on QDF2400 platform and it return correct value when
cpu1 is offline.

Do you know whether firmware can guarantee correct perf capabilities
regardless of CPU online/offline?

> 
> > 
> > When cpu1 is online, current code
> > will not call init() in cpufreq_driver as policy has been allocated
> > and
> > activated by cpu0. So, cpu1's perf capabilities are not initialized
> > (all 0s).
> > 
> > When cpu0 is offline, policy->cpu will be shifted to cpu1. As
> > cpu1's perf
> > capabilities are 0s, speed change will not take effect when setting
> > speed.
> > 
> > This patch adds calling init() of cpufreq_driver when policy
> > inactive cpu
> > comes to online.
> No CPU should be inactive here, its just that you haven't initialized
> it
> properly.
> 

I mean the policy is handled(active) by the first online cpu's (cpu0)
perf capabilities. Not handled (inactive) by the one's just come into
online (cpu1). Sorry for this.

Thanks.
Shunyong.


> And we are not going to call init() multiple times for a group of
> CPUs. That's
> not what the purpose of init() is.
> 

Re: [RFC PATCH] cpufreq: Calling init() of cpufreq_driver when policy inactive cpu online

[Yang, Shunyong]

Hi, Kumar

On Thu, 2018-03-22 at 11:30 +0800, Viresh Kumar wrote:
> On 21-03-18, 18:21, Shunyong Yang wrote:
> > 
> > When multiple cpus are related in one cpufreq policy, the first
> > online cpu
> > will be chosen by default to handle cpufreq operations. In a CPPC
> > case,
> > let's take two related cpus, cpu0 and cpu1 as an example.
> > 
> > After system start, cpu0 is the first online cpu. Cpufreq policy
> > will be
> > allocated and init() in cpufreq_driver will be called to initialize
> > cpu0's
> > perf capabilities and policy parameters.
> Not exactly. The init() is called to initialize stuff for all the
> CPUs that
> should be part of policy->related_cpus after init() has returned. So
> you should
> initialize perf capabilities for all of them.

In page 533 of ACPI 6.2 specificaiton, it says,

"Starting with ACPI Specification 6.2, all _CPC registers can be in
PCC, System Memory, System IO, or Functional Fixed Hardware address
spaces. OSPM support for this more flexible register space scheme is
indicated by the “Flexible Address Space for CPPC Registers” _OSC bit."

As _CPC register maybe in System Memory, System IO, or Functional Fixed
Hardware address spaces. I am not sure all architecture implementing
CPPC can return correct value before CPU come into online. That's the
reason I add the extra init() call.

BTW, I've tested on QDF2400 platform and it return correct value when
cpu1 is offline.

Do you know whether firmware can guarantee correct perf capabilities
regardless of CPU online/offline?

> 
> > 
> > When cpu1 is online, current code
> > will not call init() in cpufreq_driver as policy has been allocated
> > and
> > activated by cpu0. So, cpu1's perf capabilities are not initialized
> > (all 0s).
> > 
> > When cpu0 is offline, policy->cpu will be shifted to cpu1. As
> > cpu1's perf
> > capabilities are 0s, speed change will not take effect when setting
> > speed.
> > 
> > This patch adds calling init() of cpufreq_driver when policy
> > inactive cpu
> > comes to online.
> No CPU should be inactive here, its just that you haven't initialized
> it
> properly.
> 

I mean the policy is handled(active) by the first online cpu's (cpu0)
perf capabilities. Not handled (inactive) by the one's just come into
online (cpu1). Sorry for this.

Thanks.
Shunyong.


> And we are not going to call init() multiple times for a group of
> CPUs. That's
> not what the purpose of init() is.
> 

[PATCH] Documentation: Mention why %p prints ptrval

[Joel Stanley]

When debugging recent kernels, people will see '(ptrval)' but there
isn't much information as to what that means. Briefly describe why it's
there.

Signed-off-by: Joel Stanley 
---
 Documentation/core-api/printk-formats.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/core-api/printk-formats.rst 
b/Documentation/core-api/printk-formats.rst
index 934559b3c130..eb30efdd2e78 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -60,8 +60,8 @@ Plain Pointers
 Pointers printed without a specifier extension (i.e unadorned %p) are
 hashed to prevent leaking information about the kernel memory layout. This
 has the added benefit of providing a unique identifier. On 64-bit machines
-the first 32 bits are zeroed. If you *really* want the address see %px
-below.
+the first 32 bits are zeroed. The kernel will print ``(ptrval)`` until it
+gathers enough entropy. If you *really* want the address see %px below.
 
 Symbols/Function Pointers
 -
-- 
2.15.1

[PATCH] Documentation: Mention why %p prints ptrval

[Joel Stanley]

When debugging recent kernels, people will see '(ptrval)' but there
isn't much information as to what that means. Briefly describe why it's
there.

Signed-off-by: Joel Stanley 
---
 Documentation/core-api/printk-formats.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/core-api/printk-formats.rst 
b/Documentation/core-api/printk-formats.rst
index 934559b3c130..eb30efdd2e78 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -60,8 +60,8 @@ Plain Pointers
 Pointers printed without a specifier extension (i.e unadorned %p) are
 hashed to prevent leaking information about the kernel memory layout. This
 has the added benefit of providing a unique identifier. On 64-bit machines
-the first 32 bits are zeroed. If you *really* want the address see %px
-below.
+the first 32 bits are zeroed. The kernel will print ``(ptrval)`` until it
+gathers enough entropy. If you *really* want the address see %px below.
 
 Symbols/Function Pointers
 -
-- 
2.15.1

Re: [PATCH v10] mmc: Export host capabilities to debugfs.

[Harish Jenny K N]

On Friday 16 March 2018 01:27 PM, Ulf Hansson wrote:
> On 16 March 2018 at 05:20, Harish Jenny K N  wrote:
>>
>> On Thursday 15 March 2018 05:59 PM, Ulf Hansson wrote:
>>> On 15 March 2018 at 11:26, Andy Shevchenko
>>>  wrote:
 On Thu, 2018-03-15 at 11:12 +0100, Ulf Hansson wrote:
> On 13 March 2018 at 06:10, Harish Jenny K N > wrote:
>>
> Honestly, I don't like this, but maybe other people do, then I am fine
> with this approach.
>
> If were to decide, I would just rather print the caps field in a
> hexadecimal bit form and leave the translation to the user.
 A compromise would be to print both:

 0x\n
 Description of each enabled field, one per line


 Another format would be:

 Bit XX: Description of a field
>>> If we were to print the description, there is no point in printing the
>>> bits in hex. Or is it?
>> Yes. I also do not see the use of printing hex value if we are printing the 
>> description.
>>
>>> As I said, if you and other folkz thinks this is valuable, then I am
>>> fine as well. Just saying, it's not my preferred option.
>>>
>>>
>>
>> I just want to inform that the idea of printing the description came after 
>> discussion in https://www.spinics.net/lists/linux-mmc/msg48246.html, where 
>> it was decided adding utility in mmc-utils was not going to work ( reason:  
>> We may very well be changing the bit offsets for the caps and caps2 in the 
>> mmc kernel header, keeping a copy of them is not a good idea. It's just a 
>> matter of *when* it will break).
> I recall. However, I didn't realize all these strings were going to be
> needed. :-)
>
>> On Thu, 2018-03-15 at 11:12 +0100, Ulf Hansson wrote:
>>> If were to decide, I would just rather print the caps field in a 
>>> hexadecimal bit form and leave the translation to the user.
>> I think translation becomes difficult for the above reason and hence I would 
>> prefer printing the description.
> Okay.
>
>> Note: Printing values in Hex was the original idea and it is also available 
>> in https://www.spinics.net/lists/linux-mmc/msg48213.html just in case if it 
>> is required.
> Yeah, so maybe I should apply that one, then we can take it from there!?



Fine with both the approach. Please consider this.


Thanks,
Harish Jenny K N

Re: [PATCH v10] mmc: Export host capabilities to debugfs.

[Harish Jenny K N]

On Friday 16 March 2018 01:27 PM, Ulf Hansson wrote:
> On 16 March 2018 at 05:20, Harish Jenny K N  wrote:
>>
>> On Thursday 15 March 2018 05:59 PM, Ulf Hansson wrote:
>>> On 15 March 2018 at 11:26, Andy Shevchenko
>>>  wrote:
 On Thu, 2018-03-15 at 11:12 +0100, Ulf Hansson wrote:
> On 13 March 2018 at 06:10, Harish Jenny K N > wrote:
>>
> Honestly, I don't like this, but maybe other people do, then I am fine
> with this approach.
>
> If were to decide, I would just rather print the caps field in a
> hexadecimal bit form and leave the translation to the user.
 A compromise would be to print both:

 0x\n
 Description of each enabled field, one per line


 Another format would be:

 Bit XX: Description of a field
>>> If we were to print the description, there is no point in printing the
>>> bits in hex. Or is it?
>> Yes. I also do not see the use of printing hex value if we are printing the 
>> description.
>>
>>> As I said, if you and other folkz thinks this is valuable, then I am
>>> fine as well. Just saying, it's not my preferred option.
>>>
>>>
>>
>> I just want to inform that the idea of printing the description came after 
>> discussion in https://www.spinics.net/lists/linux-mmc/msg48246.html, where 
>> it was decided adding utility in mmc-utils was not going to work ( reason:  
>> We may very well be changing the bit offsets for the caps and caps2 in the 
>> mmc kernel header, keeping a copy of them is not a good idea. It's just a 
>> matter of *when* it will break).
> I recall. However, I didn't realize all these strings were going to be
> needed. :-)
>
>> On Thu, 2018-03-15 at 11:12 +0100, Ulf Hansson wrote:
>>> If were to decide, I would just rather print the caps field in a 
>>> hexadecimal bit form and leave the translation to the user.
>> I think translation becomes difficult for the above reason and hence I would 
>> prefer printing the description.
> Okay.
>
>> Note: Printing values in Hex was the original idea and it is also available 
>> in https://www.spinics.net/lists/linux-mmc/msg48213.html just in case if it 
>> is required.
> Yeah, so maybe I should apply that one, then we can take it from there!?



Fine with both the approach. Please consider this.


Thanks,
Harish Jenny K N

Re: [PATCH v1 1/1] dmaengine: stm32-dmamux: fix a potential buffer overflow

[Vinod Koul]

On Tue, Mar 13, 2018 at 05:55:35PM +0100, Pierre-Yves MORDRET wrote:
> The bitfield dma_inuse is allocated of size dma_requests bits, thus a
> valid bit address is from 0 to (dma_requests - 1).
> When find_first_zero_bit() fails, it returns dma_requests as invalid
> address.
> Using such address for the following set_bit() is incorrect and, if
> dma_requests is a multiple of BITS_PER_LONG, it will cause a buffer
> overflow.
> Currently this driver is only used in DT stm32h743.dtsi where a safe value
> dma_requests=16 is not triggering the buffer overflow.
> 
> Fixed by checking the return value of find_first_zero_bit() _before_
> using it.

Applied, thanks

-- 
~Vinod

Re: [PATCH v1 1/1] dmaengine: stm32-dmamux: fix a potential buffer overflow

[Vinod Koul]

On Tue, Mar 13, 2018 at 05:55:35PM +0100, Pierre-Yves MORDRET wrote:
> The bitfield dma_inuse is allocated of size dma_requests bits, thus a
> valid bit address is from 0 to (dma_requests - 1).
> When find_first_zero_bit() fails, it returns dma_requests as invalid
> address.
> Using such address for the following set_bit() is incorrect and, if
> dma_requests is a multiple of BITS_PER_LONG, it will cause a buffer
> overflow.
> Currently this driver is only used in DT stm32h743.dtsi where a safe value
> dma_requests=16 is not triggering the buffer overflow.
> 
> Fixed by checking the return value of find_first_zero_bit() _before_
> using it.

Applied, thanks

-- 
~Vinod

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

[Srivatsa S. Bhat]

On 3/21/18 10:12 PM, Srivatsa S. Bhat wrote:
> On 3/21/18 7:02 PM, Steve French wrote:
>> Found a patch which solves the dependency issue.  In my testing (on
>> 4.9, with Windows 2016, and also to Samba) as Pavel suggested this
>> appears to fix the problem, but I will let Srivatsa confirm that it
>> also fixes it for him.  The two attached patches for 4.9 should work.
>>
> 
> Indeed, those two patches fix the problem for me on 4.9. Thanks a lot
> Steve, Pavel and Aurelien for all your efforts in fixing this!
> 
> I was also interested in getting this fixed on 4.4, so I modified the
> patches to apply on 4.4.88 and verified that they fix the mount

I meant to say 4.4.122 there (the latest stable 4.4 version at the moment).

Regards,
Srivatsa
VMware Photon OS

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

[Srivatsa S. Bhat]

On 3/21/18 10:12 PM, Srivatsa S. Bhat wrote:
> On 3/21/18 7:02 PM, Steve French wrote:
>> Found a patch which solves the dependency issue.  In my testing (on
>> 4.9, with Windows 2016, and also to Samba) as Pavel suggested this
>> appears to fix the problem, but I will let Srivatsa confirm that it
>> also fixes it for him.  The two attached patches for 4.9 should work.
>>
> 
> Indeed, those two patches fix the problem for me on 4.9. Thanks a lot
> Steve, Pavel and Aurelien for all your efforts in fixing this!
> 
> I was also interested in getting this fixed on 4.4, so I modified the
> patches to apply on 4.4.88 and verified that they fix the mount

I meant to say 4.4.122 there (the latest stable 4.4 version at the moment).

Regards,
Srivatsa
VMware Photon OS

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

[Srivatsa S. Bhat]

On 3/21/18 7:02 PM, Steve French wrote:
> Found a patch which solves the dependency issue.  In my testing (on
> 4.9, with Windows 2016, and also to Samba) as Pavel suggested this
> appears to fix the problem, but I will let Srivatsa confirm that it
> also fixes it for him.  The two attached patches for 4.9 should work.
> 

Indeed, those two patches fix the problem for me on 4.9. Thanks a lot
Steve, Pavel and Aurelien for all your efforts in fixing this!

I was also interested in getting this fixed on 4.4, so I modified the
patches to apply on 4.4.88 and verified that they fix the mount
failure. I have attached my patches for 4.4 with this mail.

Steve, Pavel, could you kindly double-check the second patch for 4.4,
especially around the keygen_exit error path?

Thank you very much!

Regards,
Srivatsa
VMware Photon OS
From a01a7dfb60e2d5421a487a7b81fd8a1bf72d96d4 Mon Sep 17 00:00:00 2001
From: Steve French 
Date: Sun, 11 Mar 2018 20:00:27 -0700
Subject: [PATCH 1/2] SMB3: Validate negotiate request must always be signed

commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream.

According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned

See kernel bugzilla bug 197311

[ Fixed up for kernel version 4.4 ]

CC: Stable 
Acked-by: Ronnie Sahlberg 
Signed-off-by: Steve French 
Signed-off-by: Srivatsa S. Bhat 
---
 fs/cifs/smb2pdu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 84614a5..6dae5b8 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1558,6 +1558,9 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon 
*tcon, u64 persistent_fid,
} else
iov[0].iov_len = get_rfc1002_length(req) + 4;
 
+   /* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */
+   if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO)
+   req->hdr.Flags |= SMB2_FLAGS_SIGNED;
 
rc = SendReceive2(xid, ses, iov, num_iovecs, _buftype, 0);
rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;
-- 
2.7.4

From d0178d8f096b29a88914787274bdc8ee8334ab07 Mon Sep 17 00:00:00 2001
From: Pavel Shilovsky 
Date: Mon, 7 Nov 2016 18:20:50 -0800
Subject: [PATCH 2/2] CIFS: Enable encryption during session setup phase

commit cabfb3680f78981d26c078a26e5c748531257ebb upstream.

In order to allow encryption on SMB connection we need to exchange
a session key and generate encryption and decryption keys.

[ Fixed up for kernel version 4.4 ]

Signed-off-by: Pavel Shilovsky 
Signed-off-by: Srivatsa S. Bhat 
---
 fs/cifs/sess.c| 22 ++
 fs/cifs/smb2pdu.c |  8 +---
 2 files changed, 11 insertions(+), 19 deletions(-)

diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index e88ffe1..a035d1a 100644
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -344,13 +344,12 @@ void build_ntlmssp_negotiate_blob(unsigned char *pbuffer,
/* BB is NTLMV2 session security format easier to use here? */
flags = NTLMSSP_NEGOTIATE_56 |  NTLMSSP_REQUEST_TARGET |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
-   NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
-   if (ses->server->sign) {
+   NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+   NTLMSSP_NEGOTIATE_SEAL;
+   if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
-   if (!ses->server->session_estab ||
-   ses->ntlmssp->sesskey_per_smbsess)
-   flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
-   }
+   if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+   flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
 
sec_blob->NegotiateFlags = cpu_to_le32(flags);
 
@@ -407,13 +406,12 @@ int build_ntlmssp_auth_blob(unsigned char **pbuffer,
flags = NTLMSSP_NEGOTIATE_56 |
NTLMSSP_REQUEST_TARGET | NTLMSSP_NEGOTIATE_TARGET_INFO |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
-   NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
-   if (ses->server->sign) {
+   NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+   NTLMSSP_NEGOTIATE_SEAL;
+   if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
-   if (!ses->server->session_estab ||
-   ses->ntlmssp->sesskey_per_smbsess)
-   flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
-   }
+   if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+   flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
 
tmp = *pbuffer + sizeof(AUTHENTICATE_MESSAGE);
sec_blob->NegotiateFlags = cpu_to_le32(flags);
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

[Srivatsa S. Bhat]

On 3/21/18 7:02 PM, Steve French wrote:
> Found a patch which solves the dependency issue.  In my testing (on
> 4.9, with Windows 2016, and also to Samba) as Pavel suggested this
> appears to fix the problem, but I will let Srivatsa confirm that it
> also fixes it for him.  The two attached patches for 4.9 should work.
> 

Indeed, those two patches fix the problem for me on 4.9. Thanks a lot
Steve, Pavel and Aurelien for all your efforts in fixing this!

I was also interested in getting this fixed on 4.4, so I modified the
patches to apply on 4.4.88 and verified that they fix the mount
failure. I have attached my patches for 4.4 with this mail.

Steve, Pavel, could you kindly double-check the second patch for 4.4,
especially around the keygen_exit error path?

Thank you very much!

Regards,
Srivatsa
VMware Photon OS
From a01a7dfb60e2d5421a487a7b81fd8a1bf72d96d4 Mon Sep 17 00:00:00 2001
From: Steve French 
Date: Sun, 11 Mar 2018 20:00:27 -0700
Subject: [PATCH 1/2] SMB3: Validate negotiate request must always be signed

commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream.

According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned

See kernel bugzilla bug 197311

[ Fixed up for kernel version 4.4 ]

CC: Stable 
Acked-by: Ronnie Sahlberg 
Signed-off-by: Steve French 
Signed-off-by: Srivatsa S. Bhat 
---
 fs/cifs/smb2pdu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 84614a5..6dae5b8 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1558,6 +1558,9 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon 
*tcon, u64 persistent_fid,
} else
iov[0].iov_len = get_rfc1002_length(req) + 4;
 
+   /* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */
+   if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO)
+   req->hdr.Flags |= SMB2_FLAGS_SIGNED;
 
rc = SendReceive2(xid, ses, iov, num_iovecs, _buftype, 0);
rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;
-- 
2.7.4

From d0178d8f096b29a88914787274bdc8ee8334ab07 Mon Sep 17 00:00:00 2001
From: Pavel Shilovsky 
Date: Mon, 7 Nov 2016 18:20:50 -0800
Subject: [PATCH 2/2] CIFS: Enable encryption during session setup phase

commit cabfb3680f78981d26c078a26e5c748531257ebb upstream.

In order to allow encryption on SMB connection we need to exchange
a session key and generate encryption and decryption keys.

[ Fixed up for kernel version 4.4 ]

Signed-off-by: Pavel Shilovsky 
Signed-off-by: Srivatsa S. Bhat 
---
 fs/cifs/sess.c| 22 ++
 fs/cifs/smb2pdu.c |  8 +---
 2 files changed, 11 insertions(+), 19 deletions(-)

diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index e88ffe1..a035d1a 100644
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -344,13 +344,12 @@ void build_ntlmssp_negotiate_blob(unsigned char *pbuffer,
/* BB is NTLMV2 session security format easier to use here? */
flags = NTLMSSP_NEGOTIATE_56 |  NTLMSSP_REQUEST_TARGET |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
-   NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
-   if (ses->server->sign) {
+   NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+   NTLMSSP_NEGOTIATE_SEAL;
+   if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
-   if (!ses->server->session_estab ||
-   ses->ntlmssp->sesskey_per_smbsess)
-   flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
-   }
+   if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+   flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
 
sec_blob->NegotiateFlags = cpu_to_le32(flags);
 
@@ -407,13 +406,12 @@ int build_ntlmssp_auth_blob(unsigned char **pbuffer,
flags = NTLMSSP_NEGOTIATE_56 |
NTLMSSP_REQUEST_TARGET | NTLMSSP_NEGOTIATE_TARGET_INFO |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
-   NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
-   if (ses->server->sign) {
+   NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+   NTLMSSP_NEGOTIATE_SEAL;
+   if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
-   if (!ses->server->session_estab ||
-   ses->ntlmssp->sesskey_per_smbsess)
-   flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
-   }
+   if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+   flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
 
tmp = *pbuffer + sizeof(AUTHENTICATE_MESSAGE);
sec_blob->NegotiateFlags = cpu_to_le32(flags);
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 6dae5b8..33b1bc2 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -832,10 +832,8 @@ ssetup_exit:
 
if (!rc) {

Re: [RFC PATCH 4/6] sched/fair: Introduce an energy estimation helper function

[Quentin Perret]

On Wednesday 21 Mar 2018 at 15:54:58 (+), Patrick Bellasi wrote:
> On 21-Mar 14:26, Quentin Perret wrote:
> > On Wednesday 21 Mar 2018 at 12:39:21 (+), Patrick Bellasi wrote:
> > > On 20-Mar 09:43, Dietmar Eggemann wrote:
> > > > From: Quentin Perret 

[...]

> > So actually, what I can do is add something like
> > 
> > fdom_tot_util += util;
> > 
> > to this loop and compute
> > 
> > energy = cs->power * fdom_tot_util / cs->cap;
> > 
> > only once, instead of having the second loop to compute the energy. We don't
> > have to scale the util for each and every CPU since they share the same
> > cap state. That would save some divisions and ensure the consistency
> > between the selection of the cap state and the associated energy
> > computation. What do you think ?
> 
> Right, would say that under the hypothesis the we are in the same
> frequency domain (and we are because of fdom->span), that's basically
> doing:
> 
>sum_i(P_x * U_i / C_x) => P_x / C_x * sum_i(U_i)
> 
> Where (C_x, P_x) are the EM reported capacity and power for the
> expected frequency domain OPP.
> 

Yes that's exactly that. I'll do the change in v2.

> > Or maybe you were talking about consistency between several consecutive
> > calls to compute_energy() ?
> 
> Nope, the above +1
> 

[...]

> > I agree that it would be nice to document somewhere that
> > compute_energy() is unsafe to call without sched_energy_present.
> > I can simply add a proper doc comment to this function actually.
> > Would that work ?
> 
> Right, it's just that _maybe_ an explicit BUG_ON is improving the
> documentation by making more explicit the error on testing ?
> 
> Thus, I would probably add both... but Peter will tell you for sure ;)
> 

Right, but I'm still not sure if the BUG_ON is the right thing to do. I
mean, if we really want to make this check, then we could also try
to recover into a working state ... If we enter compute_energy() without
having an energy model, and if we detect it on time, we could bail out
and disable sched_energy_present ASAP with an error message for example.
That would let us know if EAS is broken without making the system
unusable.

Anyways, if there is a general agreement, or if the maintainers think
that the BUG_ON is the right thing to do here, I'm happy to change that
in future versions :)

Re: [RFC PATCH 4/6] sched/fair: Introduce an energy estimation helper function

[Quentin Perret]

On Wednesday 21 Mar 2018 at 15:54:58 (+), Patrick Bellasi wrote:
> On 21-Mar 14:26, Quentin Perret wrote:
> > On Wednesday 21 Mar 2018 at 12:39:21 (+), Patrick Bellasi wrote:
> > > On 20-Mar 09:43, Dietmar Eggemann wrote:
> > > > From: Quentin Perret 

[...]

> > So actually, what I can do is add something like
> > 
> > fdom_tot_util += util;
> > 
> > to this loop and compute
> > 
> > energy = cs->power * fdom_tot_util / cs->cap;
> > 
> > only once, instead of having the second loop to compute the energy. We don't
> > have to scale the util for each and every CPU since they share the same
> > cap state. That would save some divisions and ensure the consistency
> > between the selection of the cap state and the associated energy
> > computation. What do you think ?
> 
> Right, would say that under the hypothesis the we are in the same
> frequency domain (and we are because of fdom->span), that's basically
> doing:
> 
>sum_i(P_x * U_i / C_x) => P_x / C_x * sum_i(U_i)
> 
> Where (C_x, P_x) are the EM reported capacity and power for the
> expected frequency domain OPP.
> 

Yes that's exactly that. I'll do the change in v2.

> > Or maybe you were talking about consistency between several consecutive
> > calls to compute_energy() ?
> 
> Nope, the above +1
> 

[...]

> > I agree that it would be nice to document somewhere that
> > compute_energy() is unsafe to call without sched_energy_present.
> > I can simply add a proper doc comment to this function actually.
> > Would that work ?
> 
> Right, it's just that _maybe_ an explicit BUG_ON is improving the
> documentation by making more explicit the error on testing ?
> 
> Thus, I would probably add both... but Peter will tell you for sure ;)
> 

Right, but I'm still not sure if the BUG_ON is the right thing to do. I
mean, if we really want to make this check, then we could also try
to recover into a working state ... If we enter compute_energy() without
having an energy model, and if we detect it on time, we could bail out
and disable sched_energy_present ASAP with an error message for example.
That would let us know if EAS is broken without making the system
unusable.

Anyways, if there is a general agreement, or if the maintainers think
that the BUG_ON is the right thing to do here, I'm happy to change that
in future versions :)

Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim

[Dave Chinner]

On Wed, Mar 21, 2018 at 07:15:14PM +0300, Kirill Tkhai wrote:
> On 20.03.2018 17:34, Dave Chinner wrote:
> > On Tue, Mar 20, 2018 at 04:15:16PM +0300, Kirill Tkhai wrote:
> >> On 20.03.2018 03:18, Dave Chinner wrote:
> >>> On Mon, Mar 19, 2018 at 02:06:01PM +0300, Kirill Tkhai wrote:
>  On 17.03.2018 00:39, Dave Chinner wrote:
> >>> Actually, it is fair, because:
> >>>
> >>> /* proportion the scan between the caches */
> >>> dentries = mult_frac(sc->nr_to_scan, dentries, total_objects);
> >>> inodes = mult_frac(sc->nr_to_scan, inodes, total_objects);
> >>> fs_objects = mult_frac(sc->nr_to_scan, fs_objects, total_objects);
> >>>
> >>> This means that if the number of objects in the memcg aware VFS
> >>> caches are tiny compared to the global XFS inode cache, then they
> >>> only get a tiny amount of the total scanning done by the shrinker.
> >>
> >> This is just wrong. If you have two memcgs, the first is charged
> >> by xfs dentries and inodes, while the second is not charged by xfs
> >> dentries and inodes, the second will response for xfs shrink as well
> >> as the first.
> > 
> > That makes no sense to me. Shrinkers are per-sb, so they only
> > shrink per-filesystem dentries and inodes. If your memcgs are on
> > different filesystems, then they'll behave according to the size of
> > that filesystem's caches, not the cache of some other filesystem.
> 
> But this break the isolation purpose of memcg. When someone places
> different services in different pairs of memcg and cpu cgroup, he
> wants do not do foreign work.

Too bad. Filesystems *break memcg isolation all the time*.

Think about it. The filesystem journal is owned by the filesystem,
not the memcg that is writing a transaction to it.  If one memcg
does lots of metadata modifications, it can use all the journal
space and starve iitself and all other memcgs of journal space while
the filesystem does writeback to clear it out.

Another example: if one memcg is manipulating free space in a
particular allocation group, other memcgs that need to manipulate
space in those allocation groups will block and be prevented from
operating until the other memcg finishes it's work.

Another example: inode IO in XFS are done in clusters of 32. read or
write any inode in the cluster, and we read/write all the other
inodes in that cluster, too. Hence if we need to read an inode and
the cluster is busy because the filesystem journal needed flushing
or another inode in the cluster is being unlinked (e.g. by a process
in a different memcg), then the read in the first memcg will block
until whatever is being done on the buffer is complete. IOWs, even
at the physical on-disk inode level we violate memcg resource 
isolation principles.

I can go on, but I think you get the picture: Filesystems are full
of global structures whose access arbitration mechanisms
fundamentally break the concept of operational memcg isolation.

With that in mind, we really don't care that the shrinker does
global work and violate memcg isolation principles because we
violately them everywhere. IOWs, if we try to enforce memcg
isolation in the shrinker, then we can't guarantee forwards progress
in memory reclaim because we end up with multi-dimensional memcg
dependencies at the physical layers of the filesystem structure

I don't expect people who know nothing about XFS or filesystems to
understand the complexity of the interactions we are dealing with
here. Everything is a compromise when it comes to the memory reclaim
code as tehre are so many corner cases we have to handle. In this
situation, perfect is the enemy of good

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim

[Dave Chinner]

On Wed, Mar 21, 2018 at 07:15:14PM +0300, Kirill Tkhai wrote:
> On 20.03.2018 17:34, Dave Chinner wrote:
> > On Tue, Mar 20, 2018 at 04:15:16PM +0300, Kirill Tkhai wrote:
> >> On 20.03.2018 03:18, Dave Chinner wrote:
> >>> On Mon, Mar 19, 2018 at 02:06:01PM +0300, Kirill Tkhai wrote:
>  On 17.03.2018 00:39, Dave Chinner wrote:
> >>> Actually, it is fair, because:
> >>>
> >>> /* proportion the scan between the caches */
> >>> dentries = mult_frac(sc->nr_to_scan, dentries, total_objects);
> >>> inodes = mult_frac(sc->nr_to_scan, inodes, total_objects);
> >>> fs_objects = mult_frac(sc->nr_to_scan, fs_objects, total_objects);
> >>>
> >>> This means that if the number of objects in the memcg aware VFS
> >>> caches are tiny compared to the global XFS inode cache, then they
> >>> only get a tiny amount of the total scanning done by the shrinker.
> >>
> >> This is just wrong. If you have two memcgs, the first is charged
> >> by xfs dentries and inodes, while the second is not charged by xfs
> >> dentries and inodes, the second will response for xfs shrink as well
> >> as the first.
> > 
> > That makes no sense to me. Shrinkers are per-sb, so they only
> > shrink per-filesystem dentries and inodes. If your memcgs are on
> > different filesystems, then they'll behave according to the size of
> > that filesystem's caches, not the cache of some other filesystem.
> 
> But this break the isolation purpose of memcg. When someone places
> different services in different pairs of memcg and cpu cgroup, he
> wants do not do foreign work.

Too bad. Filesystems *break memcg isolation all the time*.

Think about it. The filesystem journal is owned by the filesystem,
not the memcg that is writing a transaction to it.  If one memcg
does lots of metadata modifications, it can use all the journal
space and starve iitself and all other memcgs of journal space while
the filesystem does writeback to clear it out.

Another example: if one memcg is manipulating free space in a
particular allocation group, other memcgs that need to manipulate
space in those allocation groups will block and be prevented from
operating until the other memcg finishes it's work.

Another example: inode IO in XFS are done in clusters of 32. read or
write any inode in the cluster, and we read/write all the other
inodes in that cluster, too. Hence if we need to read an inode and
the cluster is busy because the filesystem journal needed flushing
or another inode in the cluster is being unlinked (e.g. by a process
in a different memcg), then the read in the first memcg will block
until whatever is being done on the buffer is complete. IOWs, even
at the physical on-disk inode level we violate memcg resource 
isolation principles.

I can go on, but I think you get the picture: Filesystems are full
of global structures whose access arbitration mechanisms
fundamentally break the concept of operational memcg isolation.

With that in mind, we really don't care that the shrinker does
global work and violate memcg isolation principles because we
violately them everywhere. IOWs, if we try to enforce memcg
isolation in the shrinker, then we can't guarantee forwards progress
in memory reclaim because we end up with multi-dimensional memcg
dependencies at the physical layers of the filesystem structure

I don't expect people who know nothing about XFS or filesystems to
understand the complexity of the interactions we are dealing with
here. Everything is a compromise when it comes to the memory reclaim
code as tehre are so many corner cases we have to handle. In this
situation, perfect is the enemy of good

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH] arm64: avoid race condition issue in dump_backtrace

[Baruch Siach]

Hi Ji Zhang,

On Thu, Mar 22, 2018 at 11:06:00AM +0800, Ji Zhang wrote:
> When we dump the backtrace of some specific task, there is a potential race
> condition due to the task may be running on other cores if SMP enabled.
> That is because for current implementation, if the task is not the current
> task, we will get the registers used for unwind from cpu_context saved in
> thread_info, which is the snapshot before context switch, but if the task
> is running on other cores, the registers and the content of stack are
> changed.
> This may cause that we get the wrong backtrace or incomplete backtrace or
> even crash the kernel.
> To avoid this case, do not dump the backtrace of the tasks which are
> running on other cores.
> This patch cannot solve the issue completely but can shrink the window of
> race condition.
> 
> Signed-off-by: Ji Zhang 
> ---
>  arch/arm64/kernel/traps.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index eb2d151..95749364 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -113,6 +113,9 @@ void dump_backtrace(struct pt_regs *regs, struct 
> task_struct *tsk)
>   if (tsk == current) {
>   frame.fp = (unsigned long)__builtin_frame_address(0);
>   frame.pc = (unsigned long)dump_backtrace;
> + else if (tsk->state == TASK_RUNNING) {

Missing closing brace. Does this build?

> + pr_notice("Do not dump other running tasks\n");
> + return;
>   } else {
>   /*
>* task blocked in __switch_to

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [PATCH] arm64: avoid race condition issue in dump_backtrace

[Baruch Siach]

Hi Ji Zhang,

On Thu, Mar 22, 2018 at 11:06:00AM +0800, Ji Zhang wrote:
> When we dump the backtrace of some specific task, there is a potential race
> condition due to the task may be running on other cores if SMP enabled.
> That is because for current implementation, if the task is not the current
> task, we will get the registers used for unwind from cpu_context saved in
> thread_info, which is the snapshot before context switch, but if the task
> is running on other cores, the registers and the content of stack are
> changed.
> This may cause that we get the wrong backtrace or incomplete backtrace or
> even crash the kernel.
> To avoid this case, do not dump the backtrace of the tasks which are
> running on other cores.
> This patch cannot solve the issue completely but can shrink the window of
> race condition.
> 
> Signed-off-by: Ji Zhang 
> ---
>  arch/arm64/kernel/traps.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index eb2d151..95749364 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -113,6 +113,9 @@ void dump_backtrace(struct pt_regs *regs, struct 
> task_struct *tsk)
>   if (tsk == current) {
>   frame.fp = (unsigned long)__builtin_frame_address(0);
>   frame.pc = (unsigned long)dump_backtrace;
> + else if (tsk->state == TASK_RUNNING) {

Missing closing brace. Does this build?

> + pr_notice("Do not dump other running tasks\n");
> + return;
>   } else {
>   /*
>* task blocked in __switch_to

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[PATCH] vfio iommu type1: improve memory pinning process for raw PFN mapping

[Jason Cai (Xiang Feng)]

When using vfio to pass through a PCIe device (e.g. a GPU card) that
has a huge BAR (e.g. 16GB), a lot of cycles are wasted on memory
pinning because PFNs of PCI BAR are not backed by struct page, and
the corresponding VMA has flag VM_PFNMAP.

With this change, when pinning a region which is a raw PFN mapping,
it can skip unnecessary user memory pinning process, and thus, can
significantly improve VM's boot up time when passing through devices
via VFIO. In my test on a Xeon E5 2.6GHz, the time mapping a 16GB
BAR was reduced from about 0.4s to 1.5us.

Signed-off-by: Jason Cai (Xiang Feng) 
---
 drivers/vfio/vfio_iommu_type1.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 45657e2b1ff7..0658f35318b8 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -397,7 +397,6 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
 {
unsigned long pfn = 0;
long ret, pinned = 0, lock_acct = 0;
-   bool rsvd;
dma_addr_t iova = vaddr - dma->vaddr + dma->iova;
 
/* This code path is only user initiated */
@@ -408,14 +407,22 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
if (ret)
return ret;
 
+   if (is_invalid_reserved_pfn(*pfn_base)) {
+   struct vm_area_struct *vma;
+   down_read(>mm->mmap_sem);
+   vma = find_vma_intersection(current->mm, vaddr, vaddr + 1);
+   pinned = min(npage, (long)vma_pages(vma));
+   up_read(>mm->mmap_sem);
+   return pinned;
+   }
+
pinned++;
-   rsvd = is_invalid_reserved_pfn(*pfn_base);
 
/*
 * Reserved pages aren't counted against the user, externally pinned
 * pages are already counted against the user.
 */
-   if (!rsvd && !vfio_find_vpfn(dma, iova)) {
+   if (!vfio_find_vpfn(dma, iova)) {
if (!lock_cap && current->mm->locked_vm + 1 > limit) {
put_pfn(*pfn_base, dma->prot);
pr_warn("%s: RLIMIT_MEMLOCK (%ld) exceeded\n", __func__,
@@ -435,13 +442,12 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
if (ret)
break;
 
-   if (pfn != *pfn_base + pinned ||
-   rsvd != is_invalid_reserved_pfn(pfn)) {
+   if (pfn != *pfn_base + pinned) {
put_pfn(pfn, dma->prot);
break;
}
 
-   if (!rsvd && !vfio_find_vpfn(dma, iova)) {
+   if (!vfio_find_vpfn(dma, iova)) {
if (!lock_cap &&
current->mm->locked_vm + lock_acct + 1 > limit) {
put_pfn(pfn, dma->prot);
@@ -459,10 +465,8 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
 
 unpin_out:
if (ret) {
-   if (!rsvd) {
-   for (pfn = *pfn_base ; pinned ; pfn++, pinned--)
-   put_pfn(pfn, dma->prot);
-   }
+   for (pfn = *pfn_base ; pinned ; pfn++, pinned--)
+   put_pfn(pfn, dma->prot);
 
return ret;
}
-- 
2.13.6

[PATCH] vfio iommu type1: improve memory pinning process for raw PFN mapping

[Jason Cai (Xiang Feng)]

When using vfio to pass through a PCIe device (e.g. a GPU card) that
has a huge BAR (e.g. 16GB), a lot of cycles are wasted on memory
pinning because PFNs of PCI BAR are not backed by struct page, and
the corresponding VMA has flag VM_PFNMAP.

With this change, when pinning a region which is a raw PFN mapping,
it can skip unnecessary user memory pinning process, and thus, can
significantly improve VM's boot up time when passing through devices
via VFIO. In my test on a Xeon E5 2.6GHz, the time mapping a 16GB
BAR was reduced from about 0.4s to 1.5us.

Signed-off-by: Jason Cai (Xiang Feng) 
---
 drivers/vfio/vfio_iommu_type1.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 45657e2b1ff7..0658f35318b8 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -397,7 +397,6 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
 {
unsigned long pfn = 0;
long ret, pinned = 0, lock_acct = 0;
-   bool rsvd;
dma_addr_t iova = vaddr - dma->vaddr + dma->iova;
 
/* This code path is only user initiated */
@@ -408,14 +407,22 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
if (ret)
return ret;
 
+   if (is_invalid_reserved_pfn(*pfn_base)) {
+   struct vm_area_struct *vma;
+   down_read(>mm->mmap_sem);
+   vma = find_vma_intersection(current->mm, vaddr, vaddr + 1);
+   pinned = min(npage, (long)vma_pages(vma));
+   up_read(>mm->mmap_sem);
+   return pinned;
+   }
+
pinned++;
-   rsvd = is_invalid_reserved_pfn(*pfn_base);
 
/*
 * Reserved pages aren't counted against the user, externally pinned
 * pages are already counted against the user.
 */
-   if (!rsvd && !vfio_find_vpfn(dma, iova)) {
+   if (!vfio_find_vpfn(dma, iova)) {
if (!lock_cap && current->mm->locked_vm + 1 > limit) {
put_pfn(*pfn_base, dma->prot);
pr_warn("%s: RLIMIT_MEMLOCK (%ld) exceeded\n", __func__,
@@ -435,13 +442,12 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
if (ret)
break;
 
-   if (pfn != *pfn_base + pinned ||
-   rsvd != is_invalid_reserved_pfn(pfn)) {
+   if (pfn != *pfn_base + pinned) {
put_pfn(pfn, dma->prot);
break;
}
 
-   if (!rsvd && !vfio_find_vpfn(dma, iova)) {
+   if (!vfio_find_vpfn(dma, iova)) {
if (!lock_cap &&
current->mm->locked_vm + lock_acct + 1 > limit) {
put_pfn(pfn, dma->prot);
@@ -459,10 +465,8 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, 
unsigned long vaddr,
 
 unpin_out:
if (ret) {
-   if (!rsvd) {
-   for (pfn = *pfn_base ; pinned ; pfn++, pinned--)
-   put_pfn(pfn, dma->prot);
-   }
+   for (pfn = *pfn_base ; pinned ; pfn++, pinned--)
+   put_pfn(pfn, dma->prot);
 
return ret;
}
-- 
2.13.6

[PATCH] nfit: skip region registration for incomplete control regions

[Dan Williams]

Per the ACPI specification the only functional purpose for a DIMM
Control Region to be mapped into the system physical address space, from
an OSPM perspective, is to support block-apertures. However, there are
some BIOSen that publish DIMM Control Region SPA entries for pre-boot
environment consumption.  Undo the kernel policy of generating disabled
'ndblk' regions when this configuration is detected.

Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c |   13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 39ad06143e78..4530d89044db 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2578,7 +2578,7 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc 
*acpi_desc,
struct acpi_nfit_system_address *spa = nfit_spa->spa;
struct nd_blk_region_desc *ndbr_desc;
struct nfit_mem *nfit_mem;
-   int blk_valid = 0, rc;
+   int rc;
 
if (!nvdimm) {
dev_err(acpi_desc->dev, "spa%d dimm: %#x not found\n",
@@ -2598,15 +2598,14 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc 
*acpi_desc,
if (!nfit_mem || !nfit_mem->bdw) {
dev_dbg(acpi_desc->dev, "spa%d %s missing bdw\n",
spa->range_index, nvdimm_name(nvdimm));
-   } else {
-   mapping->size = nfit_mem->bdw->capacity;
-   mapping->start = nfit_mem->bdw->start_address;
-   ndr_desc->num_lanes = nfit_mem->bdw->windows;
-   blk_valid = 1;
+   break;
}
 
+   mapping->size = nfit_mem->bdw->capacity;
+   mapping->start = nfit_mem->bdw->start_address;
+   ndr_desc->num_lanes = nfit_mem->bdw->windows;
ndr_desc->mapping = mapping;
-   ndr_desc->num_mappings = blk_valid;
+   ndr_desc->num_mappings = 1;
ndbr_desc = to_blk_region_desc(ndr_desc);
ndbr_desc->enable = acpi_nfit_blk_region_enable;
ndbr_desc->do_io = acpi_desc->blk_do_io;

Re: [PATCH v4 23/24] fpga: dfl: afu: add user afu sub feature support

[Wu Hao]

On Wed, Mar 21, 2018 at 06:50:54PM -0500, Alan Tull wrote:
> On Tue, Mar 20, 2018 at 2:10 AM, Wu Hao  wrote:
> 
> >> > +static int afu_mmap(struct file *filp, struct vm_area_struct *vma)
> >> > +{
> >> > +   struct fpga_afu_region region;
> >> > +   struct platform_device *pdev = filp->private_data;
> >> > +   struct feature_platform_data *pdata = 
> >> > dev_get_platdata(>dev);
> >> > +   u64 size = vma->vm_end - vma->vm_start;
> >> > +   u64 offset;
> >> > +   int ret;
> >> > +
> >> > +   if (!(vma->vm_flags & VM_SHARED))
> >> > +   return -EINVAL;
> >> > +
> >> > +   offset = vma->vm_pgoff << PAGE_SHIFT;
> >> > +   ret = afu_get_region_by_offset(pdata, offset, size, );
> 
> Most of the functions here are afu_region_*, but there's also
> afu_get_region_by_*.  Better if afu_region_get_by_* to be consistent.

Agree, will fix it in the next version, thanks a lot for the comments.

Hao

[PATCH] nfit: skip region registration for incomplete control regions

[Dan Williams]

Per the ACPI specification the only functional purpose for a DIMM
Control Region to be mapped into the system physical address space, from
an OSPM perspective, is to support block-apertures. However, there are
some BIOSen that publish DIMM Control Region SPA entries for pre-boot
environment consumption.  Undo the kernel policy of generating disabled
'ndblk' regions when this configuration is detected.

Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c |   13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 39ad06143e78..4530d89044db 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2578,7 +2578,7 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc 
*acpi_desc,
struct acpi_nfit_system_address *spa = nfit_spa->spa;
struct nd_blk_region_desc *ndbr_desc;
struct nfit_mem *nfit_mem;
-   int blk_valid = 0, rc;
+   int rc;
 
if (!nvdimm) {
dev_err(acpi_desc->dev, "spa%d dimm: %#x not found\n",
@@ -2598,15 +2598,14 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc 
*acpi_desc,
if (!nfit_mem || !nfit_mem->bdw) {
dev_dbg(acpi_desc->dev, "spa%d %s missing bdw\n",
spa->range_index, nvdimm_name(nvdimm));
-   } else {
-   mapping->size = nfit_mem->bdw->capacity;
-   mapping->start = nfit_mem->bdw->start_address;
-   ndr_desc->num_lanes = nfit_mem->bdw->windows;
-   blk_valid = 1;
+   break;
}
 
+   mapping->size = nfit_mem->bdw->capacity;
+   mapping->start = nfit_mem->bdw->start_address;
+   ndr_desc->num_lanes = nfit_mem->bdw->windows;
ndr_desc->mapping = mapping;
-   ndr_desc->num_mappings = blk_valid;
+   ndr_desc->num_mappings = 1;
ndbr_desc = to_blk_region_desc(ndr_desc);
ndbr_desc->enable = acpi_nfit_blk_region_enable;
ndbr_desc->do_io = acpi_desc->blk_do_io;

Re: [PATCH v4 23/24] fpga: dfl: afu: add user afu sub feature support

[Wu Hao]

On Wed, Mar 21, 2018 at 06:50:54PM -0500, Alan Tull wrote:
> On Tue, Mar 20, 2018 at 2:10 AM, Wu Hao  wrote:
> 
> >> > +static int afu_mmap(struct file *filp, struct vm_area_struct *vma)
> >> > +{
> >> > +   struct fpga_afu_region region;
> >> > +   struct platform_device *pdev = filp->private_data;
> >> > +   struct feature_platform_data *pdata = 
> >> > dev_get_platdata(>dev);
> >> > +   u64 size = vma->vm_end - vma->vm_start;
> >> > +   u64 offset;
> >> > +   int ret;
> >> > +
> >> > +   if (!(vma->vm_flags & VM_SHARED))
> >> > +   return -EINVAL;
> >> > +
> >> > +   offset = vma->vm_pgoff << PAGE_SHIFT;
> >> > +   ret = afu_get_region_by_offset(pdata, offset, size, );
> 
> Most of the functions here are afu_region_*, but there's also
> afu_get_region_by_*.  Better if afu_region_get_by_* to be consistent.

Agree, will fix it in the next version, thanks a lot for the comments.

Hao

Re: [PATCH v4 04/24] fpga: add device feature list support

[Wu Hao]

On Wed, Mar 21, 2018 at 06:54:58PM -0500, Alan Tull wrote:
> On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao  wrote:
> 
> Hi Hao,
> 
> > +static int
> > +build_info_create_dev(struct build_feature_devs_info *binfo,
> > + enum fpga_id_type type, const char *name,
> > + void __iomem *ioaddr)
> > +{
> > +   struct platform_device *fdev;
> > +   int ret;
> > +
> > +   /* we will create a new device, commit current device first */
> > +   ret = build_info_commit_dev(binfo);
> > +   if (ret)
> > +   return ret;
> > +
> > +   /*
> > +* we use -ENODEV as the initialization indicator which indicates
> > +* whether the id need to be reclaimed
> > +*/
> > +   fdev = platform_device_alloc(name, -ENODEV);
> > +   if (!fdev)
> > +   return -ENOMEM;
> > +
> > +   binfo->feature_dev = fdev;
> > +   binfo->feature_num = 0;
> > +   binfo->ioaddr = ioaddr;
> > +   INIT_LIST_HEAD(>sub_features);
> > +
> > +   fdev->id = alloc_fpga_id(type, >dev);
> > +   if (fdev->id < 0)
> > +   return fdev->id;
> 
> Do we need platform_device_put if returning here?

Hi Alan,

Actually if any error returned by this build_info_create_dev, it will cause
parse_feature_list returns error code and finally build_info_free is invoked.
In build_info_free function, it will do platform_device_put there, so we don't
have to add code to do put here. : )

Thanks
Hao

> 
> Alan
> 
> > +
> > +   fdev->dev.parent = >cdev->region.dev;
> > +
> > +   return 0;
> > +}
> > +

Re: [PATCH v4 04/24] fpga: add device feature list support

[Wu Hao]

On Wed, Mar 21, 2018 at 06:54:58PM -0500, Alan Tull wrote:
> On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao  wrote:
> 
> Hi Hao,
> 
> > +static int
> > +build_info_create_dev(struct build_feature_devs_info *binfo,
> > + enum fpga_id_type type, const char *name,
> > + void __iomem *ioaddr)
> > +{
> > +   struct platform_device *fdev;
> > +   int ret;
> > +
> > +   /* we will create a new device, commit current device first */
> > +   ret = build_info_commit_dev(binfo);
> > +   if (ret)
> > +   return ret;
> > +
> > +   /*
> > +* we use -ENODEV as the initialization indicator which indicates
> > +* whether the id need to be reclaimed
> > +*/
> > +   fdev = platform_device_alloc(name, -ENODEV);
> > +   if (!fdev)
> > +   return -ENOMEM;
> > +
> > +   binfo->feature_dev = fdev;
> > +   binfo->feature_num = 0;
> > +   binfo->ioaddr = ioaddr;
> > +   INIT_LIST_HEAD(>sub_features);
> > +
> > +   fdev->id = alloc_fpga_id(type, >dev);
> > +   if (fdev->id < 0)
> > +   return fdev->id;
> 
> Do we need platform_device_put if returning here?

Hi Alan,

Actually if any error returned by this build_info_create_dev, it will cause
parse_feature_list returns error code and finally build_info_free is invoked.
In build_info_free function, it will do platform_device_put there, so we don't
have to add code to do put here. : )

Thanks
Hao

> 
> Alan
> 
> > +
> > +   fdev->dev.parent = >cdev->region.dev;
> > +
> > +   return 0;
> > +}
> > +

Re: [PATCH] serial: samsung: macros with complex values should be enclosed in parentheses

[Joe Perches]

On Thu, 2018-03-22 at 13:37 +0900, y.k.oh wrote:
> 
> On 03/14/2018 10:58 PM, Greg KH wrote:
> > On Wed, Mar 14, 2018 at 11:17:05AM +0900, YOUNGKEUN OH wrote:
> > > Cleanup checkpatch error:
> > > ERROR: Macros with complex values should be enclosed in parentheses
> > > 
> > > Signed-off-by: YOUNGKEUN OH 
> > > ---
> > >  drivers/tty/serial/samsung.c | 16 
> > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> > > index 3f2f8c1..da9bddb1 100644
> > > --- a/drivers/tty/serial/samsung.c
> > > +++ b/drivers/tty/serial/samsung.c
> > > @@ -1455,7 +1455,7 @@ static int __init s3c24xx_serial_console_init(void)
> > >  }
> > >  console_initcall(s3c24xx_serial_console_init);
> > > 
> > > -#define S3C24XX_SERIAL_CONSOLE _serial_console
> > > +#define S3C24XX_SERIAL_CONSOLE (_serial_console)
> > 
> > That's not a complex macro!
> > 
> > Please use checkpatch as a hint, not the "truth".
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Dear Greg.
> 
> Yes! Of course that's not a pretty complex macro. However, I think it is
> important to make a small effort to modify the minimum standard,
> Checkpatch ERROR, to ensure consistency in the Linux code.
> Starting with this Checkpatch error of samsung.c, I would like to start
> my efforts on contribution from a small point.  Please review it again.
> If there are any points that require modification, such as comment,
> then I'll modify it.

It might be better to remove the #defines and use
an #ifdef in the one place S2C24XX_SERIAL_CONSOLE
is referenced instead.

Re: [PATCH] serial: samsung: macros with complex values should be enclosed in parentheses

[Joe Perches]

On Thu, 2018-03-22 at 13:37 +0900, y.k.oh wrote:
> 
> On 03/14/2018 10:58 PM, Greg KH wrote:
> > On Wed, Mar 14, 2018 at 11:17:05AM +0900, YOUNGKEUN OH wrote:
> > > Cleanup checkpatch error:
> > > ERROR: Macros with complex values should be enclosed in parentheses
> > > 
> > > Signed-off-by: YOUNGKEUN OH 
> > > ---
> > >  drivers/tty/serial/samsung.c | 16 
> > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> > > index 3f2f8c1..da9bddb1 100644
> > > --- a/drivers/tty/serial/samsung.c
> > > +++ b/drivers/tty/serial/samsung.c
> > > @@ -1455,7 +1455,7 @@ static int __init s3c24xx_serial_console_init(void)
> > >  }
> > >  console_initcall(s3c24xx_serial_console_init);
> > > 
> > > -#define S3C24XX_SERIAL_CONSOLE _serial_console
> > > +#define S3C24XX_SERIAL_CONSOLE (_serial_console)
> > 
> > That's not a complex macro!
> > 
> > Please use checkpatch as a hint, not the "truth".
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Dear Greg.
> 
> Yes! Of course that's not a pretty complex macro. However, I think it is
> important to make a small effort to modify the minimum standard,
> Checkpatch ERROR, to ensure consistency in the Linux code.
> Starting with this Checkpatch error of samsung.c, I would like to start
> my efforts on contribution from a small point.  Please review it again.
> If there are any points that require modification, such as comment,
> then I'll modify it.

It might be better to remove the #defines and use
an #ifdef in the one place S2C24XX_SERIAL_CONSOLE
is referenced instead.

Re: [PATCH 0/7] HID core and multitouch fixups

[Peter Hutterer]

On Tue, Mar 20, 2018 at 12:04:44PM +0100, Benjamin Tissoires wrote:
> Hi,
> 
> Patches 1 and 2 are related to the Razer Blade Stealth that has some dead zone
> near the edges of the touchpad.
> Patches 3 was previously sent and reviewed by Dmitry and he suggested patch 4
> at the time.
> Patches 5..7 are cleanups I realized while trying to merge hid-multitouch
> into hid-core, so that other drivers could reuse the hid-mt logic (but it's
> not that easy I must confess).

Series: Acked-by: Peter Hutterer 

Cheers,
   Peter

> 
> Cheers,
> Benjamin
> 
> Benjamin Tissoires (7):
>   HID: multitouch: export a quirk for the button handling of touchpads
>   HID: multitouch: remove dead zones of Razer Blade Stealth
>   HID: use BIT macro instead of plain integers for flags
>   HID: use BIT() macro for quirks too
>   HID: core: remove the need for HID_QUIRK_NO_EMPTY_INPUT
>   HID: multitouch: do not set HID_QUIRK_NO_INIT_REPORTS
>   HID: core: reset the quirks before calling probe again
> 
>  drivers/hid/hid-asus.c   |  3 +-
>  drivers/hid/hid-core.c   |  2 ++
>  drivers/hid/hid-input.c  | 10 +++
>  drivers/hid/hid-multitouch.c | 61 -
>  drivers/hid/hid-uclogic.c|  1 -
>  include/linux/hid.h  | 65 
> ++--
>  6 files changed, 65 insertions(+), 77 deletions(-)
> 
> -- 
> 2.14.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" 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/7] HID core and multitouch fixups

[Peter Hutterer]

On Tue, Mar 20, 2018 at 12:04:44PM +0100, Benjamin Tissoires wrote:
> Hi,
> 
> Patches 1 and 2 are related to the Razer Blade Stealth that has some dead zone
> near the edges of the touchpad.
> Patches 3 was previously sent and reviewed by Dmitry and he suggested patch 4
> at the time.
> Patches 5..7 are cleanups I realized while trying to merge hid-multitouch
> into hid-core, so that other drivers could reuse the hid-mt logic (but it's
> not that easy I must confess).

Series: Acked-by: Peter Hutterer 

Cheers,
   Peter

> 
> Cheers,
> Benjamin
> 
> Benjamin Tissoires (7):
>   HID: multitouch: export a quirk for the button handling of touchpads
>   HID: multitouch: remove dead zones of Razer Blade Stealth
>   HID: use BIT macro instead of plain integers for flags
>   HID: use BIT() macro for quirks too
>   HID: core: remove the need for HID_QUIRK_NO_EMPTY_INPUT
>   HID: multitouch: do not set HID_QUIRK_NO_INIT_REPORTS
>   HID: core: reset the quirks before calling probe again
> 
>  drivers/hid/hid-asus.c   |  3 +-
>  drivers/hid/hid-core.c   |  2 ++
>  drivers/hid/hid-input.c  | 10 +++
>  drivers/hid/hid-multitouch.c | 61 -
>  drivers/hid/hid-uclogic.c|  1 -
>  include/linux/hid.h  | 65 
> ++--
>  6 files changed, 65 insertions(+), 77 deletions(-)
> 
> -- 
> 2.14.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] serial: samsung: macros with complex values should be enclosed in parentheses

[y.k.oh]

On 03/14/2018 10:58 PM, Greg KH wrote:
> On Wed, Mar 14, 2018 at 11:17:05AM +0900, YOUNGKEUN OH wrote:
>> Cleanup checkpatch error:
>> ERROR: Macros with complex values should be enclosed in parentheses
>>
>> Signed-off-by: YOUNGKEUN OH 
>> ---
>>  drivers/tty/serial/samsung.c | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
>> index 3f2f8c1..da9bddb1 100644
>> --- a/drivers/tty/serial/samsung.c
>> +++ b/drivers/tty/serial/samsung.c
>> @@ -1455,7 +1455,7 @@ static int __init s3c24xx_serial_console_init(void)
>>  }
>>  console_initcall(s3c24xx_serial_console_init);
>>
>> -#define S3C24XX_SERIAL_CONSOLE _serial_console
>> +#define S3C24XX_SERIAL_CONSOLE (_serial_console)
> 
> That's not a complex macro!
> 
> Please use checkpatch as a hint, not the "truth".
> 
> thanks,
> 
> greg k-h
> 
Dear Greg.

Yes! Of course that's not a pretty complex macro. However, I think it is
important to make a small effort to modify the minimum standard,
Checkpatch ERROR, to ensure consistency in the Linux code.
Starting with this Checkpatch error of samsung.c, I would like to start
my efforts on contribution from a small point.  Please review it again.
If there are any points that require modification, such as comment,
then I'll modify it.
Thank you.

Best regards,
Youngkeun Oh

Re: [PATCH] serial: samsung: macros with complex values should be enclosed in parentheses

[y.k.oh]

On 03/14/2018 10:58 PM, Greg KH wrote:
> On Wed, Mar 14, 2018 at 11:17:05AM +0900, YOUNGKEUN OH wrote:
>> Cleanup checkpatch error:
>> ERROR: Macros with complex values should be enclosed in parentheses
>>
>> Signed-off-by: YOUNGKEUN OH 
>> ---
>>  drivers/tty/serial/samsung.c | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
>> index 3f2f8c1..da9bddb1 100644
>> --- a/drivers/tty/serial/samsung.c
>> +++ b/drivers/tty/serial/samsung.c
>> @@ -1455,7 +1455,7 @@ static int __init s3c24xx_serial_console_init(void)
>>  }
>>  console_initcall(s3c24xx_serial_console_init);
>>
>> -#define S3C24XX_SERIAL_CONSOLE _serial_console
>> +#define S3C24XX_SERIAL_CONSOLE (_serial_console)
> 
> That's not a complex macro!
> 
> Please use checkpatch as a hint, not the "truth".
> 
> thanks,
> 
> greg k-h
> 
Dear Greg.

Yes! Of course that's not a pretty complex macro. However, I think it is
important to make a small effort to modify the minimum standard,
Checkpatch ERROR, to ensure consistency in the Linux code.
Starting with this Checkpatch error of samsung.c, I would like to start
my efforts on contribution from a small point.  Please review it again.
If there are any points that require modification, such as comment,
then I'll modify it.
Thank you.

Best regards,
Youngkeun Oh

Re: [RESEND PATCH] crypto: Add zstd support

[Sergey Senozhatsky]

On (03/21/18 15:49), Nick Terrell wrote:
> depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in

Yikes! How come I missed that... :)

> [0] 
> lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangt...@gmail.com

Signed-off-by: Nick Terrell  ?

-ss

Re: [RESEND PATCH] crypto: Add zstd support

[Sergey Senozhatsky]

On (03/21/18 15:49), Nick Terrell wrote:
> depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in

Yikes! How come I missed that... :)

> [0] 
> lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangt...@gmail.com

Signed-off-by: Nick Terrell  ?

-ss

Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.

[Maninder Singh]

CC: Vaneet Narang.

 
On (03/21/18 10:10), Maninder Singh wrote:
> diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c
> index cc7b6d4..185c358 100644
> --- a/lib/lz4/lz4_compress.c
> +++ b/lib/lz4/lz4_compress.c
> @@ -183,7 +183,8 @@ static FORCE_INLINE int LZ4_compress_generic(
>  const tableType_t tableType,
>  const dict_directive dict,
>  const dictIssue_directive dictIssue,
> -const U32 acceleration)
> +const U32 acceleration,
> +const Dynamic_Offset dynOffset)
>  {
>  const BYTE *ip = (const BYTE *) source;
>  const BYTE *base;
> @@ -199,6 +200,7 @@ static FORCE_INLINE int LZ4_compress_generic(
>
>  BYTE *op = (BYTE *) dest;
>  BYTE * const olimit = op + maxOutputSize;
> +int max_distance = dynOffset ? MAX_DISTANCE_DYN : MAX_DISTANCE;
 
Lets mark this variable `const`. If the compiler doesn't realize that this
variable and `dynOffset` are compile time constants, I expect the speed to
be impacted.
 
>
>  U32 forwardH;
>  size_t refDelta = 0;
> @@ -245,6 +247,7 @@ static FORCE_INLINE int LZ4_compress_generic(
>  for ( ; ; ) {
>  const BYTE *match;
>  BYTE *token;
> +int curr_offset;
>
>  /* Find a match */
>  {
> @@ -285,7 +288,7 @@ static FORCE_INLINE int LZ4_compress_generic(
>  : 0)
>  || ((tableType == byU16)
>  ? 0
> -: (match + MAX_DISTANCE < ip))
> +: (match + max_distance < ip))
>  || (LZ4_read32(match + refDelta)
>  != LZ4_read32(ip)));
>  }
> @@ -328,8 +331,26 @@ static FORCE_INLINE int LZ4_compress_generic(
>
>  _next_match:
>  /* Encode Offset */
> -LZ4_writeLE16(op, (U16)(ip - match));
> -op += 2;
> +if (dynOffset) {
> +curr_offset = (U16)(ip - match);
> +
> +/*
> + * If Ofsset is greater than 127, we need 2 bytes
> + * to store it. Otherwise 1 byte is enough.
> + */
> +if (curr_offset > 127) {
> +curr_offset = (curr_offset << 1) | DYN_BIT;
> +LZ4_writeLE16(op, (U16)curr_offset);
> +op += 2;
> +} else {
> +curr_offset = curr_offset << 1;
> +*op = (BYTE)curr_offset;
> +op++;
> +}
 
The standard way to do variable sized integers is to use the high-bit as
the control bit, not the low-bit. Do you have benchmarks to show that using
the low-bit is faster than using the high-bit? If so, lets comment in the
code, if not lets use the high-bit.
 
> +} else {
> +LZ4_writeLE16(op, (U16)(ip - match));
> +op += 2;
> +}
>
>  /* Encode MatchLength */
>  {
> @@ -480,39 +501,70 @@ static int LZ4_compress_fast_extState(
>  return LZ4_compress_generic(ctx, source,
>  dest, inputSize, 0,
>  noLimit, byU16, noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
>  else
>  return LZ4_compress_generic(ctx, source,
>  dest, inputSize, 0,
>  noLimit, tableType, noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
>  } else {
>  if (inputSize < LZ4_64Klimit)
>  return LZ4_compress_generic(ctx, source,
>  dest, inputSize,
>  maxOutputSize, limitedOutput, byU16, noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
>  else
>  return LZ4_compress_generic(ctx, source,
>  dest, inputSize,
>  maxOutputSize, limitedOutput, tableType, 
>noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
>  }
>  }
>
> +static int LZ4_compress_fast_extState_dynamic(
> +void *state,
> +const char *source,
> +char *dest,
> 

Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.

[Maninder Singh]

CC: Vaneet Narang.

 
On (03/21/18 10:10), Maninder Singh wrote:
> diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c
> index cc7b6d4..185c358 100644
> --- a/lib/lz4/lz4_compress.c
> +++ b/lib/lz4/lz4_compress.c
> @@ -183,7 +183,8 @@ static FORCE_INLINE int LZ4_compress_generic(
>  const tableType_t tableType,
>  const dict_directive dict,
>  const dictIssue_directive dictIssue,
> -const U32 acceleration)
> +const U32 acceleration,
> +const Dynamic_Offset dynOffset)
>  {
>  const BYTE *ip = (const BYTE *) source;
>  const BYTE *base;
> @@ -199,6 +200,7 @@ static FORCE_INLINE int LZ4_compress_generic(
>
>  BYTE *op = (BYTE *) dest;
>  BYTE * const olimit = op + maxOutputSize;
> +int max_distance = dynOffset ? MAX_DISTANCE_DYN : MAX_DISTANCE;
 
Lets mark this variable `const`. If the compiler doesn't realize that this
variable and `dynOffset` are compile time constants, I expect the speed to
be impacted.
 
>
>  U32 forwardH;
>  size_t refDelta = 0;
> @@ -245,6 +247,7 @@ static FORCE_INLINE int LZ4_compress_generic(
>  for ( ; ; ) {
>  const BYTE *match;
>  BYTE *token;
> +int curr_offset;
>
>  /* Find a match */
>  {
> @@ -285,7 +288,7 @@ static FORCE_INLINE int LZ4_compress_generic(
>  : 0)
>  || ((tableType == byU16)
>  ? 0
> -: (match + MAX_DISTANCE < ip))
> +: (match + max_distance < ip))
>  || (LZ4_read32(match + refDelta)
>  != LZ4_read32(ip)));
>  }
> @@ -328,8 +331,26 @@ static FORCE_INLINE int LZ4_compress_generic(
>
>  _next_match:
>  /* Encode Offset */
> -LZ4_writeLE16(op, (U16)(ip - match));
> -op += 2;
> +if (dynOffset) {
> +curr_offset = (U16)(ip - match);
> +
> +/*
> + * If Ofsset is greater than 127, we need 2 bytes
> + * to store it. Otherwise 1 byte is enough.
> + */
> +if (curr_offset > 127) {
> +curr_offset = (curr_offset << 1) | DYN_BIT;
> +LZ4_writeLE16(op, (U16)curr_offset);
> +op += 2;
> +} else {
> +curr_offset = curr_offset << 1;
> +*op = (BYTE)curr_offset;
> +op++;
> +}
 
The standard way to do variable sized integers is to use the high-bit as
the control bit, not the low-bit. Do you have benchmarks to show that using
the low-bit is faster than using the high-bit? If so, lets comment in the
code, if not lets use the high-bit.
 
> +} else {
> +LZ4_writeLE16(op, (U16)(ip - match));
> +op += 2;
> +}
>
>  /* Encode MatchLength */
>  {
> @@ -480,39 +501,70 @@ static int LZ4_compress_fast_extState(
>  return LZ4_compress_generic(ctx, source,
>  dest, inputSize, 0,
>  noLimit, byU16, noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
>  else
>  return LZ4_compress_generic(ctx, source,
>  dest, inputSize, 0,
>  noLimit, tableType, noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
>  } else {
>  if (inputSize < LZ4_64Klimit)
>  return LZ4_compress_generic(ctx, source,
>  dest, inputSize,
>  maxOutputSize, limitedOutput, byU16, noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
>  else
>  return LZ4_compress_generic(ctx, source,
>  dest, inputSize,
>  maxOutputSize, limitedOutput, tableType, 
>noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
>  }
>  }
>
> +static int LZ4_compress_fast_extState_dynamic(
> +void *state,
> +const char *source,
> +char *dest,
> 

RE: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add documentation for controller and driver

[Naga Sureshkumar Relli]

Hi Randy,

Thanks for reviewing the patch.

 I will address below mentioned comments in next version of patch.

Thanks,
Naga Sureshkumar Relli.

> -Original Message-
> From: Randy Dunlap [mailto:rdun...@infradead.org]
> Sent: Thursday, March 15, 2018 5:27 AM
> To: nagasureshkumarre...@gmail.com; boris.brezil...@bootlin.com;
> rich...@nod.at; dw...@infradead.org; computersforpe...@gmail.com;
> marek.va...@gmail.com; cyrille.pitc...@wedev4u.fr;
> miquel.ray...@bootlin.com
> Cc: linux-...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek
> ; Punnaiah Choudary Kalluri ; Naga
> Sureshkumar Relli 
> Subject: Re: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add
> documentation for controller and driver
> 
> On 03/14/2018 03:48 AM, nagasureshkumarre...@gmail.com wrote:
> > From: Naga Sureshkumar Relli 
> >
> > Added notes about the controller and driver
> >
> > Signed-off-by: Naga Sureshkumar Relli 
> > ---
> 
> Hi,
> 
> > ---
> >  Documentation/mtd/nand/pl353-nand.txt | 92
> > +++
> >  1 file changed, 92 insertions(+)
> >  create mode 100644 Documentation/mtd/nand/pl353-nand.txt
> >
> > diff --git a/Documentation/mtd/nand/pl353-nand.txt
> > b/Documentation/mtd/nand/pl353-nand.txt
> > new file mode 100644
> > index 000..ac6fbd5
> > --- /dev/null
> > +++ b/Documentation/mtd/nand/pl353-nand.txt
> > @@ -0,0 +1,92 @@
> > +This documents provides some notes about the ARM pl353 smc controller
> > +used in
> 
> s/smc/SMC/
> 
> > +Zynq SOC and confined to NAND specific details.
> > +
> > +Overview of the controller
> > +==
> > +   The SMC (PL353) supports two memory interfaces:
> > +   Interface 0 type SRAM.
> > +   Interface 1 type NAND.
> > +   This configuration supports the following configurable options:
> > +  . 32-bit or 64-bit AXI data width
> > +  . 8-bit, 16-bit, or 32-bit memory data width for interface 0
> > +  . 8-bit, or 16-bit memory data width for interface 1
> > +  . 1-4 chip selects on each interface
> > +  . SLC ECC block for interface 1
> > +
> > +For more information, refer the below link for TRM
> > +http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/
> > +DDI0380G_smc_pl350_series_r2p1_trm.pdf
> > +
> > +NAND memory accesses
> > +
> > +   . Two phase NAND accesses
> > +   . NAND command phase transfers
> > +   . NAND data phase transfers
> > +
> > +Two phase NAND accesses
> > +   The SMC defines two phases of commands when transferring data to or
> > +from NAND flash.
> > +
> > +Command phase
> > +   Commands and optional address information are written to the NAND
> flash.
> > +The command and address can be associated with either a data phase
> > +operation to write to or read from the array, or a status/ID register 
> > transfer.
> > +
> > +Data phase
> > + Data is either written to or read from the NAND flash. This data can
> > +be either data transferred to or from the array, or status/ID register
> information.
> > +
> > +NAND AXI address setup
> > +   AXI address  Command phase  Data phase
> > +   [31:24] Chip address   Chip address
> > +   [23]NoOfAddCycles_2Reserved
> > +   [22]NoOfAddCycles_1Reserved
> > +   [21]NoOfAddCycles_0ClearCS
> > +   [20]End command valid  End command valid
> > +   [19]0  1
> > +   [18:11] End commandEnd command
> > +   [10:3]  Start command  [10] ECC Last
> > +  [9:3] Reserved
> > +   [2:0]   Reserved   Reserved
> > +
> > +ECC
> > +===
> > +It operates on a number of 512 byte blocks of NAND memory and can
> > +be programmed to store the ECC codes after the data in memory. For
> > +writes, the ECC is written to the spare area of the page. For reads,
> > +the result of a block ECC check are made available to the device driver.
> > +
> > +-
> > +---
> > +|   n * 512 blocks  | extra  | ecc| |
> > +|   | block  | codes  | |
> > +-
> > +---
> > +
> > +The ECC calculation uses a simple Hamming code, using 1-bit
> > +correction 2-bit detection. It starts when a valid read or write
> > +command with a 512 byte aligned address is detected on the memory
> interface.
> > +
> > +Driver details
> > +==
> > +   The NAND driver has dependency with the pl353_smc memory
> controller
> > +driver for intializing the nand timing parameters, bus width, ECC
> > +modes,
> 
>   initializing the NAND
> 
> > +control and status information.
> > +
> > +Since the controller expects that the chipselect bit should be
> > +cleared 

RE: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add documentation for controller and driver

[Naga Sureshkumar Relli]

Hi Randy,

Thanks for reviewing the patch.

 I will address below mentioned comments in next version of patch.

Thanks,
Naga Sureshkumar Relli.

> -Original Message-
> From: Randy Dunlap [mailto:rdun...@infradead.org]
> Sent: Thursday, March 15, 2018 5:27 AM
> To: nagasureshkumarre...@gmail.com; boris.brezil...@bootlin.com;
> rich...@nod.at; dw...@infradead.org; computersforpe...@gmail.com;
> marek.va...@gmail.com; cyrille.pitc...@wedev4u.fr;
> miquel.ray...@bootlin.com
> Cc: linux-...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek
> ; Punnaiah Choudary Kalluri ; Naga
> Sureshkumar Relli 
> Subject: Re: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add
> documentation for controller and driver
> 
> On 03/14/2018 03:48 AM, nagasureshkumarre...@gmail.com wrote:
> > From: Naga Sureshkumar Relli 
> >
> > Added notes about the controller and driver
> >
> > Signed-off-by: Naga Sureshkumar Relli 
> > ---
> 
> Hi,
> 
> > ---
> >  Documentation/mtd/nand/pl353-nand.txt | 92
> > +++
> >  1 file changed, 92 insertions(+)
> >  create mode 100644 Documentation/mtd/nand/pl353-nand.txt
> >
> > diff --git a/Documentation/mtd/nand/pl353-nand.txt
> > b/Documentation/mtd/nand/pl353-nand.txt
> > new file mode 100644
> > index 000..ac6fbd5
> > --- /dev/null
> > +++ b/Documentation/mtd/nand/pl353-nand.txt
> > @@ -0,0 +1,92 @@
> > +This documents provides some notes about the ARM pl353 smc controller
> > +used in
> 
> s/smc/SMC/
> 
> > +Zynq SOC and confined to NAND specific details.
> > +
> > +Overview of the controller
> > +==
> > +   The SMC (PL353) supports two memory interfaces:
> > +   Interface 0 type SRAM.
> > +   Interface 1 type NAND.
> > +   This configuration supports the following configurable options:
> > +  . 32-bit or 64-bit AXI data width
> > +  . 8-bit, 16-bit, or 32-bit memory data width for interface 0
> > +  . 8-bit, or 16-bit memory data width for interface 1
> > +  . 1-4 chip selects on each interface
> > +  . SLC ECC block for interface 1
> > +
> > +For more information, refer the below link for TRM
> > +http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/
> > +DDI0380G_smc_pl350_series_r2p1_trm.pdf
> > +
> > +NAND memory accesses
> > +
> > +   . Two phase NAND accesses
> > +   . NAND command phase transfers
> > +   . NAND data phase transfers
> > +
> > +Two phase NAND accesses
> > +   The SMC defines two phases of commands when transferring data to or
> > +from NAND flash.
> > +
> > +Command phase
> > +   Commands and optional address information are written to the NAND
> flash.
> > +The command and address can be associated with either a data phase
> > +operation to write to or read from the array, or a status/ID register 
> > transfer.
> > +
> > +Data phase
> > + Data is either written to or read from the NAND flash. This data can
> > +be either data transferred to or from the array, or status/ID register
> information.
> > +
> > +NAND AXI address setup
> > +   AXI address  Command phase  Data phase
> > +   [31:24] Chip address   Chip address
> > +   [23]NoOfAddCycles_2Reserved
> > +   [22]NoOfAddCycles_1Reserved
> > +   [21]NoOfAddCycles_0ClearCS
> > +   [20]End command valid  End command valid
> > +   [19]0  1
> > +   [18:11] End commandEnd command
> > +   [10:3]  Start command  [10] ECC Last
> > +  [9:3] Reserved
> > +   [2:0]   Reserved   Reserved
> > +
> > +ECC
> > +===
> > +It operates on a number of 512 byte blocks of NAND memory and can
> > +be programmed to store the ECC codes after the data in memory. For
> > +writes, the ECC is written to the spare area of the page. For reads,
> > +the result of a block ECC check are made available to the device driver.
> > +
> > +-
> > +---
> > +|   n * 512 blocks  | extra  | ecc| |
> > +|   | block  | codes  | |
> > +-
> > +---
> > +
> > +The ECC calculation uses a simple Hamming code, using 1-bit
> > +correction 2-bit detection. It starts when a valid read or write
> > +command with a 512 byte aligned address is detected on the memory
> interface.
> > +
> > +Driver details
> > +==
> > +   The NAND driver has dependency with the pl353_smc memory
> controller
> > +driver for intializing the nand timing parameters, bus width, ECC
> > +modes,
> 
>   initializing the NAND
> 
> > +control and status information.
> > +
> > +Since the controller expects that the chipselect bit should be
> > +cleared for the last data transfer i.e last 4 data bytes, the
> > +existing nandbase page read/write routines 

Re: [PATCH v5 4/5] typec: tcpm: Represent source supply through power_supply

[Guenter Roeck]

On 03/20/2018 07:33 AM, Adam Thomson wrote:

This commit adds a power_supply class instance to represent a
PD source's voltage and current properties. This provides an
interface for reading these properties from user-space or other
drivers.

For PPS enabled Sources, this also provides write access to set
the current and voltage and allows for swapping between standard
PDO and PPS APDO.

As this represents a superset of the information provided in the
fusb302 driver, the power_supply instance in that code is removed
as part of this change, so reverting the commit titled
'typec: tcpm: Represent source supply through power_supply class'

Signed-off-by: Adam Thomson 
---
  drivers/usb/typec/Kconfig   |   1 +
  drivers/usb/typec/fusb302/Kconfig   |   2 +-
  drivers/usb/typec/fusb302/fusb302.c |  63 +-
  drivers/usb/typec/tcpm.c| 242 +++-
  4 files changed, 245 insertions(+), 63 deletions(-)

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bcb2744..1ef606d 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -48,6 +48,7 @@ if TYPEC
  config TYPEC_TCPM
tristate "USB Type-C Port Controller Manager"
depends on USB
+   select POWER_SUPPLY
help
  The Type-C Port Controller Manager provides a USB PD and USB Type-C
  state machine for use with Type-C Port Controllers.
diff --git a/drivers/usb/typec/fusb302/Kconfig 
b/drivers/usb/typec/fusb302/Kconfig
index 48a4f2f..fce099f 100644
--- a/drivers/usb/typec/fusb302/Kconfig
+++ b/drivers/usb/typec/fusb302/Kconfig
@@ -1,6 +1,6 @@
  config TYPEC_FUSB302
tristate "Fairchild FUSB302 Type-C chip driver"
-   depends on I2C && POWER_SUPPLY
+   depends on I2C
help
  The Fairchild FUSB302 Type-C chip driver that works with
  Type-C Port Controller Manager to provide USB PD and USB
diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 06794c0..6a8f279 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -18,7 +18,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
@@ -99,11 +98,6 @@ struct fusb302_chip {
/* lock for sharing chip states */
struct mutex lock;
  
-	/* psy + psy status */

-   struct power_supply *psy;
-   u32 current_limit;
-   u32 supply_voltage;
-
/* chip status */
enum toggling_mode toggling_mode;
enum src_current_status src_current_status;
@@ -861,13 +855,11 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on, 
bool charge)
chip->vbus_on = on;
fusb302_log(chip, "vbus := %s", on ? "On" : "Off");
}
-   if (chip->charge_on == charge) {
+   if (chip->charge_on == charge)
fusb302_log(chip, "charge is already %s",
charge ? "On" : "Off");
-   } else {
+   else
chip->charge_on = charge;
-   power_supply_changed(chip->psy);
-   }
  
  done:

mutex_unlock(>lock);
@@ -883,11 +875,6 @@ static int tcpm_set_current_limit(struct tcpc_dev *dev, 
u32 max_ma, u32 mv)
fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
max_ma, mv);
  
-	chip->supply_voltage = mv;

-   chip->current_limit = max_ma;
-
-   power_supply_changed(chip->psy);
-
return 0;
  }
  
@@ -1686,43 +1673,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id)

return IRQ_HANDLED;
  }
  
-static int fusb302_psy_get_property(struct power_supply *psy,

-   enum power_supply_property psp,
-   union power_supply_propval *val)
-{
-   struct fusb302_chip *chip = power_supply_get_drvdata(psy);
-
-   switch (psp) {
-   case POWER_SUPPLY_PROP_ONLINE:
-   val->intval = chip->charge_on;
-   break;
-   case POWER_SUPPLY_PROP_VOLTAGE_NOW:
-   val->intval = chip->supply_voltage * 1000; /* mV -> µV */
-   break;
-   case POWER_SUPPLY_PROP_CURRENT_MAX:
-   val->intval = chip->current_limit * 1000; /* mA -> µA */
-   break;
-   default:
-   return -ENODATA;
-   }
-
-   return 0;
-}
-
-static enum power_supply_property fusb302_psy_properties[] = {
-   POWER_SUPPLY_PROP_ONLINE,
-   POWER_SUPPLY_PROP_VOLTAGE_NOW,
-   POWER_SUPPLY_PROP_CURRENT_MAX,
-};
-
-static const struct power_supply_desc fusb302_psy_desc = {
-   .name   = "fusb302-typec-source",
-   .type   = POWER_SUPPLY_TYPE_USB_TYPE_C,
-   .properties = fusb302_psy_properties,
-   .num_properties = ARRAY_SIZE(fusb302_psy_properties),
-   .get_property   = fusb302_psy_get_property,
-};
-
  static int init_gpio(struct fusb302_chip *chip)
  {
 

Re: [PATCH v5 4/5] typec: tcpm: Represent source supply through power_supply

[Guenter Roeck]

On 03/20/2018 07:33 AM, Adam Thomson wrote:

This commit adds a power_supply class instance to represent a
PD source's voltage and current properties. This provides an
interface for reading these properties from user-space or other
drivers.

For PPS enabled Sources, this also provides write access to set
the current and voltage and allows for swapping between standard
PDO and PPS APDO.

As this represents a superset of the information provided in the
fusb302 driver, the power_supply instance in that code is removed
as part of this change, so reverting the commit titled
'typec: tcpm: Represent source supply through power_supply class'

Signed-off-by: Adam Thomson 
---
  drivers/usb/typec/Kconfig   |   1 +
  drivers/usb/typec/fusb302/Kconfig   |   2 +-
  drivers/usb/typec/fusb302/fusb302.c |  63 +-
  drivers/usb/typec/tcpm.c| 242 +++-
  4 files changed, 245 insertions(+), 63 deletions(-)

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bcb2744..1ef606d 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -48,6 +48,7 @@ if TYPEC
  config TYPEC_TCPM
tristate "USB Type-C Port Controller Manager"
depends on USB
+   select POWER_SUPPLY
help
  The Type-C Port Controller Manager provides a USB PD and USB Type-C
  state machine for use with Type-C Port Controllers.
diff --git a/drivers/usb/typec/fusb302/Kconfig 
b/drivers/usb/typec/fusb302/Kconfig
index 48a4f2f..fce099f 100644
--- a/drivers/usb/typec/fusb302/Kconfig
+++ b/drivers/usb/typec/fusb302/Kconfig
@@ -1,6 +1,6 @@
  config TYPEC_FUSB302
tristate "Fairchild FUSB302 Type-C chip driver"
-   depends on I2C && POWER_SUPPLY
+   depends on I2C
help
  The Fairchild FUSB302 Type-C chip driver that works with
  Type-C Port Controller Manager to provide USB PD and USB
diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 06794c0..6a8f279 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -18,7 +18,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
@@ -99,11 +98,6 @@ struct fusb302_chip {
/* lock for sharing chip states */
struct mutex lock;
  
-	/* psy + psy status */

-   struct power_supply *psy;
-   u32 current_limit;
-   u32 supply_voltage;
-
/* chip status */
enum toggling_mode toggling_mode;
enum src_current_status src_current_status;
@@ -861,13 +855,11 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on, 
bool charge)
chip->vbus_on = on;
fusb302_log(chip, "vbus := %s", on ? "On" : "Off");
}
-   if (chip->charge_on == charge) {
+   if (chip->charge_on == charge)
fusb302_log(chip, "charge is already %s",
charge ? "On" : "Off");
-   } else {
+   else
chip->charge_on = charge;
-   power_supply_changed(chip->psy);
-   }
  
  done:

mutex_unlock(>lock);
@@ -883,11 +875,6 @@ static int tcpm_set_current_limit(struct tcpc_dev *dev, 
u32 max_ma, u32 mv)
fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
max_ma, mv);
  
-	chip->supply_voltage = mv;

-   chip->current_limit = max_ma;
-
-   power_supply_changed(chip->psy);
-
return 0;
  }
  
@@ -1686,43 +1673,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id)

return IRQ_HANDLED;
  }
  
-static int fusb302_psy_get_property(struct power_supply *psy,

-   enum power_supply_property psp,
-   union power_supply_propval *val)
-{
-   struct fusb302_chip *chip = power_supply_get_drvdata(psy);
-
-   switch (psp) {
-   case POWER_SUPPLY_PROP_ONLINE:
-   val->intval = chip->charge_on;
-   break;
-   case POWER_SUPPLY_PROP_VOLTAGE_NOW:
-   val->intval = chip->supply_voltage * 1000; /* mV -> µV */
-   break;
-   case POWER_SUPPLY_PROP_CURRENT_MAX:
-   val->intval = chip->current_limit * 1000; /* mA -> µA */
-   break;
-   default:
-   return -ENODATA;
-   }
-
-   return 0;
-}
-
-static enum power_supply_property fusb302_psy_properties[] = {
-   POWER_SUPPLY_PROP_ONLINE,
-   POWER_SUPPLY_PROP_VOLTAGE_NOW,
-   POWER_SUPPLY_PROP_CURRENT_MAX,
-};
-
-static const struct power_supply_desc fusb302_psy_desc = {
-   .name   = "fusb302-typec-source",
-   .type   = POWER_SUPPLY_TYPE_USB_TYPE_C,
-   .properties = fusb302_psy_properties,
-   .num_properties = ARRAY_SIZE(fusb302_psy_properties),
-   .get_property   = fusb302_psy_get_property,
-};
-
  static int init_gpio(struct fusb302_chip *chip)
  {
struct device_node *node;
@@ 

Re: [PATCH v5 3/5] power: supply: Add 'usb_type' property and supporting code

[Guenter Roeck]

On 03/20/2018 07:33 AM, Adam Thomson wrote:

This commit adds the 'usb_type' property to represent USB supplies
which can report a number of different types based on a connection
event.

Examples of this already exist in drivers whereby the existing 'type'
property is updated, based on an event, to represent what was
connected (e.g. USB, USB_DCP, USB_ACA, ...). Current implementations
however don't show all supported connectable types, so this knowledge
has to be exlicitly known for each driver that supports this.

The 'usb_type' property is intended to fill this void and show users
all possible USB types supported by a driver. The property, when read,
shows all available types for the driver, and the one currently chosen
is highlighted/bracketed. It is expected that the 'type' property
would then just show the top-level type 'USB', and this would be
static.

Currently the 'usb_type' enum contains all of the USB variant types
that exist for the 'type' enum at this time, and in addition has
SDP and PPS types. The mirroring is intentional so as to not impact
existing usage of the 'type' property.

Signed-off-by: Adam Thomson 
Acked-by: Heikki Krogerus 
Reviewed-by: Sebastian Reichel 
---
  Documentation/ABI/testing/sysfs-class-power | 12 +++
  drivers/power/supply/power_supply_sysfs.c   | 50 +
  include/linux/power_supply.h| 16 +
  3 files changed, 78 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-power 
b/Documentation/ABI/testing/sysfs-class-power
index e046566..5e23e22 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -409,6 +409,18 @@ Description:
Access: Read
Valid values: Represented in 1/10 Degrees Celsius
  
+What: 		/sys/class/power_supply//usb_type

+Date:  March 2018
+Contact:   linux...@vger.kernel.org
+Description:
+   Reports what type of USB connection is currently active for
+   the supply, for example it can show if USB-PD capable source
+   is attached.
+
+   Access: Read-Only
+   Valid values: "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
+ "PD_DRP", "PD_PPS", "BrickID"
+
  What: /sys/class/power_supply//voltage_max
  Date: January 2008
  Contact:  linux...@vger.kernel.org
diff --git a/drivers/power/supply/power_supply_sysfs.c 
b/drivers/power/supply/power_supply_sysfs.c
index 5204f11..b68def4 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -46,6 +46,11 @@
"USB_PD", "USB_PD_DRP", "BrickID"
  };
  
+static const char * const power_supply_usb_type_text[] = {

+   "Unknown", "SDP", "DCP", "CDP", "ACA", "C",
+   "PD", "PD_DRP", "PD_PPS", "BrickID"
+};
+
  static const char * const power_supply_status_text[] = {
"Unknown", "Charging", "Discharging", "Not charging", "Full"
  };
@@ -73,6 +78,46 @@
"Unknown", "System", "Device"
  };
  
+static ssize_t power_supply_show_usb_type(struct device *dev,

+ enum power_supply_usb_type *usb_types,
+ ssize_t num_usb_types,
+ union power_supply_propval *value,
+ char *buf)
+{
+   enum power_supply_usb_type usb_type;
+   ssize_t count = 0;
+   bool match = false;
+   int i;
+
+   if ((!usb_types) || (num_usb_types <= 0)) {


Unnecessary ( )


+   dev_warn(dev, "driver has no valid connected types\n");


Are those warnings useful or do they just clog the log ? Either case, if that 
happens,
wouldn't it be better to detect the situation during registration and abort ?


+   return -ENODATA;
+   }
+
+   for (i = 0; i < num_usb_types; ++i) {
+   usb_type = usb_types[i];
+
+   if (value->intval == usb_type) {
+   count += sprintf(buf + count, "[%s] ",
+power_supply_usb_type_text[usb_type]);
+   match = true;
+   } else {
+   count += sprintf(buf + count, "%s ",
+power_supply_usb_type_text[usb_type]);
+   }
+   }
+
+   if (!match) {
+   dev_warn(dev, "driver reporting unsupported connected type\n");
+   return -EINVAL;
+   }
+
+   if (count)
+   buf[count - 1] = '\n';
+
+   return count;
+}
+
  static ssize_t power_supply_show_property(struct device *dev,
  struct device_attribute *attr,
  char *buf) {
@@ -115,6 +160,10 @@ static ssize_t 

Re: [PATCH v5 3/5] power: supply: Add 'usb_type' property and supporting code

[Guenter Roeck]

On 03/20/2018 07:33 AM, Adam Thomson wrote:

This commit adds the 'usb_type' property to represent USB supplies
which can report a number of different types based on a connection
event.

Examples of this already exist in drivers whereby the existing 'type'
property is updated, based on an event, to represent what was
connected (e.g. USB, USB_DCP, USB_ACA, ...). Current implementations
however don't show all supported connectable types, so this knowledge
has to be exlicitly known for each driver that supports this.

The 'usb_type' property is intended to fill this void and show users
all possible USB types supported by a driver. The property, when read,
shows all available types for the driver, and the one currently chosen
is highlighted/bracketed. It is expected that the 'type' property
would then just show the top-level type 'USB', and this would be
static.

Currently the 'usb_type' enum contains all of the USB variant types
that exist for the 'type' enum at this time, and in addition has
SDP and PPS types. The mirroring is intentional so as to not impact
existing usage of the 'type' property.

Signed-off-by: Adam Thomson 
Acked-by: Heikki Krogerus 
Reviewed-by: Sebastian Reichel 
---
  Documentation/ABI/testing/sysfs-class-power | 12 +++
  drivers/power/supply/power_supply_sysfs.c   | 50 +
  include/linux/power_supply.h| 16 +
  3 files changed, 78 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-power 
b/Documentation/ABI/testing/sysfs-class-power
index e046566..5e23e22 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -409,6 +409,18 @@ Description:
Access: Read
Valid values: Represented in 1/10 Degrees Celsius
  
+What: 		/sys/class/power_supply//usb_type

+Date:  March 2018
+Contact:   linux...@vger.kernel.org
+Description:
+   Reports what type of USB connection is currently active for
+   the supply, for example it can show if USB-PD capable source
+   is attached.
+
+   Access: Read-Only
+   Valid values: "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
+ "PD_DRP", "PD_PPS", "BrickID"
+
  What: /sys/class/power_supply//voltage_max
  Date: January 2008
  Contact:  linux...@vger.kernel.org
diff --git a/drivers/power/supply/power_supply_sysfs.c 
b/drivers/power/supply/power_supply_sysfs.c
index 5204f11..b68def4 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -46,6 +46,11 @@
"USB_PD", "USB_PD_DRP", "BrickID"
  };
  
+static const char * const power_supply_usb_type_text[] = {

+   "Unknown", "SDP", "DCP", "CDP", "ACA", "C",
+   "PD", "PD_DRP", "PD_PPS", "BrickID"
+};
+
  static const char * const power_supply_status_text[] = {
"Unknown", "Charging", "Discharging", "Not charging", "Full"
  };
@@ -73,6 +78,46 @@
"Unknown", "System", "Device"
  };
  
+static ssize_t power_supply_show_usb_type(struct device *dev,

+ enum power_supply_usb_type *usb_types,
+ ssize_t num_usb_types,
+ union power_supply_propval *value,
+ char *buf)
+{
+   enum power_supply_usb_type usb_type;
+   ssize_t count = 0;
+   bool match = false;
+   int i;
+
+   if ((!usb_types) || (num_usb_types <= 0)) {


Unnecessary ( )


+   dev_warn(dev, "driver has no valid connected types\n");


Are those warnings useful or do they just clog the log ? Either case, if that 
happens,
wouldn't it be better to detect the situation during registration and abort ?


+   return -ENODATA;
+   }
+
+   for (i = 0; i < num_usb_types; ++i) {
+   usb_type = usb_types[i];
+
+   if (value->intval == usb_type) {
+   count += sprintf(buf + count, "[%s] ",
+power_supply_usb_type_text[usb_type]);
+   match = true;
+   } else {
+   count += sprintf(buf + count, "%s ",
+power_supply_usb_type_text[usb_type]);
+   }
+   }
+
+   if (!match) {
+   dev_warn(dev, "driver reporting unsupported connected type\n");
+   return -EINVAL;
+   }
+
+   if (count)
+   buf[count - 1] = '\n';
+
+   return count;
+}
+
  static ssize_t power_supply_show_property(struct device *dev,
  struct device_attribute *attr,
  char *buf) {
@@ -115,6 +160,10 @@ static ssize_t power_supply_show_property(struct device 
*dev,
else if (off == POWER_SUPPLY_PROP_TYPE)
return 

Re: [PATCH v5 1/5] typec: tcpm: Add core support for sink side PPS

[Guenter Roeck]

On 03/20/2018 07:33 AM, Adam Thomson wrote:

This commit adds code to handle requesting of PPS APDOs. Switching
between standard PDOs and APDOs, and re-requesting an APDO to
modify operating voltage/current will be triggered by an
external call into TCPM.

Signed-off-by: Adam Thomson 
Acked-by: Heikki Krogerus 
---
  drivers/usb/typec/tcpm.c | 524 +--
  include/linux/usb/pd.h   |   4 +-
  include/linux/usb/tcpm.h |   2 +-
  3 files changed, 513 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 4c0fc54..b4cf1ca 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -47,6 +47,7 @@
S(SNK_DISCOVERY_DEBOUNCE_DONE), \
S(SNK_WAIT_CAPABILITIES),   \
S(SNK_NEGOTIATE_CAPABILITIES),  \
+   S(SNK_NEGOTIATE_PPS_CAPABILITIES),  \
S(SNK_TRANSITION_SINK), \
S(SNK_TRANSITION_SINK_VBUS),\
S(SNK_READY),   \
@@ -166,6 +167,16 @@ struct pd_mode_data {
struct typec_altmode_desc altmode_desc[SVID_DISCOVERY_MAX];
  };
  
+struct pd_pps_data {

+   u32 min_volt;
+   u32 max_volt;
+   u32 max_curr;
+   u32 out_volt;
+   u32 op_curr;
+   bool supported;
+   bool active;
+};
+
  struct tcpm_port {
struct device *dev;
  
@@ -233,6 +244,7 @@ struct tcpm_port {

struct completion swap_complete;
int swap_status;
  
+	unsigned int negotiated_rev;

unsigned int message_id;
unsigned int caps_count;
unsigned int hard_reset_count;
@@ -259,6 +271,7 @@ struct tcpm_port {
unsigned int max_snk_ma;
unsigned int max_snk_mw;
unsigned int operating_snk_mw;
+   bool update_sink_caps;
  
  	/* Requested current / voltage */

u32 current_limit;
@@ -275,8 +288,13 @@ struct tcpm_port {
/* VDO to retry if UFP responder replied busy */
u32 vdo_retry;
  
-	/* Alternate mode data */

+   /* PPS */
+   struct pd_pps_data pps_data;
+   struct completion pps_complete;
+   bool pps_pending;
+   int pps_status;
  
+	/* Alternate mode data */

struct pd_mode_data mode_data;
struct typec_altmode *partner_altmode[SVID_DISCOVERY_MAX];
struct typec_altmode *port_altmode[SVID_DISCOVERY_MAX];
@@ -494,6 +512,16 @@ static void tcpm_log_source_caps(struct tcpm_port *port)
  pdo_max_voltage(pdo),
  pdo_max_power(pdo));
break;
+   case PDO_TYPE_APDO:
+   if (pdo_apdo_type(pdo) == APDO_TYPE_PPS)
+   scnprintf(msg, sizeof(msg),
+ "%u-%u mV, %u mA",
+ pdo_pps_apdo_min_voltage(pdo),
+ pdo_pps_apdo_max_voltage(pdo),
+ pdo_pps_apdo_max_current(pdo));
+   else
+   strcpy(msg, "undefined APDO");
+   break;
default:
strcpy(msg, "undefined");
break;
@@ -777,11 +805,13 @@ static int tcpm_pd_send_source_caps(struct tcpm_port 
*port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SOURCE_CAP,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id,
  port->nr_src_pdo);
}
@@ -802,11 +832,13 @@ static int tcpm_pd_send_sink_caps(struct tcpm_port *port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SINK_CAP,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id,
  port->nr_snk_pdo);
}
@@ -1173,6 +1205,7 @@ static void vdm_run_state_machine(struct tcpm_port *port)

Re: [PATCH v5 1/5] typec: tcpm: Add core support for sink side PPS

[Guenter Roeck]

On 03/20/2018 07:33 AM, Adam Thomson wrote:

This commit adds code to handle requesting of PPS APDOs. Switching
between standard PDOs and APDOs, and re-requesting an APDO to
modify operating voltage/current will be triggered by an
external call into TCPM.

Signed-off-by: Adam Thomson 
Acked-by: Heikki Krogerus 
---
  drivers/usb/typec/tcpm.c | 524 +--
  include/linux/usb/pd.h   |   4 +-
  include/linux/usb/tcpm.h |   2 +-
  3 files changed, 513 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 4c0fc54..b4cf1ca 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -47,6 +47,7 @@
S(SNK_DISCOVERY_DEBOUNCE_DONE), \
S(SNK_WAIT_CAPABILITIES),   \
S(SNK_NEGOTIATE_CAPABILITIES),  \
+   S(SNK_NEGOTIATE_PPS_CAPABILITIES),  \
S(SNK_TRANSITION_SINK), \
S(SNK_TRANSITION_SINK_VBUS),\
S(SNK_READY),   \
@@ -166,6 +167,16 @@ struct pd_mode_data {
struct typec_altmode_desc altmode_desc[SVID_DISCOVERY_MAX];
  };
  
+struct pd_pps_data {

+   u32 min_volt;
+   u32 max_volt;
+   u32 max_curr;
+   u32 out_volt;
+   u32 op_curr;
+   bool supported;
+   bool active;
+};
+
  struct tcpm_port {
struct device *dev;
  
@@ -233,6 +244,7 @@ struct tcpm_port {

struct completion swap_complete;
int swap_status;
  
+	unsigned int negotiated_rev;

unsigned int message_id;
unsigned int caps_count;
unsigned int hard_reset_count;
@@ -259,6 +271,7 @@ struct tcpm_port {
unsigned int max_snk_ma;
unsigned int max_snk_mw;
unsigned int operating_snk_mw;
+   bool update_sink_caps;
  
  	/* Requested current / voltage */

u32 current_limit;
@@ -275,8 +288,13 @@ struct tcpm_port {
/* VDO to retry if UFP responder replied busy */
u32 vdo_retry;
  
-	/* Alternate mode data */

+   /* PPS */
+   struct pd_pps_data pps_data;
+   struct completion pps_complete;
+   bool pps_pending;
+   int pps_status;
  
+	/* Alternate mode data */

struct pd_mode_data mode_data;
struct typec_altmode *partner_altmode[SVID_DISCOVERY_MAX];
struct typec_altmode *port_altmode[SVID_DISCOVERY_MAX];
@@ -494,6 +512,16 @@ static void tcpm_log_source_caps(struct tcpm_port *port)
  pdo_max_voltage(pdo),
  pdo_max_power(pdo));
break;
+   case PDO_TYPE_APDO:
+   if (pdo_apdo_type(pdo) == APDO_TYPE_PPS)
+   scnprintf(msg, sizeof(msg),
+ "%u-%u mV, %u mA",
+ pdo_pps_apdo_min_voltage(pdo),
+ pdo_pps_apdo_max_voltage(pdo),
+ pdo_pps_apdo_max_current(pdo));
+   else
+   strcpy(msg, "undefined APDO");
+   break;
default:
strcpy(msg, "undefined");
break;
@@ -777,11 +805,13 @@ static int tcpm_pd_send_source_caps(struct tcpm_port 
*port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SOURCE_CAP,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id,
  port->nr_src_pdo);
}
@@ -802,11 +832,13 @@ static int tcpm_pd_send_sink_caps(struct tcpm_port *port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SINK_CAP,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id,
  port->nr_snk_pdo);
}
@@ -1173,6 +1205,7 @@ static void vdm_run_state_machine(struct tcpm_port *port)
msg.header = PD_HEADER_LE(PD_DATA_VENDOR_DEF,

Re: [PATCH v5 5/5] typec: tcpm: Add support for sink PPS related messages

[Guenter Roeck]

On 03/20/2018 07:33 AM, Adam Thomson wrote:

This commit adds sink side support for Get_Status, Status,
Get_PPS_Status and PPS_Status handling. As there's the
potential for a partner to respond with Not_Supported,
handling of this message is also added. Sending of
Not_Supported is added to handle messagescreceived but not
yet handled.

Signed-off-by: Adam Thomson 
Acked-by: Heikki Krogerus 
---
  drivers/usb/typec/tcpm.c | 152 ---
  1 file changed, 143 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 18ab36f..148db99 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -19,7 +19,9 @@
  #include 
  #include 
  #include 
+#include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -113,6 +115,11 @@
S(SNK_TRYWAIT_VBUS),\
S(BIST_RX), \
\
+   S(GET_STATUS_SEND), \
+   S(GET_STATUS_SEND_TIMEOUT), \
+   S(GET_PPS_STATUS_SEND), \
+   S(GET_PPS_STATUS_SEND_TIMEOUT), \
+   \
S(ERROR_RECOVERY),  \
S(PORT_RESET),  \
S(PORT_RESET_WAIT_OFF)
@@ -143,6 +150,7 @@ enum pd_msg_request {
PD_MSG_NONE = 0,
PD_MSG_CTRL_REJECT,
PD_MSG_CTRL_WAIT,
+   PD_MSG_CTRL_NOT_SUPP,
PD_MSG_DATA_SINK_CAP,
PD_MSG_DATA_SOURCE_CAP,
  };
@@ -1398,10 +1406,42 @@ static int tcpm_validate_caps(struct tcpm_port *port, 
const u32 *pdo,
  /*
   * PD (data, control) command handling functions
   */
+static inline enum tcpm_state ready_state(struct tcpm_port *port)
+{
+   if (port->pwr_role == TYPEC_SOURCE)
+   return SRC_READY;
+   else
+   return SNK_READY;
+}
  
  static int tcpm_pd_send_control(struct tcpm_port *port,

enum pd_ctrl_msg_type type);
  
+static void tcpm_handle_alert(struct tcpm_port *port, const __le32 *payload,

+ int cnt)
+{
+   u32 p0 = le32_to_cpu(payload[0]);
+   unsigned int type = usb_pd_ado_type(p0);
+
+   if (!type) {
+   tcpm_log(port, "Alert message received with no type");
+   return;
+   }
+
+   /* Just handling non-battery alerts for now */
+   if (!(type & USB_PD_ADO_TYPE_BATT_STATUS_CHANGE)) {
+   switch (port->state) {
+   case SRC_READY:
+   case SNK_READY:
+   tcpm_set_state(port, GET_STATUS_SEND, 0);
+   break;
+   default:
+   tcpm_queue_message(port, PD_MSG_CTRL_WAIT);
+   break;
+   }
+   }
+}
+
  static void tcpm_pd_data_request(struct tcpm_port *port,
 const struct pd_message *msg)
  {
@@ -1487,6 +1527,14 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
tcpm_set_state(port, BIST_RX, 0);
}
break;
+   case PD_DATA_ALERT:
+   tcpm_handle_alert(port, msg->payload, cnt);
+   break;
+   case PD_DATA_BATT_STATUS:
+   case PD_DATA_GET_COUNTRY_INFO:
+   /* Currently unsupported */
+   tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+   break;
default:
tcpm_log(port, "Unhandled data message type %#x", type);
break;
@@ -1569,6 +1617,7 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
case PD_CTRL_REJECT:
case PD_CTRL_WAIT:
+   case PD_CTRL_NOT_SUPP:
switch (port->state) {
case SNK_NEGOTIATE_CAPABILITIES:
/* USB PD specification, Figure 8-43 */
@@ -1688,12 +1737,84 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
}
break;
+   case PD_CTRL_GET_SOURCE_CAP_EXT:
+   case PD_CTRL_GET_STATUS:
+   case PD_CTRL_FR_SWAP:
+   case PD_CTRL_GET_PPS_STATUS:
+   case PD_CTRL_GET_COUNTRY_CODES:
+   /* Currently not supported */
+   tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+   break;
default:
tcpm_log(port, "Unhandled ctrl message type %#x", type);
break;
}
  }
  
+static void tcpm_pd_ext_msg_request(struct tcpm_port *port,

+   const struct pd_message *msg)
+{
+   enum pd_ext_msg_type type = pd_header_type_le(msg->header);
+   unsigned int data_size = 
pd_ext_header_data_size_le(msg->ext_msg.header);
+   u8 *data;
+
+   if (!(msg->ext_msg.header && PD_EXT_HDR_CHUNKED)) {
+   

Re: [PATCH v5 5/5] typec: tcpm: Add support for sink PPS related messages

[Guenter Roeck]

On 03/20/2018 07:33 AM, Adam Thomson wrote:

This commit adds sink side support for Get_Status, Status,
Get_PPS_Status and PPS_Status handling. As there's the
potential for a partner to respond with Not_Supported,
handling of this message is also added. Sending of
Not_Supported is added to handle messagescreceived but not
yet handled.

Signed-off-by: Adam Thomson 
Acked-by: Heikki Krogerus 
---
  drivers/usb/typec/tcpm.c | 152 ---
  1 file changed, 143 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 18ab36f..148db99 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -19,7 +19,9 @@
  #include 
  #include 
  #include 
+#include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -113,6 +115,11 @@
S(SNK_TRYWAIT_VBUS),\
S(BIST_RX), \
\
+   S(GET_STATUS_SEND), \
+   S(GET_STATUS_SEND_TIMEOUT), \
+   S(GET_PPS_STATUS_SEND), \
+   S(GET_PPS_STATUS_SEND_TIMEOUT), \
+   \
S(ERROR_RECOVERY),  \
S(PORT_RESET),  \
S(PORT_RESET_WAIT_OFF)
@@ -143,6 +150,7 @@ enum pd_msg_request {
PD_MSG_NONE = 0,
PD_MSG_CTRL_REJECT,
PD_MSG_CTRL_WAIT,
+   PD_MSG_CTRL_NOT_SUPP,
PD_MSG_DATA_SINK_CAP,
PD_MSG_DATA_SOURCE_CAP,
  };
@@ -1398,10 +1406,42 @@ static int tcpm_validate_caps(struct tcpm_port *port, 
const u32 *pdo,
  /*
   * PD (data, control) command handling functions
   */
+static inline enum tcpm_state ready_state(struct tcpm_port *port)
+{
+   if (port->pwr_role == TYPEC_SOURCE)
+   return SRC_READY;
+   else
+   return SNK_READY;
+}
  
  static int tcpm_pd_send_control(struct tcpm_port *port,

enum pd_ctrl_msg_type type);
  
+static void tcpm_handle_alert(struct tcpm_port *port, const __le32 *payload,

+ int cnt)
+{
+   u32 p0 = le32_to_cpu(payload[0]);
+   unsigned int type = usb_pd_ado_type(p0);
+
+   if (!type) {
+   tcpm_log(port, "Alert message received with no type");
+   return;
+   }
+
+   /* Just handling non-battery alerts for now */
+   if (!(type & USB_PD_ADO_TYPE_BATT_STATUS_CHANGE)) {
+   switch (port->state) {
+   case SRC_READY:
+   case SNK_READY:
+   tcpm_set_state(port, GET_STATUS_SEND, 0);
+   break;
+   default:
+   tcpm_queue_message(port, PD_MSG_CTRL_WAIT);
+   break;
+   }
+   }
+}
+
  static void tcpm_pd_data_request(struct tcpm_port *port,
 const struct pd_message *msg)
  {
@@ -1487,6 +1527,14 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
tcpm_set_state(port, BIST_RX, 0);
}
break;
+   case PD_DATA_ALERT:
+   tcpm_handle_alert(port, msg->payload, cnt);
+   break;
+   case PD_DATA_BATT_STATUS:
+   case PD_DATA_GET_COUNTRY_INFO:
+   /* Currently unsupported */
+   tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+   break;
default:
tcpm_log(port, "Unhandled data message type %#x", type);
break;
@@ -1569,6 +1617,7 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
case PD_CTRL_REJECT:
case PD_CTRL_WAIT:
+   case PD_CTRL_NOT_SUPP:
switch (port->state) {
case SNK_NEGOTIATE_CAPABILITIES:
/* USB PD specification, Figure 8-43 */
@@ -1688,12 +1737,84 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
}
break;
+   case PD_CTRL_GET_SOURCE_CAP_EXT:
+   case PD_CTRL_GET_STATUS:
+   case PD_CTRL_FR_SWAP:
+   case PD_CTRL_GET_PPS_STATUS:
+   case PD_CTRL_GET_COUNTRY_CODES:
+   /* Currently not supported */
+   tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+   break;
default:
tcpm_log(port, "Unhandled ctrl message type %#x", type);
break;
}
  }
  
+static void tcpm_pd_ext_msg_request(struct tcpm_port *port,

+   const struct pd_message *msg)
+{
+   enum pd_ext_msg_type type = pd_header_type_le(msg->header);
+   unsigned int data_size = 
pd_ext_header_data_size_le(msg->ext_msg.header);
+   u8 *data;
+
+   if (!(msg->ext_msg.header && PD_EXT_HDR_CHUNKED)) {
+   tcpm_log(port, "Unchunked extended messages unsupported");
+   

[PATCH] watchdog: booke_wdt: Disable the watchdog prior to setting a new timeout value in order to avoid the following situation

[Xiaofeng Wei]

A watchdog timer exception also occurs if the selected time base bit 
transitions from 0 to 1 due
to an mtspr that writes a 1 to the bit when its previous value was 0.

Signed-off-by: Xiaofeng Wei 
---
 drivers/watchdog/booke_wdt.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 3ad1e44..70e742c 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -186,9 +186,15 @@ static int booke_wdt_stop(struct watchdog_device *wdog)
 static int booke_wdt_set_timeout(struct watchdog_device *wdt_dev,
 unsigned int timeout)
 {
+   if (watchdog_active(wdt_dev))
+   on_each_cpu(__booke_wdt_disable, NULL, 0);
+
wdt_dev->timeout = timeout;
booke_wdt_set(wdt_dev);
 
+   if (watchdog_active(wdt_dev))
+   on_each_cpu(__booke_wdt_enable, wdt_dev, 0);
+
return 0;
 }
 
-- 
2.9.3

[PATCH] watchdog: booke_wdt: Disable the watchdog prior to setting a new timeout value in order to avoid the following situation

[Xiaofeng Wei]

A watchdog timer exception also occurs if the selected time base bit 
transitions from 0 to 1 due
to an mtspr that writes a 1 to the bit when its previous value was 0.

Signed-off-by: Xiaofeng Wei 
---
 drivers/watchdog/booke_wdt.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 3ad1e44..70e742c 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -186,9 +186,15 @@ static int booke_wdt_stop(struct watchdog_device *wdog)
 static int booke_wdt_set_timeout(struct watchdog_device *wdt_dev,
 unsigned int timeout)
 {
+   if (watchdog_active(wdt_dev))
+   on_each_cpu(__booke_wdt_disable, NULL, 0);
+
wdt_dev->timeout = timeout;
booke_wdt_set(wdt_dev);
 
+   if (watchdog_active(wdt_dev))
+   on_each_cpu(__booke_wdt_enable, wdt_dev, 0);
+
return 0;
 }
 
-- 
2.9.3

[PATCH 0/2] Kexec_file: Load kernel at top of system ram

[Baoquan He]

The current kexec_file ignores kexec_buf.top_down value when call
arch_kexec_walk_mem() to allocate memory for loading kernel/initrd
stuffs. This is not supposed to be what kexec_buf.top_down is used
for.

In patch 0001, introduce a new function walk_system_ram_res_rev()
which is a variant of walk_system_ram_res(), walks through resources
of System RAM from top to down. And patch 0001 is picked from AKASHI's
patchset which adds arm64 kexec_file support. His next round of post
won't need walk_system_ram_res_rev any more, so I take it into this
patchset and use it in patch 0002.

In patch 0002, check kexec_buf.top_down in arch_kexec_walk_mem(),
if its value is 'true', call walk_system_ram_res_rev(). Otherwise
call walk_system_ram_res().

AKASHI Takahiro (1):
  resource: add walk_system_ram_res_rev()

Baoquan He (1):
  kexec_file: Load kernel at top of system RAM if required

 include/linux/ioport.h |  3 +++
 kernel/kexec_file.c|  2 ++
 kernel/resource.c  | 63 ++
 3 files changed, 68 insertions(+)

-- 
2.13.6

[PATCH 1/2] resource: add walk_system_ram_res_rev()

[Baoquan He]

From: AKASHI Takahiro 

This function, being a variant of walk_system_ram_res() introduced in
commit 8c86e70acead ("resource: provide new functions to walk through
resources"), walks through a list of all the resources of System RAM
in reversed order, i.e., from higher to lower.

It will be used in kexec_file code.

Signed-off-by: AKASHI Takahiro 
Signed-off-by: Baoquan He 

---
 include/linux/ioport.h |  3 +++
 kernel/resource.c  | 63 ++
 2 files changed, 66 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index da0ebaec25f0..f12d95fe038b 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -277,6 +277,9 @@ extern int
 walk_system_ram_res(u64 start, u64 end, void *arg,
int (*func)(struct resource *, void *));
 extern int
+walk_system_ram_res_rev(u64 start, u64 end, void *arg,
+   int (*func)(struct resource *, void *));
+extern int
 walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64 
end,
void *arg, int (*func)(struct resource *, void *));
 
diff --git a/kernel/resource.c b/kernel/resource.c
index e270b5048988..f456fc95f1b2 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 
@@ -470,6 +472,67 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
 }
 
 /*
+ * This function, being a variant of walk_system_ram_res(), calls the @func
+ * callback against all memory ranges of type System RAM which are marked as
+ * IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY in reversed order, i.e., from
+ * higher to lower.
+ */
+int walk_system_ram_res_rev(u64 start, u64 end, void *arg,
+   int (*func)(struct resource *, void *))
+{
+   struct resource res, *rams;
+   int rams_size = 16, i;
+   int ret = -1;
+
+   /* create a list */
+   rams = vmalloc(sizeof(struct resource) * rams_size);
+   if (!rams)
+   return ret;
+
+   res.start = start;
+   res.end = end;
+   res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
+   i = 0;
+   while ((res.start < res.end) &&
+   (!find_next_iomem_res(, IORES_DESC_NONE, true))) {
+   if (i >= rams_size) {
+   /* re-alloc */
+   struct resource *rams_new;
+   int rams_new_size;
+
+   rams_new_size = rams_size + 16;
+   rams_new = vmalloc(sizeof(struct resource)
+   * rams_new_size);
+   if (!rams_new)
+   goto out;
+
+   memcpy(rams_new, rams,
+   sizeof(struct resource) * rams_size);
+   vfree(rams);
+   rams = rams_new;
+   rams_size = rams_new_size;
+   }
+
+   rams[i].start = res.start;
+   rams[i++].end = res.end;
+
+   res.start = res.end + 1;
+   res.end = end;
+   }
+
+   /* go reverse */
+   for (i--; i >= 0; i--) {
+   ret = (*func)([i], arg);
+   if (ret)
+   break;
+   }
+
+out:
+   vfree(rams);
+   return ret;
+}
+
+/*
  * This function calls the @func callback against all memory ranges, which
  * are ranges marked as IORESOURCE_MEM and IORESOUCE_BUSY.
  */
-- 
2.13.6

[PATCH 0/2] Kexec_file: Load kernel at top of system ram

[Baoquan He]

The current kexec_file ignores kexec_buf.top_down value when call
arch_kexec_walk_mem() to allocate memory for loading kernel/initrd
stuffs. This is not supposed to be what kexec_buf.top_down is used
for.

In patch 0001, introduce a new function walk_system_ram_res_rev()
which is a variant of walk_system_ram_res(), walks through resources
of System RAM from top to down. And patch 0001 is picked from AKASHI's
patchset which adds arm64 kexec_file support. His next round of post
won't need walk_system_ram_res_rev any more, so I take it into this
patchset and use it in patch 0002.

In patch 0002, check kexec_buf.top_down in arch_kexec_walk_mem(),
if its value is 'true', call walk_system_ram_res_rev(). Otherwise
call walk_system_ram_res().

AKASHI Takahiro (1):
  resource: add walk_system_ram_res_rev()

Baoquan He (1):
  kexec_file: Load kernel at top of system RAM if required

 include/linux/ioport.h |  3 +++
 kernel/kexec_file.c|  2 ++
 kernel/resource.c  | 63 ++
 3 files changed, 68 insertions(+)

-- 
2.13.6

[PATCH 1/2] resource: add walk_system_ram_res_rev()

[Baoquan He]

From: AKASHI Takahiro 

This function, being a variant of walk_system_ram_res() introduced in
commit 8c86e70acead ("resource: provide new functions to walk through
resources"), walks through a list of all the resources of System RAM
in reversed order, i.e., from higher to lower.

It will be used in kexec_file code.

Signed-off-by: AKASHI Takahiro 
Signed-off-by: Baoquan He 

---
 include/linux/ioport.h |  3 +++
 kernel/resource.c  | 63 ++
 2 files changed, 66 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index da0ebaec25f0..f12d95fe038b 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -277,6 +277,9 @@ extern int
 walk_system_ram_res(u64 start, u64 end, void *arg,
int (*func)(struct resource *, void *));
 extern int
+walk_system_ram_res_rev(u64 start, u64 end, void *arg,
+   int (*func)(struct resource *, void *));
+extern int
 walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64 
end,
void *arg, int (*func)(struct resource *, void *));
 
diff --git a/kernel/resource.c b/kernel/resource.c
index e270b5048988..f456fc95f1b2 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 
@@ -470,6 +472,67 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
 }
 
 /*
+ * This function, being a variant of walk_system_ram_res(), calls the @func
+ * callback against all memory ranges of type System RAM which are marked as
+ * IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY in reversed order, i.e., from
+ * higher to lower.
+ */
+int walk_system_ram_res_rev(u64 start, u64 end, void *arg,
+   int (*func)(struct resource *, void *))
+{
+   struct resource res, *rams;
+   int rams_size = 16, i;
+   int ret = -1;
+
+   /* create a list */
+   rams = vmalloc(sizeof(struct resource) * rams_size);
+   if (!rams)
+   return ret;
+
+   res.start = start;
+   res.end = end;
+   res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
+   i = 0;
+   while ((res.start < res.end) &&
+   (!find_next_iomem_res(, IORES_DESC_NONE, true))) {
+   if (i >= rams_size) {
+   /* re-alloc */
+   struct resource *rams_new;
+   int rams_new_size;
+
+   rams_new_size = rams_size + 16;
+   rams_new = vmalloc(sizeof(struct resource)
+   * rams_new_size);
+   if (!rams_new)
+   goto out;
+
+   memcpy(rams_new, rams,
+   sizeof(struct resource) * rams_size);
+   vfree(rams);
+   rams = rams_new;
+   rams_size = rams_new_size;
+   }
+
+   rams[i].start = res.start;
+   rams[i++].end = res.end;
+
+   res.start = res.end + 1;
+   res.end = end;
+   }
+
+   /* go reverse */
+   for (i--; i >= 0; i--) {
+   ret = (*func)([i], arg);
+   if (ret)
+   break;
+   }
+
+out:
+   vfree(rams);
+   return ret;
+}
+
+/*
  * This function calls the @func callback against all memory ranges, which
  * are ranges marked as IORESOURCE_MEM and IORESOUCE_BUSY.
  */
-- 
2.13.6

[PATCH 2/2] kexec_file: Load kernel at top of system RAM if required

[Baoquan He]

For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
is used to load kernel/initrd/purgatory is supposed to be allocated from
top to down. This is also consistent with the old kexec loading interface.

However, the current arch_kexec_walk_mem() doesn't do like this. It ignores
checking kexec_buf.top_down, bug calls walk_system_ram_res() directly to go
through all resources of System RAM, to try to find memory region which can
contain the specific kexec buffer, then call locate_mem_hole_callback() to
allocate memory in that found memory region from top to down. This is not
right.

Here add checking if kexec_buf.top_down is 'true' in arch_kexec_walk_mem(),
if yes, call the newly added walk_system_ram_res_rev() to find memory region
from top to down to load kernel.

Signed-off-by: Baoquan He 
---
 kernel/kexec_file.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 57ec39995b23..76e6307f8971 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -445,6 +445,8 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
   IORESOURCE_SYSTEM_RAM | 
IORESOURCE_BUSY,
   crashk_res.start, crashk_res.end,
   kbuf, func);
+   else if (kbuf->top_down)
+   return walk_system_ram_res_rev(0, ULONG_MAX, kbuf, func);
else
return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
 }
-- 
2.13.6

[PATCH 2/2] kexec_file: Load kernel at top of system RAM if required

[Baoquan He]

For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
is used to load kernel/initrd/purgatory is supposed to be allocated from
top to down. This is also consistent with the old kexec loading interface.

However, the current arch_kexec_walk_mem() doesn't do like this. It ignores
checking kexec_buf.top_down, bug calls walk_system_ram_res() directly to go
through all resources of System RAM, to try to find memory region which can
contain the specific kexec buffer, then call locate_mem_hole_callback() to
allocate memory in that found memory region from top to down. This is not
right.

Here add checking if kexec_buf.top_down is 'true' in arch_kexec_walk_mem(),
if yes, call the newly added walk_system_ram_res_rev() to find memory region
from top to down to load kernel.

Signed-off-by: Baoquan He 
---
 kernel/kexec_file.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 57ec39995b23..76e6307f8971 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -445,6 +445,8 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
   IORESOURCE_SYSTEM_RAM | 
IORESOURCE_BUSY,
   crashk_res.start, crashk_res.end,
   kbuf, func);
+   else if (kbuf->top_down)
+   return walk_system_ram_res_rev(0, ULONG_MAX, kbuf, func);
else
return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
 }
-- 
2.13.6

[PATCH] arm: avoid race condition issue in dump_backtrace

[Ji Zhang]

When we dump the backtrace of some specific task, there is a potential race
condition due to the task may be running on other cores if SMP enabled.
That is because for current implementation, if the task is not the current
task, we will get the registers used for unwind from cpu_context saved in
thread_info, which the snapshot before context switch, but if the task is
running on other cores, the registers and the content of stack are changed.
This may cause that we get the wrong backtrace or incomplete backtrace or
even crash the kernel.
To avoid this case, do not dump the backtrace of the task which is running
on other cores.
This patch cannot solve the issue completely but can shrink the window of
race condition.

Signed-off-by: Ji Zhang 
---
 arch/arm/kernel/traps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 5e3633c..faa3d45 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -220,6 +220,10 @@ static void dump_backtrace(struct pt_regs *regs, struct 
task_struct *tsk)
fp = frame_pointer(regs);
mode = processor_mode(regs);
} else if (tsk != current) {
+   if (tsk->state == TASK_RUNNING) {
+   pr_notice("Do not dump other running tasks\n");
+   return;
+   }
fp = thread_saved_fp(tsk);
mode = 0x10;
} else {
-- 
1.9.1

[PATCH] arm: avoid race condition issue in dump_backtrace

[Ji Zhang]

When we dump the backtrace of some specific task, there is a potential race
condition due to the task may be running on other cores if SMP enabled.
That is because for current implementation, if the task is not the current
task, we will get the registers used for unwind from cpu_context saved in
thread_info, which the snapshot before context switch, but if the task is
running on other cores, the registers and the content of stack are changed.
This may cause that we get the wrong backtrace or incomplete backtrace or
even crash the kernel.
To avoid this case, do not dump the backtrace of the task which is running
on other cores.
This patch cannot solve the issue completely but can shrink the window of
race condition.

Signed-off-by: Ji Zhang 
---
 arch/arm/kernel/traps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 5e3633c..faa3d45 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -220,6 +220,10 @@ static void dump_backtrace(struct pt_regs *regs, struct 
task_struct *tsk)
fp = frame_pointer(regs);
mode = processor_mode(regs);
} else if (tsk != current) {
+   if (tsk->state == TASK_RUNNING) {
+   pr_notice("Do not dump other running tasks\n");
+   return;
+   }
fp = thread_saved_fp(tsk);
mode = 0x10;
} else {
-- 
1.9.1

Re: [RFC PATCH] cpufreq: Calling init() of cpufreq_driver when policy inactive cpu online

[Viresh Kumar]

On 21-03-18, 18:21, Shunyong Yang wrote:
> When multiple cpus are related in one cpufreq policy, the first online cpu
> will be chosen by default to handle cpufreq operations. In a CPPC case,
> let's take two related cpus, cpu0 and cpu1 as an example.
> 
> After system start, cpu0 is the first online cpu. Cpufreq policy will be
> allocated and init() in cpufreq_driver will be called to initialize cpu0's
> perf capabilities and policy parameters.

Not exactly. The init() is called to initialize stuff for all the CPUs that
should be part of policy->related_cpus after init() has returned. So you should
initialize perf capabilities for all of them.

> When cpu1 is online, current code
> will not call init() in cpufreq_driver as policy has been allocated and
> activated by cpu0. So, cpu1's perf capabilities are not initialized
> (all 0s).
> 
> When cpu0 is offline, policy->cpu will be shifted to cpu1. As cpu1's perf
> capabilities are 0s, speed change will not take effect when setting
> speed.
> 
> This patch adds calling init() of cpufreq_driver when policy inactive cpu
> comes to online.

No CPU should be inactive here, its just that you haven't initialized it
properly.

And we are not going to call init() multiple times for a group of CPUs. That's
not what the purpose of init() is.

-- 
viresh

Re: [RFC PATCH] cpufreq: Calling init() of cpufreq_driver when policy inactive cpu online

[Viresh Kumar]

On 21-03-18, 18:21, Shunyong Yang wrote:
> When multiple cpus are related in one cpufreq policy, the first online cpu
> will be chosen by default to handle cpufreq operations. In a CPPC case,
> let's take two related cpus, cpu0 and cpu1 as an example.
> 
> After system start, cpu0 is the first online cpu. Cpufreq policy will be
> allocated and init() in cpufreq_driver will be called to initialize cpu0's
> perf capabilities and policy parameters.

Not exactly. The init() is called to initialize stuff for all the CPUs that
should be part of policy->related_cpus after init() has returned. So you should
initialize perf capabilities for all of them.

> When cpu1 is online, current code
> will not call init() in cpufreq_driver as policy has been allocated and
> activated by cpu0. So, cpu1's perf capabilities are not initialized
> (all 0s).
> 
> When cpu0 is offline, policy->cpu will be shifted to cpu1. As cpu1's perf
> capabilities are 0s, speed change will not take effect when setting
> speed.
> 
> This patch adds calling init() of cpufreq_driver when policy inactive cpu
> comes to online.

No CPU should be inactive here, its just that you haven't initialized it
properly.

And we are not going to call init() multiple times for a group of CPUs. That's
not what the purpose of init() is.

-- 
viresh

Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

[Michael S. Tsirkin]

On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote:
> 
> 
> On 2018年03月20日 12:26, Jonathan Helman wrote:
> > > On Mar 19, 2018, at 7:31 PM, Jason Wang  wrote:
> > > 
> > > 
> > > 
> > > On 2018年03月20日 06:14, Jonathan Helman wrote:
> > > > Export the number of successful and failed hugetlb page
> > > > allocations via the virtio balloon driver. These 2 counts
> > > > come directly from the vm_events HTLB_BUDDY_PGALLOC and
> > > > HTLB_BUDDY_PGALLOC_FAIL.
> > > > 
> > > > Signed-off-by: Jonathan Helman 
> > > Reviewed-by: Jason Wang 
> > Thanks.
> > 
> > > > ---
> > > >   drivers/virtio/virtio_balloon.c | 6 ++
> > > >   include/uapi/linux/virtio_balloon.h | 4 +++-
> > > >   2 files changed, 9 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/virtio/virtio_balloon.c 
> > > > b/drivers/virtio/virtio_balloon.c
> > > > index dfe5684..6b237e3 100644
> > > > --- a/drivers/virtio/virtio_balloon.c
> > > > +++ b/drivers/virtio/virtio_balloon.c
> > > > @@ -272,6 +272,12 @@ static unsigned int update_balloon_stats(struct 
> > > > virtio_balloon *vb)
> > > > pages_to_bytes(events[PSWPOUT]));
> > > > update_stat(vb, idx++, VIRTIO_BALLOON_S_MAJFLT, 
> > > > events[PGMAJFAULT]);
> > > > update_stat(vb, idx++, VIRTIO_BALLOON_S_MINFLT, 
> > > > events[PGFAULT]);
> > > > +#ifdef CONFIG_HUGETLB_PAGE
> > > > +   update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGALLOC,
> > > > +   events[HTLB_BUDDY_PGALLOC]);
> > > > +   update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGFAIL,
> > > > +   events[HTLB_BUDDY_PGALLOC_FAIL]);
> > > > +#endif
> > > >   #endif
> > > > update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
> > > > pages_to_bytes(i.freeram));
> > > > diff --git a/include/uapi/linux/virtio_balloon.h 
> > > > b/include/uapi/linux/virtio_balloon.h
> > > > index 4e8b830..40297a3 100644
> > > > --- a/include/uapi/linux/virtio_balloon.h
> > > > +++ b/include/uapi/linux/virtio_balloon.h
> > > > @@ -53,7 +53,9 @@ struct virtio_balloon_config {
> > > >   #define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of memory */
> > > >   #define VIRTIO_BALLOON_S_AVAIL6   /* Available memory as in /proc 
> > > > */
> > > >   #define VIRTIO_BALLOON_S_CACHES   7   /* Disk caches */
> > > > -#define VIRTIO_BALLOON_S_NR   8
> > > > +#define VIRTIO_BALLOON_S_HTLB_PGALLOC  8  /* Hugetlb page allocations 
> > > > */
> > > > +#define VIRTIO_BALLOON_S_HTLB_PGFAIL   9  /* Hugetlb page allocation 
> > > > failures */
> > > > +#define VIRTIO_BALLOON_S_NR   10
> > > > /*
> > > >* Memory statistics structure.
> > > Not for this patch, but it looks to me that exporting such nr through 
> > > uapi is fragile.
> > Sorry, can you explain what you mean here?
> > 
> > Jon
> 
> Spec said "Within an output buffer submitted to the statsq, the device MUST
> ignore entries with tag values that it does not recognize". So exporting
> VIRTIO_BALLOON_S_NR seems useless and device implementation can not depend
> on such number in uapi.
> 
> Thanks

Suggestions? I don't like to break build for people ...

> > 
> > > Thanks
> > 
> > -
> > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
> > 

Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

[Michael S. Tsirkin]

On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote:
> 
> 
> On 2018年03月20日 12:26, Jonathan Helman wrote:
> > > On Mar 19, 2018, at 7:31 PM, Jason Wang  wrote:
> > > 
> > > 
> > > 
> > > On 2018年03月20日 06:14, Jonathan Helman wrote:
> > > > Export the number of successful and failed hugetlb page
> > > > allocations via the virtio balloon driver. These 2 counts
> > > > come directly from the vm_events HTLB_BUDDY_PGALLOC and
> > > > HTLB_BUDDY_PGALLOC_FAIL.
> > > > 
> > > > Signed-off-by: Jonathan Helman 
> > > Reviewed-by: Jason Wang 
> > Thanks.
> > 
> > > > ---
> > > >   drivers/virtio/virtio_balloon.c | 6 ++
> > > >   include/uapi/linux/virtio_balloon.h | 4 +++-
> > > >   2 files changed, 9 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/virtio/virtio_balloon.c 
> > > > b/drivers/virtio/virtio_balloon.c
> > > > index dfe5684..6b237e3 100644
> > > > --- a/drivers/virtio/virtio_balloon.c
> > > > +++ b/drivers/virtio/virtio_balloon.c
> > > > @@ -272,6 +272,12 @@ static unsigned int update_balloon_stats(struct 
> > > > virtio_balloon *vb)
> > > > pages_to_bytes(events[PSWPOUT]));
> > > > update_stat(vb, idx++, VIRTIO_BALLOON_S_MAJFLT, 
> > > > events[PGMAJFAULT]);
> > > > update_stat(vb, idx++, VIRTIO_BALLOON_S_MINFLT, 
> > > > events[PGFAULT]);
> > > > +#ifdef CONFIG_HUGETLB_PAGE
> > > > +   update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGALLOC,
> > > > +   events[HTLB_BUDDY_PGALLOC]);
> > > > +   update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGFAIL,
> > > > +   events[HTLB_BUDDY_PGALLOC_FAIL]);
> > > > +#endif
> > > >   #endif
> > > > update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
> > > > pages_to_bytes(i.freeram));
> > > > diff --git a/include/uapi/linux/virtio_balloon.h 
> > > > b/include/uapi/linux/virtio_balloon.h
> > > > index 4e8b830..40297a3 100644
> > > > --- a/include/uapi/linux/virtio_balloon.h
> > > > +++ b/include/uapi/linux/virtio_balloon.h
> > > > @@ -53,7 +53,9 @@ struct virtio_balloon_config {
> > > >   #define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of memory */
> > > >   #define VIRTIO_BALLOON_S_AVAIL6   /* Available memory as in /proc 
> > > > */
> > > >   #define VIRTIO_BALLOON_S_CACHES   7   /* Disk caches */
> > > > -#define VIRTIO_BALLOON_S_NR   8
> > > > +#define VIRTIO_BALLOON_S_HTLB_PGALLOC  8  /* Hugetlb page allocations 
> > > > */
> > > > +#define VIRTIO_BALLOON_S_HTLB_PGFAIL   9  /* Hugetlb page allocation 
> > > > failures */
> > > > +#define VIRTIO_BALLOON_S_NR   10
> > > > /*
> > > >* Memory statistics structure.
> > > Not for this patch, but it looks to me that exporting such nr through 
> > > uapi is fragile.
> > Sorry, can you explain what you mean here?
> > 
> > Jon
> 
> Spec said "Within an output buffer submitted to the statsq, the device MUST
> ignore entries with tag values that it does not recognize". So exporting
> VIRTIO_BALLOON_S_NR seems useless and device implementation can not depend
> on such number in uapi.
> 
> Thanks

Suggestions? I don't like to break build for people ...

> > 
> > > Thanks
> > 
> > -
> > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
> > 

[PATCH] arm64: avoid race condition issue in dump_backtrace

[Ji Zhang]

When we dump the backtrace of some specific task, there is a potential race
condition due to the task may be running on other cores if SMP enabled.
That is because for current implementation, if the task is not the current
task, we will get the registers used for unwind from cpu_context saved in
thread_info, which is the snapshot before context switch, but if the task
is running on other cores, the registers and the content of stack are
changed.
This may cause that we get the wrong backtrace or incomplete backtrace or
even crash the kernel.
To avoid this case, do not dump the backtrace of the tasks which are
running on other cores.
This patch cannot solve the issue completely but can shrink the window of
race condition.

Signed-off-by: Ji Zhang 
---
 arch/arm64/kernel/traps.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index eb2d151..95749364 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -113,6 +113,9 @@ void dump_backtrace(struct pt_regs *regs, struct 
task_struct *tsk)
if (tsk == current) {
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.pc = (unsigned long)dump_backtrace;
+   else if (tsk->state == TASK_RUNNING) {
+   pr_notice("Do not dump other running tasks\n");
+   return;
} else {
/*
 * task blocked in __switch_to
-- 
1.9.1

[PATCH] arm64: avoid race condition issue in dump_backtrace

[Ji Zhang]

When we dump the backtrace of some specific task, there is a potential race
condition due to the task may be running on other cores if SMP enabled.
That is because for current implementation, if the task is not the current
task, we will get the registers used for unwind from cpu_context saved in
thread_info, which is the snapshot before context switch, but if the task
is running on other cores, the registers and the content of stack are
changed.
This may cause that we get the wrong backtrace or incomplete backtrace or
even crash the kernel.
To avoid this case, do not dump the backtrace of the tasks which are
running on other cores.
This patch cannot solve the issue completely but can shrink the window of
race condition.

Signed-off-by: Ji Zhang 
---
 arch/arm64/kernel/traps.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index eb2d151..95749364 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -113,6 +113,9 @@ void dump_backtrace(struct pt_regs *regs, struct 
task_struct *tsk)
if (tsk == current) {
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.pc = (unsigned long)dump_backtrace;
+   else if (tsk->state == TASK_RUNNING) {
+   pr_notice("Do not dump other running tasks\n");
+   return;
} else {
/*
 * task blocked in __switch_to
-- 
1.9.1

[PATCH v4 4/5] pintcrl: support bias-disable of generic and special pins simultaneously

[Zhiyong Tao]

For generic pins, parameter "arg" is 0 or 1.
For special pins, bias-disable is set by R0R1,
so we need transmited "00" to set bias-disable
When we set "bias-disable" as high-z property,
the parameter should be "MTK_PUPD_SET_R1R0_00".

Signed-off-by: Zhiyong Tao 
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 3cf384f..f991ff3 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -293,7 +293,7 @@ static int mtk_pconf_set_pull_select(struct mtk_pinctrl 
*pctl,
unsigned int pin, bool enable, bool isup, unsigned int arg)
 {
unsigned int bit;
-   unsigned int reg_pullen, reg_pullsel;
+   unsigned int reg_pullen, reg_pullsel, r1r0;
int ret;
 
/* Some pins' pull setting are very different,
@@ -301,8 +301,12 @@ static int mtk_pconf_set_pull_select(struct mtk_pinctrl 
*pctl,
 * resistor bit, so we need this special handle.
 */
if (pctl->devdata->spec_pull_set) {
+   /* For special pins, bias-disable is set by R1R0,
+* the parameter should be "MTK_PUPD_SET_R1R0_00".
+*/
+   r1r0 = enable ? arg : MTK_PUPD_SET_R1R0_00;
ret = pctl->devdata->spec_pull_set(mtk_get_regmap(pctl, pin),
-   pin, pctl->devdata->port_align, isup, arg);
+   pin, pctl->devdata->port_align, isup, r1r0);
if (!ret)
return 0;
}
-- 
1.9.1

[PATCH v4 4/5] pintcrl: support bias-disable of generic and special pins simultaneously

[Zhiyong Tao]

For generic pins, parameter "arg" is 0 or 1.
For special pins, bias-disable is set by R0R1,
so we need transmited "00" to set bias-disable
When we set "bias-disable" as high-z property,
the parameter should be "MTK_PUPD_SET_R1R0_00".

Signed-off-by: Zhiyong Tao 
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 3cf384f..f991ff3 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -293,7 +293,7 @@ static int mtk_pconf_set_pull_select(struct mtk_pinctrl 
*pctl,
unsigned int pin, bool enable, bool isup, unsigned int arg)
 {
unsigned int bit;
-   unsigned int reg_pullen, reg_pullsel;
+   unsigned int reg_pullen, reg_pullsel, r1r0;
int ret;
 
/* Some pins' pull setting are very different,
@@ -301,8 +301,12 @@ static int mtk_pconf_set_pull_select(struct mtk_pinctrl 
*pctl,
 * resistor bit, so we need this special handle.
 */
if (pctl->devdata->spec_pull_set) {
+   /* For special pins, bias-disable is set by R1R0,
+* the parameter should be "MTK_PUPD_SET_R1R0_00".
+*/
+   r1r0 = enable ? arg : MTK_PUPD_SET_R1R0_00;
ret = pctl->devdata->spec_pull_set(mtk_get_regmap(pctl, pin),
-   pin, pctl->devdata->port_align, isup, arg);
+   pin, pctl->devdata->port_align, isup, r1r0);
if (!ret)
return 0;
}
-- 
1.9.1

[PATCH v4 3/5] pinctrl: add mt2712 pinctrl driver

[Zhiyong Tao]

The commit includes mt2712 pinctrl driver.

Signed-off-by: Zhiyong Tao 
---
 drivers/pinctrl/mediatek/Kconfig  |7 +
 drivers/pinctrl/mediatek/Makefile |1 +
 drivers/pinctrl/mediatek/pinctrl-mt2712.c |  634 +
 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1757 +
 4 files changed, 2399 insertions(+)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 3e59874..862c5db 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -32,6 +32,13 @@ config PINCTRL_MT8127
select PINCTRL_MTK
 
 # For ARMv8 SoCs
+config PINCTRL_MT2712
+   bool "MediaTek MT2712 pin control"
+   depends on OF
+   depends on ARM64 || COMPILE_TEST
+   default ARM64 && ARCH_MEDIATEK
+   select PINCTRL_MTK
+
 config PINCTRL_MT7622
bool "MediaTek MT7622 pin control"
depends on OF
diff --git a/drivers/pinctrl/mediatek/Makefile 
b/drivers/pinctrl/mediatek/Makefile
index ed7d2b2..7959e77 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_PINCTRL_MTK)   += pinctrl-mtk-common.o
 
 # SoC Drivers
 obj-$(CONFIG_PINCTRL_MT2701)   += pinctrl-mt2701.o
+obj-$(CONFIG_PINCTRL_MT2712)   += pinctrl-mt2712.o
 obj-$(CONFIG_PINCTRL_MT8135)   += pinctrl-mt8135.o
 obj-$(CONFIG_PINCTRL_MT8127)   += pinctrl-mt8127.o
 obj-$(CONFIG_PINCTRL_MT7622)   += pinctrl-mt7622.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2712.c 
b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
new file mode 100644
index 000..d14511f
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
@@ -0,0 +1,634 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Zhiyong Tao 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-mtk-common.h"
+#include "pinctrl-mtk-mt2712.h"
+
+static const struct mtk_pin_spec_pupd_set_samereg mt2712_spec_pupd[] = {
+   MTK_PIN_PUPD_SPEC_SR(18, 0xe50, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(19, 0xe60, 12, 11, 10),
+   MTK_PIN_PUPD_SPEC_SR(20, 0xe50, 5, 4, 3),
+   MTK_PIN_PUPD_SPEC_SR(21, 0xe60, 15, 14, 13),
+   MTK_PIN_PUPD_SPEC_SR(22, 0xe50, 8, 7, 6),
+   MTK_PIN_PUPD_SPEC_SR(23, 0xe70, 2, 1, 0),
+
+   MTK_PIN_PUPD_SPEC_SR(30, 0xf30, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(31, 0xf30, 6, 5, 4),
+   MTK_PIN_PUPD_SPEC_SR(32, 0xf30, 10, 9, 8),
+   MTK_PIN_PUPD_SPEC_SR(33, 0xf30, 14, 13, 12),
+   MTK_PIN_PUPD_SPEC_SR(34, 0xf40, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(35, 0xf40, 6, 5, 4),
+   MTK_PIN_PUPD_SPEC_SR(36, 0xf40, 10, 9, 8),
+   MTK_PIN_PUPD_SPEC_SR(37, 0xc40, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(38, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(39, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(40, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(41, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(42, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(43, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(44, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(45, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(46, 0xc50, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(47, 0xda0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(48, 0xd90, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(49, 0xdf0, 14, 13, 12),
+   MTK_PIN_PUPD_SPEC_SR(50, 0xdf0, 10, 9, 8),
+   MTK_PIN_PUPD_SPEC_SR(51, 0xdf0, 6, 5, 4),
+   MTK_PIN_PUPD_SPEC_SR(52, 0xdf0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(53, 0xd50, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(54, 0xd80, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(55, 0xe00, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(56, 0xd40, 2, 1, 0),
+
+   MTK_PIN_PUPD_SPEC_SR(63, 0xc80, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(64, 0xdb0, 14, 13, 12),
+   MTK_PIN_PUPD_SPEC_SR(65, 0xdb0, 6, 5, 4),
+   MTK_PIN_PUPD_SPEC_SR(66, 0xdb0, 10, 9, 8),
+   MTK_PIN_PUPD_SPEC_SR(67, 0xcd0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(68, 0xdb0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(69, 0xc90, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(70, 0xcc0, 2, 1, 0),
+
+   MTK_PIN_PUPD_SPEC_SR(89, 0xce0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(90, 0xdd0, 14, 13, 12),
+   MTK_PIN_PUPD_SPEC_SR(91, 0xdd0, 10, 9, 8),
+   MTK_PIN_PUPD_SPEC_SR(92, 0xdd0, 6, 5, 4),
+   MTK_PIN_PUPD_SPEC_SR(93, 0xdd0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(94, 0xd20, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(95, 0xcf0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(96, 0xd30, 2, 1, 0),
+
+   MTK_PIN_PUPD_SPEC_SR(135, 0xe50, 11, 10, 9),
+   MTK_PIN_PUPD_SPEC_SR(136, 0xe50, 14, 13, 12),
+   MTK_PIN_PUPD_SPEC_SR(137, 0xe70, 5, 4, 3),
+   MTK_PIN_PUPD_SPEC_SR(138, 0xe70, 8, 7, 6),
+   MTK_PIN_PUPD_SPEC_SR(139, 0xe70, 11, 10, 9),
+   

[PATCH v4 3/5] pinctrl: add mt2712 pinctrl driver

[Zhiyong Tao]

The commit includes mt2712 pinctrl driver.

Signed-off-by: Zhiyong Tao 
---
 drivers/pinctrl/mediatek/Kconfig  |7 +
 drivers/pinctrl/mediatek/Makefile |1 +
 drivers/pinctrl/mediatek/pinctrl-mt2712.c |  634 +
 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1757 +
 4 files changed, 2399 insertions(+)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 3e59874..862c5db 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -32,6 +32,13 @@ config PINCTRL_MT8127
select PINCTRL_MTK
 
 # For ARMv8 SoCs
+config PINCTRL_MT2712
+   bool "MediaTek MT2712 pin control"
+   depends on OF
+   depends on ARM64 || COMPILE_TEST
+   default ARM64 && ARCH_MEDIATEK
+   select PINCTRL_MTK
+
 config PINCTRL_MT7622
bool "MediaTek MT7622 pin control"
depends on OF
diff --git a/drivers/pinctrl/mediatek/Makefile 
b/drivers/pinctrl/mediatek/Makefile
index ed7d2b2..7959e77 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_PINCTRL_MTK)   += pinctrl-mtk-common.o
 
 # SoC Drivers
 obj-$(CONFIG_PINCTRL_MT2701)   += pinctrl-mt2701.o
+obj-$(CONFIG_PINCTRL_MT2712)   += pinctrl-mt2712.o
 obj-$(CONFIG_PINCTRL_MT8135)   += pinctrl-mt8135.o
 obj-$(CONFIG_PINCTRL_MT8127)   += pinctrl-mt8127.o
 obj-$(CONFIG_PINCTRL_MT7622)   += pinctrl-mt7622.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2712.c 
b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
new file mode 100644
index 000..d14511f
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
@@ -0,0 +1,634 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Zhiyong Tao 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-mtk-common.h"
+#include "pinctrl-mtk-mt2712.h"
+
+static const struct mtk_pin_spec_pupd_set_samereg mt2712_spec_pupd[] = {
+   MTK_PIN_PUPD_SPEC_SR(18, 0xe50, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(19, 0xe60, 12, 11, 10),
+   MTK_PIN_PUPD_SPEC_SR(20, 0xe50, 5, 4, 3),
+   MTK_PIN_PUPD_SPEC_SR(21, 0xe60, 15, 14, 13),
+   MTK_PIN_PUPD_SPEC_SR(22, 0xe50, 8, 7, 6),
+   MTK_PIN_PUPD_SPEC_SR(23, 0xe70, 2, 1, 0),
+
+   MTK_PIN_PUPD_SPEC_SR(30, 0xf30, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(31, 0xf30, 6, 5, 4),
+   MTK_PIN_PUPD_SPEC_SR(32, 0xf30, 10, 9, 8),
+   MTK_PIN_PUPD_SPEC_SR(33, 0xf30, 14, 13, 12),
+   MTK_PIN_PUPD_SPEC_SR(34, 0xf40, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(35, 0xf40, 6, 5, 4),
+   MTK_PIN_PUPD_SPEC_SR(36, 0xf40, 10, 9, 8),
+   MTK_PIN_PUPD_SPEC_SR(37, 0xc40, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(38, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(39, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(40, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(41, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(42, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(43, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(44, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(45, 0xc60, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(46, 0xc50, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(47, 0xda0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(48, 0xd90, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(49, 0xdf0, 14, 13, 12),
+   MTK_PIN_PUPD_SPEC_SR(50, 0xdf0, 10, 9, 8),
+   MTK_PIN_PUPD_SPEC_SR(51, 0xdf0, 6, 5, 4),
+   MTK_PIN_PUPD_SPEC_SR(52, 0xdf0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(53, 0xd50, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(54, 0xd80, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(55, 0xe00, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(56, 0xd40, 2, 1, 0),
+
+   MTK_PIN_PUPD_SPEC_SR(63, 0xc80, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(64, 0xdb0, 14, 13, 12),
+   MTK_PIN_PUPD_SPEC_SR(65, 0xdb0, 6, 5, 4),
+   MTK_PIN_PUPD_SPEC_SR(66, 0xdb0, 10, 9, 8),
+   MTK_PIN_PUPD_SPEC_SR(67, 0xcd0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(68, 0xdb0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(69, 0xc90, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(70, 0xcc0, 2, 1, 0),
+
+   MTK_PIN_PUPD_SPEC_SR(89, 0xce0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(90, 0xdd0, 14, 13, 12),
+   MTK_PIN_PUPD_SPEC_SR(91, 0xdd0, 10, 9, 8),
+   MTK_PIN_PUPD_SPEC_SR(92, 0xdd0, 6, 5, 4),
+   MTK_PIN_PUPD_SPEC_SR(93, 0xdd0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(94, 0xd20, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(95, 0xcf0, 2, 1, 0),
+   MTK_PIN_PUPD_SPEC_SR(96, 0xd30, 2, 1, 0),
+
+   MTK_PIN_PUPD_SPEC_SR(135, 0xe50, 11, 10, 9),
+   MTK_PIN_PUPD_SPEC_SR(136, 0xe50, 14, 13, 12),
+   MTK_PIN_PUPD_SPEC_SR(137, 0xe70, 5, 4, 3),
+   MTK_PIN_PUPD_SPEC_SR(138, 0xe70, 8, 7, 6),
+   MTK_PIN_PUPD_SPEC_SR(139, 0xe70, 11, 10, 9),
+   MTK_PIN_PUPD_SPEC_SR(140, 0xe70, 14, 13, 12),
+   

[PATCH v4 0/5] PINCTRL: Mediatek pinctrl driver for mt2712

[Zhiyong Tao]

This series includes five patches:
1.Add mt2712 pintcrl head file.
2.Add mt2712 pinctrl device node.
3.Add mt2712 pinctrl driver.
4.Support bias-disable of generic and special pins simultaneously.
5.fix check warnings.

Changes in patch v4:
1)fix check warnings for mt2712.
2)add fix check warnings patch for other ICs.

Changes in patch v3:
1)Use SPDX identifiers for all new files.
2)Use right data for Copyright and Author.
3)Correct some spelling mistake.
4)Reusing original logic and change solution to support bias-disable of generic 
and special pins simultaneously.
5)Add some comments for the speical path of special pins bias-disable.

Changes in patch v2:
1)Separate patch4 for supporting bias-disable of generic and special pins.
2)GPIO16~17 direction setting is changed as generic pins in mt2712 E2,
  So remove GPIO16~17 special direction setting and remove apmixedsys node in 
pinctrl device node.
3)Add pinmux define in "mt2712-pinfunc.h" and "pinctrl-mtk-mt2712.h" for mt2712 
E2 design.


Zhiyong Tao (5):
  arm64: dts: mt2712: add pintcrl file
  arm64: dts: mt2712: add pintcrl device node.
  pinctrl: add mt2712 pinctrl driver
  pintcrl: support bias-disable of generic and special pins
simultaneously
  pinctrl: fix check warnings.

 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1123 
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi |   18 +
 drivers/pinctrl/mediatek/Kconfig  |7 +
 drivers/pinctrl/mediatek/Makefile |1 +
 drivers/pinctrl/mediatek/pinctrl-mt2712.c |  634 +
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |8 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h |  840 
 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1757 +
 drivers/pinctrl/mediatek/pinctrl-mtk-mt6397.h |  123 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-mt8127.h |  429 ++
 drivers/pinctrl/mediatek/pinctrl-mtk-mt8135.h |  609 +++--
 drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h |  405 ++
 12 files changed, 4348 insertions(+), 1606 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h

--
2.6.4

[PATCH v4 0/5] PINCTRL: Mediatek pinctrl driver for mt2712

[Zhiyong Tao]

This series includes five patches:
1.Add mt2712 pintcrl head file.
2.Add mt2712 pinctrl device node.
3.Add mt2712 pinctrl driver.
4.Support bias-disable of generic and special pins simultaneously.
5.fix check warnings.

Changes in patch v4:
1)fix check warnings for mt2712.
2)add fix check warnings patch for other ICs.

Changes in patch v3:
1)Use SPDX identifiers for all new files.
2)Use right data for Copyright and Author.
3)Correct some spelling mistake.
4)Reusing original logic and change solution to support bias-disable of generic 
and special pins simultaneously.
5)Add some comments for the speical path of special pins bias-disable.

Changes in patch v2:
1)Separate patch4 for supporting bias-disable of generic and special pins.
2)GPIO16~17 direction setting is changed as generic pins in mt2712 E2,
  So remove GPIO16~17 special direction setting and remove apmixedsys node in 
pinctrl device node.
3)Add pinmux define in "mt2712-pinfunc.h" and "pinctrl-mtk-mt2712.h" for mt2712 
E2 design.


Zhiyong Tao (5):
  arm64: dts: mt2712: add pintcrl file
  arm64: dts: mt2712: add pintcrl device node.
  pinctrl: add mt2712 pinctrl driver
  pintcrl: support bias-disable of generic and special pins
simultaneously
  pinctrl: fix check warnings.

 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1123 
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi |   18 +
 drivers/pinctrl/mediatek/Kconfig  |7 +
 drivers/pinctrl/mediatek/Makefile |1 +
 drivers/pinctrl/mediatek/pinctrl-mt2712.c |  634 +
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |8 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h |  840 
 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1757 +
 drivers/pinctrl/mediatek/pinctrl-mtk-mt6397.h |  123 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-mt8127.h |  429 ++
 drivers/pinctrl/mediatek/pinctrl-mtk-mt8135.h |  609 +++--
 drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h |  405 ++
 12 files changed, 4348 insertions(+), 1606 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h

--
2.6.4

[PATCH v4 2/5] arm64: dts: mt2712: add pintcrl device node.

[Zhiyong Tao]

This patch adds pintcrl device node for mt2712.

Signed-off-by: Zhiyong Tao 
---
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index d7688bc..fb3b051 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include "mt2712-pinfunc.h"
 
 / {
compatible = "mediatek,mt2712";
@@ -258,6 +259,23 @@
#clock-cells = <1>;
};
 
+   syscfg_pctl_a: syscfg_pctl_a@10005000 {
+   compatible = "mediatek,mt2712-pctl-a-syscfg", "syscon";
+   reg = <0 0x10005000 0 0x1000>;
+   };
+
+   pio: pinctrl@10005000 {
+   compatible = "mediatek,mt2712-pinctrl";
+   reg = <0 0x1000b000 0 0x1000>;
+   mediatek,pctl-regmap = <_pctl_a>;
+   pins-are-numbered;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   interrupts = ;
+   };
+
scpsys: scpsys@10006000 {
compatible = "mediatek,mt2712-scpsys", "syscon";
#power-domain-cells = <1>;
-- 
1.9.1

[PATCH v4 2/5] arm64: dts: mt2712: add pintcrl device node.

[Zhiyong Tao]

This patch adds pintcrl device node for mt2712.

Signed-off-by: Zhiyong Tao 
---
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index d7688bc..fb3b051 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include "mt2712-pinfunc.h"
 
 / {
compatible = "mediatek,mt2712";
@@ -258,6 +259,23 @@
#clock-cells = <1>;
};
 
+   syscfg_pctl_a: syscfg_pctl_a@10005000 {
+   compatible = "mediatek,mt2712-pctl-a-syscfg", "syscon";
+   reg = <0 0x10005000 0 0x1000>;
+   };
+
+   pio: pinctrl@10005000 {
+   compatible = "mediatek,mt2712-pinctrl";
+   reg = <0 0x1000b000 0 0x1000>;
+   mediatek,pctl-regmap = <_pctl_a>;
+   pins-are-numbered;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   interrupts = ;
+   };
+
scpsys: scpsys@10006000 {
compatible = "mediatek,mt2712-scpsys", "syscon";
#power-domain-cells = <1>;
-- 
1.9.1

[PATCH v4 1/5] arm64: dts: mt2712: add pintcrl file

[Zhiyong Tao]

This patch adds pinctrl file for mt2712.

Signed-off-by: Zhiyong Tao 
Reviewed-by: Rob Herring 
---
 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1123 +
 1 file changed, 1123 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h

diff --git a/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h 
b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
new file mode 100644
index 000..1b4cb0c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
@@ -0,0 +1,1123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Zhiyong Tao 
+ *
+ */
+#ifndef __DTS_MT2712_PINFUNC_H
+#define __DTS_MT2712_PINFUNC_H
+
+#include 
+
+#define MT2712_PIN_0_EINT0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+#define MT2712_PIN_0_EINT0__FUNC_EINT0 (MTK_PIN_NO(0) | 1)
+#define MT2712_PIN_0_EINT0__FUNC_MBIST_DIAG_SCANOUT (MTK_PIN_NO(0) | 2)
+#define MT2712_PIN_0_EINT0__FUNC_DSIA_TE (MTK_PIN_NO(0) | 3)
+#define MT2712_PIN_0_EINT0__FUNC_DSIC_TE (MTK_PIN_NO(0) | 4)
+#define MT2712_PIN_0_EINT0__FUNC_DIN_D3 (MTK_PIN_NO(0) | 5)
+#define MT2712_PIN_0_EINT0__FUNC_PURE_HW_PROTECT (MTK_PIN_NO(0) | 6)
+
+#define MT2712_PIN_1_EINT1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
+#define MT2712_PIN_1_EINT1__FUNC_EINT1 (MTK_PIN_NO(1) | 1)
+#define MT2712_PIN_1_EINT1__FUNC_IR_IN (MTK_PIN_NO(1) | 2)
+#define MT2712_PIN_1_EINT1__FUNC_DSIB_TE (MTK_PIN_NO(1) | 3)
+#define MT2712_PIN_1_EINT1__FUNC_DSID_TE (MTK_PIN_NO(1) | 4)
+#define MT2712_PIN_1_EINT1__FUNC_DIN_D4 (MTK_PIN_NO(1) | 5)
+
+#define MT2712_PIN_2_EINT2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
+#define MT2712_PIN_2_EINT2__FUNC_EINT2 (MTK_PIN_NO(2) | 1)
+#define MT2712_PIN_2_EINT2__FUNC_IR_IN (MTK_PIN_NO(2) | 2)
+#define MT2712_PIN_2_EINT2__FUNC_LCM_RST1 (MTK_PIN_NO(2) | 3)
+#define MT2712_PIN_2_EINT2__FUNC_DIN_D5 (MTK_PIN_NO(2) | 5)
+
+#define MT2712_PIN_3_EINT3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
+#define MT2712_PIN_3_EINT3__FUNC_EINT3 (MTK_PIN_NO(3) | 1)
+#define MT2712_PIN_3_EINT3__FUNC_IR_IN (MTK_PIN_NO(3) | 2)
+#define MT2712_PIN_3_EINT3__FUNC_LCM_RST0 (MTK_PIN_NO(3) | 3)
+#define MT2712_PIN_3_EINT3__FUNC_DIN_D6 (MTK_PIN_NO(3) | 5)
+
+#define MT2712_PIN_4_PWM0__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
+#define MT2712_PIN_4_PWM0__FUNC_PWM0 (MTK_PIN_NO(4) | 1)
+#define MT2712_PIN_4_PWM0__FUNC_DISP0_PWM (MTK_PIN_NO(4) | 2)
+#define MT2712_PIN_4_PWM0__FUNC_DISP1_PWM (MTK_PIN_NO(4) | 3)
+#define MT2712_PIN_4_PWM0__FUNC_DIN_CLK (MTK_PIN_NO(4) | 5)
+
+#define MT2712_PIN_5_PWM1__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
+#define MT2712_PIN_5_PWM1__FUNC_PWM1 (MTK_PIN_NO(5) | 1)
+#define MT2712_PIN_5_PWM1__FUNC_DISP1_PWM (MTK_PIN_NO(5) | 2)
+#define MT2712_PIN_5_PWM1__FUNC_DISP0_PWM (MTK_PIN_NO(5) | 3)
+#define MT2712_PIN_5_PWM1__FUNC_DIN_VSYNC (MTK_PIN_NO(5) | 5)
+
+#define MT2712_PIN_6_PWM2__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
+#define MT2712_PIN_6_PWM2__FUNC_PWM2 (MTK_PIN_NO(6) | 1)
+#define MT2712_PIN_6_PWM2__FUNC_DISP0_PWM (MTK_PIN_NO(6) | 2)
+#define MT2712_PIN_6_PWM2__FUNC_DISP1_PWM (MTK_PIN_NO(6) | 3)
+#define MT2712_PIN_6_PWM2__FUNC_DISP2_PWM (MTK_PIN_NO(6) | 4)
+#define MT2712_PIN_6_PWM2__FUNC_DIN_HSYNC (MTK_PIN_NO(6) | 5)
+
+#define MT2712_PIN_7_PWM3__FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
+#define MT2712_PIN_7_PWM3__FUNC_PWM3 (MTK_PIN_NO(7) | 1)
+#define MT2712_PIN_7_PWM3__FUNC_DISP1_PWM (MTK_PIN_NO(7) | 2)
+#define MT2712_PIN_7_PWM3__FUNC_DISP0_PWM (MTK_PIN_NO(7) | 3)
+#define MT2712_PIN_7_PWM3__FUNC_LCM_RST2 (MTK_PIN_NO(7) | 4)
+#define MT2712_PIN_7_PWM3__FUNC_DIN_D0 (MTK_PIN_NO(7) | 5)
+
+#define MT2712_PIN_8_PWM4__FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
+#define MT2712_PIN_8_PWM4__FUNC_PWM4 (MTK_PIN_NO(8) | 1)
+#define MT2712_PIN_8_PWM4__FUNC_DISP0_PWM (MTK_PIN_NO(8) | 2)
+#define MT2712_PIN_8_PWM4__FUNC_DISP1_PWM (MTK_PIN_NO(8) | 3)
+#define MT2712_PIN_8_PWM4__FUNC_DSIA_TE (MTK_PIN_NO(8) | 4)
+#define MT2712_PIN_8_PWM4__FUNC_DIN_D1 (MTK_PIN_NO(8) | 5)
+
+#define MT2712_PIN_9_PWM5__FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
+#define MT2712_PIN_9_PWM5__FUNC_PWM5 (MTK_PIN_NO(9) | 1)
+#define MT2712_PIN_9_PWM5__FUNC_DISP1_PWM (MTK_PIN_NO(9) | 2)
+#define MT2712_PIN_9_PWM5__FUNC_DISP0_PWM (MTK_PIN_NO(9) | 3)
+#define MT2712_PIN_9_PWM5__FUNC_DSIB_TE (MTK_PIN_NO(9) | 4)
+#define MT2712_PIN_9_PWM5__FUNC_DIN_D2 (MTK_PIN_NO(9) | 5)
+
+#define MT2712_PIN_10_PWM6__FUNC_GPIO10 (MTK_PIN_NO(10) | 0)
+#define MT2712_PIN_10_PWM6__FUNC_PWM6 (MTK_PIN_NO(10) | 1)
+#define MT2712_PIN_10_PWM6__FUNC_DISP0_PWM (MTK_PIN_NO(10) | 2)
+#define MT2712_PIN_10_PWM6__FUNC_DISP1_PWM (MTK_PIN_NO(10) | 3)
+#define MT2712_PIN_10_PWM6__FUNC_LCM_RST0 (MTK_PIN_NO(10) | 4)
+
+#define MT2712_PIN_11_PWM7__FUNC_GPIO11 (MTK_PIN_NO(11) | 0)
+#define MT2712_PIN_11_PWM7__FUNC_PWM7 (MTK_PIN_NO(11) | 1)
+#define MT2712_PIN_11_PWM7__FUNC_DISP1_PWM (MTK_PIN_NO(11) | 2)
+#define MT2712_PIN_11_PWM7__FUNC_DISP0_PWM (MTK_PIN_NO(11) | 3)
+#define MT2712_PIN_11_PWM7__FUNC_LCM_RST1 (MTK_PIN_NO(11) | 4)
+
+#define MT2712_PIN_12_IDDIG_P0__FUNC_GPIO12 (MTK_PIN_NO(12) | 0)

[PATCH v4 1/5] arm64: dts: mt2712: add pintcrl file

[Zhiyong Tao]

This patch adds pinctrl file for mt2712.

Signed-off-by: Zhiyong Tao 
Reviewed-by: Rob Herring 
---
 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1123 +
 1 file changed, 1123 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h

diff --git a/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h 
b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
new file mode 100644
index 000..1b4cb0c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
@@ -0,0 +1,1123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Zhiyong Tao 
+ *
+ */
+#ifndef __DTS_MT2712_PINFUNC_H
+#define __DTS_MT2712_PINFUNC_H
+
+#include 
+
+#define MT2712_PIN_0_EINT0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+#define MT2712_PIN_0_EINT0__FUNC_EINT0 (MTK_PIN_NO(0) | 1)
+#define MT2712_PIN_0_EINT0__FUNC_MBIST_DIAG_SCANOUT (MTK_PIN_NO(0) | 2)
+#define MT2712_PIN_0_EINT0__FUNC_DSIA_TE (MTK_PIN_NO(0) | 3)
+#define MT2712_PIN_0_EINT0__FUNC_DSIC_TE (MTK_PIN_NO(0) | 4)
+#define MT2712_PIN_0_EINT0__FUNC_DIN_D3 (MTK_PIN_NO(0) | 5)
+#define MT2712_PIN_0_EINT0__FUNC_PURE_HW_PROTECT (MTK_PIN_NO(0) | 6)
+
+#define MT2712_PIN_1_EINT1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
+#define MT2712_PIN_1_EINT1__FUNC_EINT1 (MTK_PIN_NO(1) | 1)
+#define MT2712_PIN_1_EINT1__FUNC_IR_IN (MTK_PIN_NO(1) | 2)
+#define MT2712_PIN_1_EINT1__FUNC_DSIB_TE (MTK_PIN_NO(1) | 3)
+#define MT2712_PIN_1_EINT1__FUNC_DSID_TE (MTK_PIN_NO(1) | 4)
+#define MT2712_PIN_1_EINT1__FUNC_DIN_D4 (MTK_PIN_NO(1) | 5)
+
+#define MT2712_PIN_2_EINT2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
+#define MT2712_PIN_2_EINT2__FUNC_EINT2 (MTK_PIN_NO(2) | 1)
+#define MT2712_PIN_2_EINT2__FUNC_IR_IN (MTK_PIN_NO(2) | 2)
+#define MT2712_PIN_2_EINT2__FUNC_LCM_RST1 (MTK_PIN_NO(2) | 3)
+#define MT2712_PIN_2_EINT2__FUNC_DIN_D5 (MTK_PIN_NO(2) | 5)
+
+#define MT2712_PIN_3_EINT3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
+#define MT2712_PIN_3_EINT3__FUNC_EINT3 (MTK_PIN_NO(3) | 1)
+#define MT2712_PIN_3_EINT3__FUNC_IR_IN (MTK_PIN_NO(3) | 2)
+#define MT2712_PIN_3_EINT3__FUNC_LCM_RST0 (MTK_PIN_NO(3) | 3)
+#define MT2712_PIN_3_EINT3__FUNC_DIN_D6 (MTK_PIN_NO(3) | 5)
+
+#define MT2712_PIN_4_PWM0__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
+#define MT2712_PIN_4_PWM0__FUNC_PWM0 (MTK_PIN_NO(4) | 1)
+#define MT2712_PIN_4_PWM0__FUNC_DISP0_PWM (MTK_PIN_NO(4) | 2)
+#define MT2712_PIN_4_PWM0__FUNC_DISP1_PWM (MTK_PIN_NO(4) | 3)
+#define MT2712_PIN_4_PWM0__FUNC_DIN_CLK (MTK_PIN_NO(4) | 5)
+
+#define MT2712_PIN_5_PWM1__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
+#define MT2712_PIN_5_PWM1__FUNC_PWM1 (MTK_PIN_NO(5) | 1)
+#define MT2712_PIN_5_PWM1__FUNC_DISP1_PWM (MTK_PIN_NO(5) | 2)
+#define MT2712_PIN_5_PWM1__FUNC_DISP0_PWM (MTK_PIN_NO(5) | 3)
+#define MT2712_PIN_5_PWM1__FUNC_DIN_VSYNC (MTK_PIN_NO(5) | 5)
+
+#define MT2712_PIN_6_PWM2__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
+#define MT2712_PIN_6_PWM2__FUNC_PWM2 (MTK_PIN_NO(6) | 1)
+#define MT2712_PIN_6_PWM2__FUNC_DISP0_PWM (MTK_PIN_NO(6) | 2)
+#define MT2712_PIN_6_PWM2__FUNC_DISP1_PWM (MTK_PIN_NO(6) | 3)
+#define MT2712_PIN_6_PWM2__FUNC_DISP2_PWM (MTK_PIN_NO(6) | 4)
+#define MT2712_PIN_6_PWM2__FUNC_DIN_HSYNC (MTK_PIN_NO(6) | 5)
+
+#define MT2712_PIN_7_PWM3__FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
+#define MT2712_PIN_7_PWM3__FUNC_PWM3 (MTK_PIN_NO(7) | 1)
+#define MT2712_PIN_7_PWM3__FUNC_DISP1_PWM (MTK_PIN_NO(7) | 2)
+#define MT2712_PIN_7_PWM3__FUNC_DISP0_PWM (MTK_PIN_NO(7) | 3)
+#define MT2712_PIN_7_PWM3__FUNC_LCM_RST2 (MTK_PIN_NO(7) | 4)
+#define MT2712_PIN_7_PWM3__FUNC_DIN_D0 (MTK_PIN_NO(7) | 5)
+
+#define MT2712_PIN_8_PWM4__FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
+#define MT2712_PIN_8_PWM4__FUNC_PWM4 (MTK_PIN_NO(8) | 1)
+#define MT2712_PIN_8_PWM4__FUNC_DISP0_PWM (MTK_PIN_NO(8) | 2)
+#define MT2712_PIN_8_PWM4__FUNC_DISP1_PWM (MTK_PIN_NO(8) | 3)
+#define MT2712_PIN_8_PWM4__FUNC_DSIA_TE (MTK_PIN_NO(8) | 4)
+#define MT2712_PIN_8_PWM4__FUNC_DIN_D1 (MTK_PIN_NO(8) | 5)
+
+#define MT2712_PIN_9_PWM5__FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
+#define MT2712_PIN_9_PWM5__FUNC_PWM5 (MTK_PIN_NO(9) | 1)
+#define MT2712_PIN_9_PWM5__FUNC_DISP1_PWM (MTK_PIN_NO(9) | 2)
+#define MT2712_PIN_9_PWM5__FUNC_DISP0_PWM (MTK_PIN_NO(9) | 3)
+#define MT2712_PIN_9_PWM5__FUNC_DSIB_TE (MTK_PIN_NO(9) | 4)
+#define MT2712_PIN_9_PWM5__FUNC_DIN_D2 (MTK_PIN_NO(9) | 5)
+
+#define MT2712_PIN_10_PWM6__FUNC_GPIO10 (MTK_PIN_NO(10) | 0)
+#define MT2712_PIN_10_PWM6__FUNC_PWM6 (MTK_PIN_NO(10) | 1)
+#define MT2712_PIN_10_PWM6__FUNC_DISP0_PWM (MTK_PIN_NO(10) | 2)
+#define MT2712_PIN_10_PWM6__FUNC_DISP1_PWM (MTK_PIN_NO(10) | 3)
+#define MT2712_PIN_10_PWM6__FUNC_LCM_RST0 (MTK_PIN_NO(10) | 4)
+
+#define MT2712_PIN_11_PWM7__FUNC_GPIO11 (MTK_PIN_NO(11) | 0)
+#define MT2712_PIN_11_PWM7__FUNC_PWM7 (MTK_PIN_NO(11) | 1)
+#define MT2712_PIN_11_PWM7__FUNC_DISP1_PWM (MTK_PIN_NO(11) | 2)
+#define MT2712_PIN_11_PWM7__FUNC_DISP0_PWM (MTK_PIN_NO(11) | 3)
+#define MT2712_PIN_11_PWM7__FUNC_LCM_RST1 (MTK_PIN_NO(11) | 4)
+
+#define MT2712_PIN_12_IDDIG_P0__FUNC_GPIO12 (MTK_PIN_NO(12) | 0)
+#define MT2712_PIN_12_IDDIG_P0__FUNC_IDDIG_A (MTK_PIN_NO(12) | 1)

Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel

[Adam Borowski]

On Wed, Mar 21, 2018 at 06:29:41PM -0700, Nick Terrell wrote:
> This patch set adds support for a ZSTD-compressed kernel and ramdisk
> images in the kernel boot process. It only integrates the support with
> x86, though the first patch is generic to all architectures.

I'm running this patch set since October on amd64 armhf arm64, no
explosions -- besides the obvious when it's not applied yet I forget to
reconfigure initramfs-tools.  Which is getting tedious, so let's merge this
already. :)

I've tested initrd on all of these archs; here's a debug patch to check if
you're actually using it.

As for compressing the kernel itself: the second patch works as submitted
(ie, x86 only).  Porting it to other architectures is straightforward, but
eg. on arm, most boards use u-boot which insists on decompressing the kernel
by itself instead of passing control.  EFI/grub should work, but I haven't
tested that yet.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel

[Adam Borowski]

On Wed, Mar 21, 2018 at 06:29:41PM -0700, Nick Terrell wrote:
> This patch set adds support for a ZSTD-compressed kernel and ramdisk
> images in the kernel boot process. It only integrates the support with
> x86, though the first patch is generic to all architectures.

I'm running this patch set since October on amd64 armhf arm64, no
explosions -- besides the obvious when it's not applied yet I forget to
reconfigure initramfs-tools.  Which is getting tedious, so let's merge this
already. :)

I've tested initrd on all of these archs; here's a debug patch to check if
you're actually using it.

As for compressing the kernel itself: the second patch works as submitted
(ie, x86 only).  Porting it to other architectures is straightforward, but
eg. on arm, most boards use u-boot which insists on decompressing the kernel
by itself instead of passing control.  EFI/grub should work, but I haven't
tested that yet.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length.

[Sergey Senozhatsky]

On (03/21/18 19:56), Nick Terrell wrote:
[..]
> This seems like a reasonable extension to the algorithm, and it looks like
> LZ4_DYN is about a 5% improvement to compression ratio on your benchmark.
> The biggest question I have is if it is worthwhile to maintain a separate
> incompatible variant of LZ4 in the kernel without any upstream for a 5%
> gain? If we do want to go forward with this, we should perform more
> benchmarks.
> 
> I commented in the patch, but because the `dynOffset` variable isn't a
> compile time static in LZ4_decompress_generic(), I suspect that the patch
> causes a regression in decompression speed for both LZ4 and LZ4_DYN. You'll
> need to re-run the benchmarks to first show that LZ4 before the patch
> performs the same as LZ4 after the patch. Then re-run the LZ4 vs LZ4_DYN
> benchmarks.
> 
> I would also like to see a benchmark in user-space (with the code), so we
> can see the performance of LZ4 before and after the patch, as well as LZ4
> vs LZ4_DYN without anything else going on. I expect the extra branches in
> the decoding loop to have an impact on speed, and I would like to see how
> big the impact is without noise. 

Yes, I've been thinking about this. There are more branches now
("to dyn or not to dyn") in compression/decompression hot path but
we see less instructions and branches in perf output at the end.
And my guess is that we have a lot of noise from zram and zsmalloc.
The data is XXX bytes shorter with dyn enabled, so we use YYY less
moves and ZZZ less branches while we copy the data to zsmalloc and
from zsmalloc, and I may be that's the root cause of "performance
gain" that we see in zram-fio tests. So may be we need to run
benchmarks against lz4, not zram+lz4.

> CC-ing Yann Collet, the author of LZ4

Great, thanks.

-ss

Re: [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length.

[Sergey Senozhatsky]

On (03/21/18 19:56), Nick Terrell wrote:
[..]
> This seems like a reasonable extension to the algorithm, and it looks like
> LZ4_DYN is about a 5% improvement to compression ratio on your benchmark.
> The biggest question I have is if it is worthwhile to maintain a separate
> incompatible variant of LZ4 in the kernel without any upstream for a 5%
> gain? If we do want to go forward with this, we should perform more
> benchmarks.
> 
> I commented in the patch, but because the `dynOffset` variable isn't a
> compile time static in LZ4_decompress_generic(), I suspect that the patch
> causes a regression in decompression speed for both LZ4 and LZ4_DYN. You'll
> need to re-run the benchmarks to first show that LZ4 before the patch
> performs the same as LZ4 after the patch. Then re-run the LZ4 vs LZ4_DYN
> benchmarks.
> 
> I would also like to see a benchmark in user-space (with the code), so we
> can see the performance of LZ4 before and after the patch, as well as LZ4
> vs LZ4_DYN without anything else going on. I expect the extra branches in
> the decoding loop to have an impact on speed, and I would like to see how
> big the impact is without noise. 

Yes, I've been thinking about this. There are more branches now
("to dyn or not to dyn") in compression/decompression hot path but
we see less instructions and branches in perf output at the end.
And my guess is that we have a lot of noise from zram and zsmalloc.
The data is XXX bytes shorter with dyn enabled, so we use YYY less
moves and ZZZ less branches while we copy the data to zsmalloc and
from zsmalloc, and I may be that's the root cause of "performance
gain" that we see in zram-fio tests. So may be we need to run
benchmarks against lz4, not zram+lz4.

> CC-ing Yann Collet, the author of LZ4

Great, thanks.

-ss

Re: [PATCH][next] phy: qcom-qusb2: fix missing assignment to an error return code

[Vivek Gautam]

On 3/21/2018 11:15 PM, Colin King wrote:

From: Colin Ian King 

The error return code is not being assigned to ret from the call
to clk_prepare_enable and consequently the current check on ret
picks up the previous error return. Fix this by adding in the
missing assignment to ret.

Detected by CoverityScan, CID#166020 ("Logically Dead code")

Fixes: 891a96f65ac3 ("phy: qcom-qusb2: Add support for runtime PM)
Signed-off-by: Colin Ian King 
---


Acked-by: Vivek Gautam 

regards
Vivek


  drivers/phy/qualcomm/phy-qcom-qusb2.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 94afeac1a19e..6f5689a40884 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -439,7 +439,7 @@ static int __maybe_unused qusb2_phy_runtime_resume(struct 
device *dev)
}
  
  	if (!qphy->has_se_clk_scheme) {

-   clk_prepare_enable(qphy->ref_clk);
+   ret = clk_prepare_enable(qphy->ref_clk);
if (ret) {
dev_err(dev, "failed to enable ref clk, %d\n", ret);
goto disable_ahb_clk;

Re: [PATCH][next] phy: qcom-qusb2: fix missing assignment to an error return code

[Vivek Gautam]

On 3/21/2018 11:15 PM, Colin King wrote:

From: Colin Ian King 

The error return code is not being assigned to ret from the call
to clk_prepare_enable and consequently the current check on ret
picks up the previous error return. Fix this by adding in the
missing assignment to ret.

Detected by CoverityScan, CID#166020 ("Logically Dead code")

Fixes: 891a96f65ac3 ("phy: qcom-qusb2: Add support for runtime PM)
Signed-off-by: Colin Ian King 
---


Acked-by: Vivek Gautam 

regards
Vivek


  drivers/phy/qualcomm/phy-qcom-qusb2.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 94afeac1a19e..6f5689a40884 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -439,7 +439,7 @@ static int __maybe_unused qusb2_phy_runtime_resume(struct 
device *dev)
}
  
  	if (!qphy->has_se_clk_scheme) {

-   clk_prepare_enable(qphy->ref_clk);
+   ret = clk_prepare_enable(qphy->ref_clk);
if (ret) {
dev_err(dev, "failed to enable ref clk, %d\n", ret);
goto disable_ahb_clk;

Re: [Bug 199003] console stalled, cause Hard LOCKUP.

[Sergey Senozhatsky]

On (03/22/18 11:14), Sergey Senozhatsky wrote:
[..]
> Looking at
>  
> printk()->call_console_drivers()->serial8250_console_putchar()->wait_for_xmitr()
> 
> ... wait_for_xmitr() can spin for over 1 second waiting for the UART_MSR_CTS
> bit.

[..]

> a 1+ second long busy loop in the console driver is quite close to
> "problems guaranteed". But, wait, there is even more. This wait_for_xmitr()
> busy wait is happening after every character we print on the console. So
> printk("foo") will generate 5 * wait_for_xmitr() busy loops [foo + \r + \n].
> They punch watchdog a lot, so at the least the system won't get killed
> by the hardlockup detector. But at the same time, it's still potentially a
> 1+ second busy loop in the console driver * strlen(message).

One does not even need to have concurrent printk()-s in this case. A
single CPU doing several direct printks under spin_lock is already
enough:

CPUACPUB ~ CPUZ
spin_lock()
 printk->wait_for_xmitr spin_lock()
 printk->wait_for_xmitr
 ...
 printk->wait_for_xmitr << lockups >>
 printk->wait_for_xmitr
spin_unlock()

> Sometimes I really wish we had detached consoles. Direct printk()->console
> is nice and cool, but... we can't have it.

And this is, basically, what they do with printk_deferred(). We usually
use it to avoid deadlocks, but in this particular case it's used due to
the fact that direct printk() is way too painful, so they are detaching
printout and move it to another control path. Quite an interesting idea,
I must say.

-ss

Re: [Bug 199003] console stalled, cause Hard LOCKUP.

[Sergey Senozhatsky]

On (03/22/18 11:14), Sergey Senozhatsky wrote:
[..]
> Looking at
>  
> printk()->call_console_drivers()->serial8250_console_putchar()->wait_for_xmitr()
> 
> ... wait_for_xmitr() can spin for over 1 second waiting for the UART_MSR_CTS
> bit.

[..]

> a 1+ second long busy loop in the console driver is quite close to
> "problems guaranteed". But, wait, there is even more. This wait_for_xmitr()
> busy wait is happening after every character we print on the console. So
> printk("foo") will generate 5 * wait_for_xmitr() busy loops [foo + \r + \n].
> They punch watchdog a lot, so at the least the system won't get killed
> by the hardlockup detector. But at the same time, it's still potentially a
> 1+ second busy loop in the console driver * strlen(message).

One does not even need to have concurrent printk()-s in this case. A
single CPU doing several direct printks under spin_lock is already
enough:

CPUACPUB ~ CPUZ
spin_lock()
 printk->wait_for_xmitr spin_lock()
 printk->wait_for_xmitr
 ...
 printk->wait_for_xmitr << lockups >>
 printk->wait_for_xmitr
spin_unlock()

> Sometimes I really wish we had detached consoles. Direct printk()->console
> is nice and cool, but... we can't have it.

And this is, basically, what they do with printk_deferred(). We usually
use it to avoid deadlocks, but in this particular case it's used due to
the fact that direct printk() is way too painful, so they are detaching
printout and move it to another control path. Quite an interesting idea,
I must say.

-ss

Re: questions about header.S

[Cao jin]

Thanks very much for you hint!

On 03/21/2018 05:57 PM, Thomas Gleixner wrote:
> On Wed, 21 Mar 2018, Cao jin wrote:
>> On 03/17/2018 06:01 PM, Cao jin wrote:
>>>   I find two small questions which confuse me a little.
>>>
>>> 1.
>>> # Check signature at end of setup
>>>cmpl$0x5a5aaa55, setup_sig
>>>jne setup_bad
>>>
>>> setup_sig is defined in setup.ld, which points to the constant also
>>> defined in setup.ld, so I don't figure out in which case they don't
>>> equal and jump to setup_bad?
> 
> That's a lame sanity check to make sure that nothing overwrote the loader.
> 

I see.

>>> In my test, drop these 2 lines seems fine, system can boot without any
>>> obvious error.
> 
> Sure it does as long as you have no corruption.
> 
>>> 2.
>>> # Zero the bss
>>> movw$__bss_start, %di
>>> movw$_end+3, %cx
>>> xorl%eax, %eax
>>> subw%di, %cx
>>> shrw$2, %cx
>>> rep; stosl
>>>
>>> It is not a big deal, but I think replace "_end" with "__bss_end" make
>>> more sense, and "_end" is already aligned to word length. And, there is
>>> no other code use symbol "__bss_end". So I don't know is there any
>>> reason to use "_end" here?
> 
> It doesn't matter at all. But its also pointless to change it.
> 

It does not matter and is pointless to change for kernel itself. It just
may confuse a little for newbies who has interests.

-- 
Sincerely,
Cao jin

Re: questions about header.S

[Cao jin]

Thanks very much for you hint!

On 03/21/2018 05:57 PM, Thomas Gleixner wrote:
> On Wed, 21 Mar 2018, Cao jin wrote:
>> On 03/17/2018 06:01 PM, Cao jin wrote:
>>>   I find two small questions which confuse me a little.
>>>
>>> 1.
>>> # Check signature at end of setup
>>>cmpl$0x5a5aaa55, setup_sig
>>>jne setup_bad
>>>
>>> setup_sig is defined in setup.ld, which points to the constant also
>>> defined in setup.ld, so I don't figure out in which case they don't
>>> equal and jump to setup_bad?
> 
> That's a lame sanity check to make sure that nothing overwrote the loader.
> 

I see.

>>> In my test, drop these 2 lines seems fine, system can boot without any
>>> obvious error.
> 
> Sure it does as long as you have no corruption.
> 
>>> 2.
>>> # Zero the bss
>>> movw$__bss_start, %di
>>> movw$_end+3, %cx
>>> xorl%eax, %eax
>>> subw%di, %cx
>>> shrw$2, %cx
>>> rep; stosl
>>>
>>> It is not a big deal, but I think replace "_end" with "__bss_end" make
>>> more sense, and "_end" is already aligned to word length. And, there is
>>> no other code use symbol "__bss_end". So I don't know is there any
>>> reason to use "_end" here?
> 
> It doesn't matter at all. But its also pointless to change it.
> 

It does not matter and is pointless to change for kernel itself. It just
may confuse a little for newbies who has interests.

-- 
Sincerely,
Cao jin

Re: [PATCH v2] f2fs: no need to initialize zero value for GFP_F2FS_ZERO

[Chao Yu]

On 2018/3/22 10:08, Yunlong Song wrote:
> Since f2fs_inode_info is allocated with flag GFP_F2FS_ZERO, so we do not
> need to initialize zero value for its member any more.
> 
> Signed-off-by: Yunlong Song 

Reviewed-by: Chao Yu 

Thanks,

Re: [PATCH v2] f2fs: no need to initialize zero value for GFP_F2FS_ZERO

[Chao Yu]

On 2018/3/22 10:08, Yunlong Song wrote:
> Since f2fs_inode_info is allocated with flag GFP_F2FS_ZERO, so we do not
> need to initialize zero value for its member any more.
> 
> Signed-off-by: Yunlong Song 

Reviewed-by: Chao Yu 

Thanks,

Re: [PATCH v3 6/7] arm: dts: sun8i: a33: Add the DSI-related nodes

[Chen-Yu Tsai]

On Tue, Mar 6, 2018 at 9:56 PM, Maxime Ripard  wrote:
> From: Maxime Ripard 
>
> The A33 has a MIPI-DSI block, along with its D-PHY. Let's add it in order
> to use it in the relevant boards.
>
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/boot/dts/sun8i-a33.dtsi | 44 +-
>  1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi 
> b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 50eb84fa246a..94cfa7b1bbfa 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -236,6 +236,11 @@
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <1>;
> +
> +   tcon0_out_dsi0: endpoint@1 {
> +   reg = <1>;
> +   remote-endpoint = 
> <_in_tcon0>;
> +   };
> };
> };
> };
> @@ -280,6 +285,45 @@
> #io-channel-cells = <0>;
> };
>
> +   dsi0: dsi@1ca {

Nit: There's only one so you don't need the numbered suffix. Also,
is "dsi" specific enough, or should we use "mipi-dsi"

> +   compatible = "allwinner,sun6i-a31-mipi-dsi";
> +   reg = <0x01ca 0x1000>;
> +   interrupts = ;
> +   clocks = < CLK_BUS_MIPI_DSI>,
> +< CLK_DSI_SCLK>;
> +   clock-names = "bus", "mod";
> +   resets = < RST_BUS_MIPI_DSI>;
> +   phys = <>;
> +   phy-names = "dphy";
> +   status = "disabled";
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   port@0 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <0>;
> +
> +   dsi0_in_tcon0: endpoint {
> +   remote-endpoint = 
> <_out_dsi0>;
> +   };
> +   };
> +   };
> +   };
> +
> +   dphy0: d-phy@1ca1000 {

Same nit, and "dsi-phy" would be better.

Otherwise,

Reviewed-by: Chen-Yu Tsai 

> +   compatible = "allwinner,sun6i-a31-mipi-dphy";
> +   reg = <0x01ca1000 0x1000>;
> +   clocks = < CLK_BUS_MIPI_DSI>,
> +< CLK_DSI_DPHY>;
> +   clock-names = "bus", "mod";
> +   resets = < RST_BUS_MIPI_DSI>;
> +   status = "disabled";
> +   #phy-cells = <0>;
> +   };
> +
> fe0: display-frontend@1e0 {
> compatible = "allwinner,sun8i-a33-display-frontend";
> reg = <0x01e0 0x2>;
> --
> git-series 0.9.1

Re: [PATCH v3 6/7] arm: dts: sun8i: a33: Add the DSI-related nodes

[Chen-Yu Tsai]

On Tue, Mar 6, 2018 at 9:56 PM, Maxime Ripard  wrote:
> From: Maxime Ripard 
>
> The A33 has a MIPI-DSI block, along with its D-PHY. Let's add it in order
> to use it in the relevant boards.
>
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/boot/dts/sun8i-a33.dtsi | 44 +-
>  1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi 
> b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 50eb84fa246a..94cfa7b1bbfa 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -236,6 +236,11 @@
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <1>;
> +
> +   tcon0_out_dsi0: endpoint@1 {
> +   reg = <1>;
> +   remote-endpoint = 
> <_in_tcon0>;
> +   };
> };
> };
> };
> @@ -280,6 +285,45 @@
> #io-channel-cells = <0>;
> };
>
> +   dsi0: dsi@1ca {

Nit: There's only one so you don't need the numbered suffix. Also,
is "dsi" specific enough, or should we use "mipi-dsi"

> +   compatible = "allwinner,sun6i-a31-mipi-dsi";
> +   reg = <0x01ca 0x1000>;
> +   interrupts = ;
> +   clocks = < CLK_BUS_MIPI_DSI>,
> +< CLK_DSI_SCLK>;
> +   clock-names = "bus", "mod";
> +   resets = < RST_BUS_MIPI_DSI>;
> +   phys = <>;
> +   phy-names = "dphy";
> +   status = "disabled";
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   port@0 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <0>;
> +
> +   dsi0_in_tcon0: endpoint {
> +   remote-endpoint = 
> <_out_dsi0>;
> +   };
> +   };
> +   };
> +   };
> +
> +   dphy0: d-phy@1ca1000 {

Same nit, and "dsi-phy" would be better.

Otherwise,

Reviewed-by: Chen-Yu Tsai 

> +   compatible = "allwinner,sun6i-a31-mipi-dphy";
> +   reg = <0x01ca1000 0x1000>;
> +   clocks = < CLK_BUS_MIPI_DSI>,
> +< CLK_DSI_DPHY>;
> +   clock-names = "bus", "mod";
> +   resets = < RST_BUS_MIPI_DSI>;
> +   status = "disabled";
> +   #phy-cells = <0>;
> +   };
> +
> fe0: display-frontend@1e0 {
> compatible = "allwinner,sun8i-a33-display-frontend";
> reg = <0x01e0 0x2>;
> --
> git-series 0.9.1

Re: [PATCH 1/2] ACPI / PM: Use register_reboot_notifier() instead of pm_power_off_prepare

[Baolin Wang]

Hi Pavel,

On 21 March 2018 at 22:04, Pavel Machek  wrote:
> On Wed 2018-03-21 19:30:16, Baolin Wang wrote:
>> We can register one notifier through register_reboot_notifier() function to
>> prepare to power off the system, then we can remove the 
>> 'pm_power_off_prepare'
>> hook in following patch.
>>
>> Signed-off-by: Baolin Wang 
>> ---
>> Note: Please help to review carefully, since I have no platform to test
>> this conversion.
>>
>> I saw there is another reboot notifier in this driver, I am not sure the
>> orders between them. I can change the priority of notifier to keep their
>> orders if it is necessary.
>
> I don't understand why this is good idea... and you should really test
> it. I'm sure you can find PC or notebook somewhere...

I want to test it, but I have no opensource board with x86
architecture. But I will try to find one or ask other guys to help to
test it. Thanks for your comments.

>>  drivers/acpi/sleep.c |   22 --
>>  1 file changed, 16 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
>> index 46cde091..b3de894 100644
>> --- a/drivers/acpi/sleep.c
>> +++ b/drivers/acpi/sleep.c
>> @@ -1229,14 +1229,24 @@ static void acpi_sleep_hibernate_setup(void)
>>  static inline void acpi_sleep_hibernate_setup(void) {}
>>  #endif /* !CONFIG_HIBERNATION */
>>
>> -static void acpi_power_off_prepare(void)
>> +static int acpi_reboot_notify(struct notifier_block *this, unsigned long 
>> code,
>> +   void *x)
>>  {
>> - /* Prepare to power off the system */
>> - acpi_sleep_prepare(ACPI_STATE_S5);
>> - acpi_disable_all_gpes();
>> - acpi_os_wait_events_complete();
>> + if (code == SYSTEM_POWER_OFF) {
>> + /* Prepare to power off the system */
>> + acpi_sleep_prepare(ACPI_STATE_S5);
>> + acpi_disable_all_gpes();
>> + acpi_os_wait_events_complete();
>> + }
>> +
>> + return NOTIFY_DONE;
>>  }
>>
>> +static struct notifier_block acpi_reboot_notifier = {
>> + .notifier_call  = acpi_reboot_notify,
>> + .priority   = 0,
>> +};
>> +
>>  static void acpi_power_off(void)
>>  {
>>   /* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
>> @@ -1261,7 +1271,7 @@ int __init acpi_sleep_init(void)
>>
>>   if (acpi_sleep_state_supported(ACPI_STATE_S5)) {
>>   sleep_states[ACPI_STATE_S5] = 1;
>> - pm_power_off_prepare = acpi_power_off_prepare;
>> + register_reboot_notifier(_reboot_notifier);
>>   pm_power_off = acpi_power_off;
>>   } else {
>>   acpi_no_s5 = true;
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



-- 
Baolin.wang
Best Regards

Re: [PATCH 1/2] ACPI / PM: Use register_reboot_notifier() instead of pm_power_off_prepare

[Baolin Wang]

Hi Pavel,

On 21 March 2018 at 22:04, Pavel Machek  wrote:
> On Wed 2018-03-21 19:30:16, Baolin Wang wrote:
>> We can register one notifier through register_reboot_notifier() function to
>> prepare to power off the system, then we can remove the 
>> 'pm_power_off_prepare'
>> hook in following patch.
>>
>> Signed-off-by: Baolin Wang 
>> ---
>> Note: Please help to review carefully, since I have no platform to test
>> this conversion.
>>
>> I saw there is another reboot notifier in this driver, I am not sure the
>> orders between them. I can change the priority of notifier to keep their
>> orders if it is necessary.
>
> I don't understand why this is good idea... and you should really test
> it. I'm sure you can find PC or notebook somewhere...

I want to test it, but I have no opensource board with x86
architecture. But I will try to find one or ask other guys to help to
test it. Thanks for your comments.

>>  drivers/acpi/sleep.c |   22 --
>>  1 file changed, 16 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
>> index 46cde091..b3de894 100644
>> --- a/drivers/acpi/sleep.c
>> +++ b/drivers/acpi/sleep.c
>> @@ -1229,14 +1229,24 @@ static void acpi_sleep_hibernate_setup(void)
>>  static inline void acpi_sleep_hibernate_setup(void) {}
>>  #endif /* !CONFIG_HIBERNATION */
>>
>> -static void acpi_power_off_prepare(void)
>> +static int acpi_reboot_notify(struct notifier_block *this, unsigned long 
>> code,
>> +   void *x)
>>  {
>> - /* Prepare to power off the system */
>> - acpi_sleep_prepare(ACPI_STATE_S5);
>> - acpi_disable_all_gpes();
>> - acpi_os_wait_events_complete();
>> + if (code == SYSTEM_POWER_OFF) {
>> + /* Prepare to power off the system */
>> + acpi_sleep_prepare(ACPI_STATE_S5);
>> + acpi_disable_all_gpes();
>> + acpi_os_wait_events_complete();
>> + }
>> +
>> + return NOTIFY_DONE;
>>  }
>>
>> +static struct notifier_block acpi_reboot_notifier = {
>> + .notifier_call  = acpi_reboot_notify,
>> + .priority   = 0,
>> +};
>> +
>>  static void acpi_power_off(void)
>>  {
>>   /* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
>> @@ -1261,7 +1271,7 @@ int __init acpi_sleep_init(void)
>>
>>   if (acpi_sleep_state_supported(ACPI_STATE_S5)) {
>>   sleep_states[ACPI_STATE_S5] = 1;
>> - pm_power_off_prepare = acpi_power_off_prepare;
>> + register_reboot_notifier(_reboot_notifier);
>>   pm_power_off = acpi_power_off;
>>   } else {
>>   acpi_no_s5 = true;
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



-- 
Baolin.wang
Best Regards

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/gvt/scheduler.c

between commit:

  fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")

from Linus' tree and commit:

  b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is pinned.")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
index 068126404151,a55b4975c154..
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@@ -52,54 -52,29 +52,77 @@@ static void set_context_pdp_root_pointe
pdp_pair[i].val = pdp[7 - i];
  }
  
 +/*
 + * when populating shadow ctx from guest, we should not overrride oa related
 + * registers, so that they will not be overlapped by guest oa configs. Thus
 + * made it possible to capture oa data from host for both host and guests.
 + */
 +static void sr_oa_regs(struct intel_vgpu_workload *workload,
 +  u32 *reg_state, bool save)
 +{
 +  struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
 +  u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
 +  u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
 +  int i = 0;
 +  u32 flex_mmio[] = {
 +  i915_mmio_reg_offset(EU_PERF_CNTL0),
 +  i915_mmio_reg_offset(EU_PERF_CNTL1),
 +  i915_mmio_reg_offset(EU_PERF_CNTL2),
 +  i915_mmio_reg_offset(EU_PERF_CNTL3),
 +  i915_mmio_reg_offset(EU_PERF_CNTL4),
 +  i915_mmio_reg_offset(EU_PERF_CNTL5),
 +  i915_mmio_reg_offset(EU_PERF_CNTL6),
 +  };
 +
 +  if (!workload || !reg_state || workload->ring_id != RCS)
 +  return;
 +
 +  if (save) {
 +  workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
 +
 +  for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
 +  u32 state_offset = ctx_flexeu0 + i * 2;
 +
 +  workload->flex_mmio[i] = reg_state[state_offset + 1];
 +  }
 +  } else {
 +  reg_state[ctx_oactxctrl] =
 +  i915_mmio_reg_offset(GEN8_OACTXCONTROL);
 +  reg_state[ctx_oactxctrl + 1] = workload->oactxctrl;
 +
 +  for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
 +  u32 state_offset = ctx_flexeu0 + i * 2;
 +  u32 mmio = flex_mmio[i];
 +
 +  reg_state[state_offset] = mmio;
 +  reg_state[state_offset + 1] = workload->flex_mmio[i];
 +  }
 +  }
 +}
 +
+ static void update_shadow_pdps(struct intel_vgpu_workload *workload)
+ {
+   struct intel_vgpu *vgpu = workload->vgpu;
+   int ring_id = workload->ring_id;
+   struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
+   struct drm_i915_gem_object *ctx_obj =
+   shadow_ctx->engine[ring_id].state->obj;
+   struct execlist_ring_context *shadow_ring_context;
+   struct page *page;
+ 
+   if (WARN_ON(!workload->shadow_mm))
+   return;
+ 
+   if (WARN_ON(!atomic_read(>shadow_mm->pincount)))
+   return;
+ 
+   page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
+   shadow_ring_context = kmap(page);
+   set_context_pdp_root_pointer(shadow_ring_context,
+   (void *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
+   kunmap(page);
+ }
+ 
  static int populate_shadow_context(struct intel_vgpu_workload *workload)
  {
struct intel_vgpu *vgpu = workload->vgpu;


pgpGlinVdYWAE.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/gvt/scheduler.c

between commit:

  fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")

from Linus' tree and commit:

  b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is pinned.")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
index 068126404151,a55b4975c154..
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@@ -52,54 -52,29 +52,77 @@@ static void set_context_pdp_root_pointe
pdp_pair[i].val = pdp[7 - i];
  }
  
 +/*
 + * when populating shadow ctx from guest, we should not overrride oa related
 + * registers, so that they will not be overlapped by guest oa configs. Thus
 + * made it possible to capture oa data from host for both host and guests.
 + */
 +static void sr_oa_regs(struct intel_vgpu_workload *workload,
 +  u32 *reg_state, bool save)
 +{
 +  struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
 +  u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
 +  u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
 +  int i = 0;
 +  u32 flex_mmio[] = {
 +  i915_mmio_reg_offset(EU_PERF_CNTL0),
 +  i915_mmio_reg_offset(EU_PERF_CNTL1),
 +  i915_mmio_reg_offset(EU_PERF_CNTL2),
 +  i915_mmio_reg_offset(EU_PERF_CNTL3),
 +  i915_mmio_reg_offset(EU_PERF_CNTL4),
 +  i915_mmio_reg_offset(EU_PERF_CNTL5),
 +  i915_mmio_reg_offset(EU_PERF_CNTL6),
 +  };
 +
 +  if (!workload || !reg_state || workload->ring_id != RCS)
 +  return;
 +
 +  if (save) {
 +  workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
 +
 +  for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
 +  u32 state_offset = ctx_flexeu0 + i * 2;
 +
 +  workload->flex_mmio[i] = reg_state[state_offset + 1];
 +  }
 +  } else {
 +  reg_state[ctx_oactxctrl] =
 +  i915_mmio_reg_offset(GEN8_OACTXCONTROL);
 +  reg_state[ctx_oactxctrl + 1] = workload->oactxctrl;
 +
 +  for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
 +  u32 state_offset = ctx_flexeu0 + i * 2;
 +  u32 mmio = flex_mmio[i];
 +
 +  reg_state[state_offset] = mmio;
 +  reg_state[state_offset + 1] = workload->flex_mmio[i];
 +  }
 +  }
 +}
 +
+ static void update_shadow_pdps(struct intel_vgpu_workload *workload)
+ {
+   struct intel_vgpu *vgpu = workload->vgpu;
+   int ring_id = workload->ring_id;
+   struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
+   struct drm_i915_gem_object *ctx_obj =
+   shadow_ctx->engine[ring_id].state->obj;
+   struct execlist_ring_context *shadow_ring_context;
+   struct page *page;
+ 
+   if (WARN_ON(!workload->shadow_mm))
+   return;
+ 
+   if (WARN_ON(!atomic_read(>shadow_mm->pincount)))
+   return;
+ 
+   page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
+   shadow_ring_context = kmap(page);
+   set_context_pdp_root_pointer(shadow_ring_context,
+   (void *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
+   kunmap(page);
+ }
+ 
  static int populate_shadow_context(struct intel_vgpu_workload *workload)
  {
struct intel_vgpu *vgpu = workload->vgpu;


pgpGlinVdYWAE.pgp
Description: OpenPGP digital signature

[PATCH] usbip: tools: usbipd: exclude exported devices from exportable device list

[Shuah Khan]

usbipd includes exported devices in response to exportable device list.
Exclude exported devices from exportable device list to avoid:

- import requests for devices that are exported only to fail the request.
- revealing devices that are imported by a client to another client.

Signed-off-by: Shuah Khan 
---
 tools/usb/usbip/src/usbipd.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tools/usb/usbip/src/usbipd.c b/tools/usb/usbip/src/usbipd.c
index f8ff735eb100..32864c52942d 100644
--- a/tools/usb/usbip/src/usbipd.c
+++ b/tools/usb/usbip/src/usbipd.c
@@ -175,10 +175,21 @@ static int send_reply_devlist(int connfd)
struct list_head *j;
int rc, i;
 
+   /*
+* Exclude devices that are already exported to a client from
+* the exportable device list to avoid:
+*  - import requests for devices that are exported only to
+*fail the request.
+*  - revealing devices that are imported by a client to
+*another client.
+*/
+
reply.ndev = 0;
/* number of exported devices */
list_for_each(j, >edev_list) {
-   reply.ndev += 1;
+   edev = list_entry(j, struct usbip_exported_device, node);
+   if (edev->status != SDEV_ST_USED)
+   reply.ndev += 1;
}
info("exportable devices: %d", reply.ndev);
 
@@ -197,6 +208,9 @@ static int send_reply_devlist(int connfd)
 
list_for_each(j, >edev_list) {
edev = list_entry(j, struct usbip_exported_device, node);
+   if (edev->status == SDEV_ST_USED)
+   continue;
+
dump_usb_device(>udev);
memcpy(_udev, >udev, sizeof(pdu_udev));
usbip_net_pack_usb_device(1, _udev);
-- 
2.14.1

[PATCH] usbip: tools: usbipd: exclude exported devices from exportable device list

[Shuah Khan]

usbipd includes exported devices in response to exportable device list.
Exclude exported devices from exportable device list to avoid:

- import requests for devices that are exported only to fail the request.
- revealing devices that are imported by a client to another client.

Signed-off-by: Shuah Khan 
---
 tools/usb/usbip/src/usbipd.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tools/usb/usbip/src/usbipd.c b/tools/usb/usbip/src/usbipd.c
index f8ff735eb100..32864c52942d 100644
--- a/tools/usb/usbip/src/usbipd.c
+++ b/tools/usb/usbip/src/usbipd.c
@@ -175,10 +175,21 @@ static int send_reply_devlist(int connfd)
struct list_head *j;
int rc, i;
 
+   /*
+* Exclude devices that are already exported to a client from
+* the exportable device list to avoid:
+*  - import requests for devices that are exported only to
+*fail the request.
+*  - revealing devices that are imported by a client to
+*another client.
+*/
+
reply.ndev = 0;
/* number of exported devices */
list_for_each(j, >edev_list) {
-   reply.ndev += 1;
+   edev = list_entry(j, struct usbip_exported_device, node);
+   if (edev->status != SDEV_ST_USED)
+   reply.ndev += 1;
}
info("exportable devices: %d", reply.ndev);
 
@@ -197,6 +208,9 @@ static int send_reply_devlist(int connfd)
 
list_for_each(j, >edev_list) {
edev = list_entry(j, struct usbip_exported_device, node);
+   if (edev->status == SDEV_ST_USED)
+   continue;
+
dump_usb_device(>udev);
memcpy(_udev, >udev, sizeof(pdu_udev));
usbip_net_pack_usb_device(1, _udev);
-- 
2.14.1