Re: [PATCH] s390/crypto: make cca_public_sec and cca_token_hdr const

[Heiko Carstens]

On Sun, Aug 06, 2017 at 11:22:27AM +0530, Bhumika Goyal wrote:
> Declare cca_public_sec and cca_token_hdr structures as const as they are
> only used during copy operations.
> 
> Signed-off-by: Bhumika Goyal 
> ---
>  drivers/s390/crypto/zcrypt_cca_key.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/s390/crypto/zcrypt_cca_key.h 
> b/drivers/s390/crypto/zcrypt_cca_key.h
> index 12cff62..7b78ba6 100644
> --- a/drivers/s390/crypto/zcrypt_cca_key.h
> +++ b/drivers/s390/crypto/zcrypt_cca_key.h
> @@ -116,10 +116,10 @@ struct cca_pvt_ext_CRT_sec {
>   */
>  static inline int zcrypt_type6_mex_key_en(struct ica_rsa_modexpo *mex, void 
> *p)
>  {
> - static struct cca_token_hdr static_pub_hdr = {
> + static const struct cca_token_hdr static_pub_hdr = {
>   .token_identifier   =  0x1E,
>   };
> - static struct cca_public_sec static_pub_sec = {
> + static const struct cca_public_sec static_pub_sec = {
>   .section_identifier =  0x04,
>   };
>   struct {
> @@ -176,7 +176,7 @@ static inline int zcrypt_type6_mex_key_en(struct 
> ica_rsa_modexpo *mex, void *p)
>   */
>  static inline int zcrypt_type6_crt_key(struct ica_rsa_modexpo_crt *crt, void 
> *p)
>  {
> - static struct cca_public_sec static_cca_pub_sec = {
> + static const struct cca_public_sec static_cca_pub_sec = {
>   .section_identifier = 4,
>   .section_length = 0x000f,
>   .exponent_len = 0x0003,

If you look at the code, it seems to be questionable why these structures
are declared static and not simply on the stack. In the first case we are
talking of an assignment of two single bytes two a structure that has
already been zeroed.
Besides this, the two functions in the header file are very large and
shouldn't be unconditionally inlined anyway. This needs to be cleaned
up. So I'm not at all in favor of a patch that just adds a const keyword in
addition.

Re: [PATCH 2/2] PCI: iproc: Add optional brcm,pci-hotplug

[Oza Oza]

On Wed, Aug 9, 2017 at 11:13 AM, Oza Oza  wrote:
> On Wed, Aug 9, 2017 at 10:57 AM, Ray Jui  wrote:
>>
>>
>> On 8/8/2017 10:22 PM, Oza Oza wrote:
>>>
>>> On Tue, Aug 8, 2017 at 7:50 PM, Rob Herring  wrote:

 Please send bindings to DT list.
>>>
>>> Sure, will do that.
>>>
 On Mon, Aug 7, 2017 at 11:44 PM, Oza Pawandeep 
 wrote:
>
> Add description for optional device tree property
> 'brcm,pci-hotplug' for PCI hotplug feature.
>
> Signed-off-by: Oza Pawandeep 
> Reviewed-by: Ray Jui 
>
> diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
> b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
> index b8e48b4..a3bad24 100644
> --- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
> @@ -72,6 +72,29 @@ Optional properties:
>   - brcm,pcie-msi-inten: Needs to be present for some older iProc
> platforms that
>   require the interrupt enable registers to be set explicitly to enable
> MSI
>
> +Optional properties:
> +- brcm,pci-hotplug: PCI hotplug feature is supported.

 I think we should make this a common property. We already have
 "ibm,slot-pluggable", so I'd propose "slot-pluggable".

 There's also "hotpluggable" for memory nodes defined, so we could
 reuse that here.

>>> ok I will rename this to
>>> brcm,slot-pluggable
>>
>>
>> How's brcm,slot-pluggable a common property? It's still brcm specific.
>> Didn't Rob propose either "slot-pluggable" or "hotpluggable"?
>>
>> And note it goes to the generic PCI binding instead iProc PCIe specific
>> binding.
>>
>
> Initially I thought, Rob suggested either "slot-pluggable".
> followed by, "hotpluggable" since memory node already has such property.
>
> but not sure in which generic pci binding I should add ?
> should it be part of
> Documentation/devicetree/bindings/pci/host-generic-pci.txt
>
> Can you please clarify Rob ?
>
> Regards,
> Oza.

To add, every SOC might have different way of implementing hotplug.
so I suppose both the binding documents have to be updated.

Documentation/devicetree/bindings/pci/host-generic-pci.txt
which can have common boolean property
named "hotpluggable"

and SOC specific implementation can stay here
for e.g.
Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
brcm,prsnt-gpios

Rob and Ray:
please let me know how this sounds.

Regards,
Oza.

Re: [PATCH] s390/crypto: make cca_public_sec and cca_token_hdr const

[Heiko Carstens]

On Sun, Aug 06, 2017 at 11:22:27AM +0530, Bhumika Goyal wrote:
> Declare cca_public_sec and cca_token_hdr structures as const as they are
> only used during copy operations.
> 
> Signed-off-by: Bhumika Goyal 
> ---
>  drivers/s390/crypto/zcrypt_cca_key.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/s390/crypto/zcrypt_cca_key.h 
> b/drivers/s390/crypto/zcrypt_cca_key.h
> index 12cff62..7b78ba6 100644
> --- a/drivers/s390/crypto/zcrypt_cca_key.h
> +++ b/drivers/s390/crypto/zcrypt_cca_key.h
> @@ -116,10 +116,10 @@ struct cca_pvt_ext_CRT_sec {
>   */
>  static inline int zcrypt_type6_mex_key_en(struct ica_rsa_modexpo *mex, void 
> *p)
>  {
> - static struct cca_token_hdr static_pub_hdr = {
> + static const struct cca_token_hdr static_pub_hdr = {
>   .token_identifier   =  0x1E,
>   };
> - static struct cca_public_sec static_pub_sec = {
> + static const struct cca_public_sec static_pub_sec = {
>   .section_identifier =  0x04,
>   };
>   struct {
> @@ -176,7 +176,7 @@ static inline int zcrypt_type6_mex_key_en(struct 
> ica_rsa_modexpo *mex, void *p)
>   */
>  static inline int zcrypt_type6_crt_key(struct ica_rsa_modexpo_crt *crt, void 
> *p)
>  {
> - static struct cca_public_sec static_cca_pub_sec = {
> + static const struct cca_public_sec static_cca_pub_sec = {
>   .section_identifier = 4,
>   .section_length = 0x000f,
>   .exponent_len = 0x0003,

If you look at the code, it seems to be questionable why these structures
are declared static and not simply on the stack. In the first case we are
talking of an assignment of two single bytes two a structure that has
already been zeroed.
Besides this, the two functions in the header file are very large and
shouldn't be unconditionally inlined anyway. This needs to be cleaned
up. So I'm not at all in favor of a patch that just adds a const keyword in
addition.

Re: [PATCH 2/2] PCI: iproc: Add optional brcm,pci-hotplug

[Oza Oza]

On Wed, Aug 9, 2017 at 11:13 AM, Oza Oza  wrote:
> On Wed, Aug 9, 2017 at 10:57 AM, Ray Jui  wrote:
>>
>>
>> On 8/8/2017 10:22 PM, Oza Oza wrote:
>>>
>>> On Tue, Aug 8, 2017 at 7:50 PM, Rob Herring  wrote:

 Please send bindings to DT list.
>>>
>>> Sure, will do that.
>>>
 On Mon, Aug 7, 2017 at 11:44 PM, Oza Pawandeep 
 wrote:
>
> Add description for optional device tree property
> 'brcm,pci-hotplug' for PCI hotplug feature.
>
> Signed-off-by: Oza Pawandeep 
> Reviewed-by: Ray Jui 
>
> diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
> b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
> index b8e48b4..a3bad24 100644
> --- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
> @@ -72,6 +72,29 @@ Optional properties:
>   - brcm,pcie-msi-inten: Needs to be present for some older iProc
> platforms that
>   require the interrupt enable registers to be set explicitly to enable
> MSI
>
> +Optional properties:
> +- brcm,pci-hotplug: PCI hotplug feature is supported.

 I think we should make this a common property. We already have
 "ibm,slot-pluggable", so I'd propose "slot-pluggable".

 There's also "hotpluggable" for memory nodes defined, so we could
 reuse that here.

>>> ok I will rename this to
>>> brcm,slot-pluggable
>>
>>
>> How's brcm,slot-pluggable a common property? It's still brcm specific.
>> Didn't Rob propose either "slot-pluggable" or "hotpluggable"?
>>
>> And note it goes to the generic PCI binding instead iProc PCIe specific
>> binding.
>>
>
> Initially I thought, Rob suggested either "slot-pluggable".
> followed by, "hotpluggable" since memory node already has such property.
>
> but not sure in which generic pci binding I should add ?
> should it be part of
> Documentation/devicetree/bindings/pci/host-generic-pci.txt
>
> Can you please clarify Rob ?
>
> Regards,
> Oza.

To add, every SOC might have different way of implementing hotplug.
so I suppose both the binding documents have to be updated.

Documentation/devicetree/bindings/pci/host-generic-pci.txt
which can have common boolean property
named "hotpluggable"

and SOC specific implementation can stay here
for e.g.
Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
brcm,prsnt-gpios

Rob and Ray:
please let me know how this sounds.

Regards,
Oza.

Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

[Kishon Vijay Abraham I]

Vivek,

On Tuesday 08 August 2017 09:20 PM, Vivek Gautam wrote:
> Hi Koshon,
> 
> On 2017-08-08 17:39, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Friday 04 August 2017 12:18 PM, Vivek Gautam wrote:
>>> Refactoring the qcom-ufs phy and host controller code to move
>>> further towards the generic phy usage. Right now the qcom-ufs exports
>>> a bunch of APIs that are used by the host controller to initialize
>>> the phy.
>>> With this patch series, we populate the phy_init() which was a no-op
>>> earlier. The host controller then calls the phy_init() at the designated
>>> place rather than doing it invariably in ufs_hcd_init().
>>>
>>> As part of this series, we introduce phy modes for ufs phy.
>>> The M-PHY has two data rates defined for each generations (Gears) -
>>> Rate A and Rate B. These can serve as the two modes of ufs HS phy.
>>> Host controller can direct the phy to set the respective configurations
>>> based on the phy modes.
>>>
>>> The patch-series has been tested with necessary dt patches on db820c.
>>
>> Can the first 3 patches go independently of the other 2 or should all this be
>> merged together?
> 
> The first 3 patches are independent, but the next 2 patches depend on those 3
> for functionality.
> I would prefer all to go in one tree. If you want to pull these in the phy 
> tree,
> I will request Subhash/Martin to ack the patches.

sure, that should be fine!

Thanks
Kishon

Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

[Kishon Vijay Abraham I]

Vivek,

On Tuesday 08 August 2017 09:20 PM, Vivek Gautam wrote:
> Hi Koshon,
> 
> On 2017-08-08 17:39, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Friday 04 August 2017 12:18 PM, Vivek Gautam wrote:
>>> Refactoring the qcom-ufs phy and host controller code to move
>>> further towards the generic phy usage. Right now the qcom-ufs exports
>>> a bunch of APIs that are used by the host controller to initialize
>>> the phy.
>>> With this patch series, we populate the phy_init() which was a no-op
>>> earlier. The host controller then calls the phy_init() at the designated
>>> place rather than doing it invariably in ufs_hcd_init().
>>>
>>> As part of this series, we introduce phy modes for ufs phy.
>>> The M-PHY has two data rates defined for each generations (Gears) -
>>> Rate A and Rate B. These can serve as the two modes of ufs HS phy.
>>> Host controller can direct the phy to set the respective configurations
>>> based on the phy modes.
>>>
>>> The patch-series has been tested with necessary dt patches on db820c.
>>
>> Can the first 3 patches go independently of the other 2 or should all this be
>> merged together?
> 
> The first 3 patches are independent, but the next 2 patches depend on those 3
> for functionality.
> I would prefer all to go in one tree. If you want to pull these in the phy 
> tree,
> I will request Subhash/Martin to ack the patches.

sure, that should be fine!

Thanks
Kishon

Kdump not working with rt patch, tested under 4.4.32/4.4.79

[Journey Journey]

Test case: 
https://github.com/saiyamd/softlockup_test/blob/master/softlockup_test.c

Kdump not working with rt patch, tested under 4.4.32/4.4.79

[Journey Journey]

Test case: 
https://github.com/saiyamd/softlockup_test/blob/master/softlockup_test.c

Re: [PATCH 2/2] PCI: iproc: Add optional brcm,pci-hotplug

[Oza Oza]

On Wed, Aug 9, 2017 at 10:57 AM, Ray Jui  wrote:
>
>
> On 8/8/2017 10:22 PM, Oza Oza wrote:
>>
>> On Tue, Aug 8, 2017 at 7:50 PM, Rob Herring  wrote:
>>>
>>> Please send bindings to DT list.
>>
>> Sure, will do that.
>>
>>> On Mon, Aug 7, 2017 at 11:44 PM, Oza Pawandeep 
>>> wrote:

 Add description for optional device tree property
 'brcm,pci-hotplug' for PCI hotplug feature.

 Signed-off-by: Oza Pawandeep 
 Reviewed-by: Ray Jui 

 diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
 b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
 index b8e48b4..a3bad24 100644
 --- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
 +++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
 @@ -72,6 +72,29 @@ Optional properties:
   - brcm,pcie-msi-inten: Needs to be present for some older iProc
 platforms that
   require the interrupt enable registers to be set explicitly to enable
 MSI

 +Optional properties:
 +- brcm,pci-hotplug: PCI hotplug feature is supported.
>>>
>>> I think we should make this a common property. We already have
>>> "ibm,slot-pluggable", so I'd propose "slot-pluggable".
>>>
>>> There's also "hotpluggable" for memory nodes defined, so we could
>>> reuse that here.
>>>
>> ok I will rename this to
>> brcm,slot-pluggable
>
>
> How's brcm,slot-pluggable a common property? It's still brcm specific.
> Didn't Rob propose either "slot-pluggable" or "hotpluggable"?
>
> And note it goes to the generic PCI binding instead iProc PCIe specific
> binding.
>

Initially I thought, Rob suggested either "slot-pluggable".
followed by, "hotpluggable" since memory node already has such property.

but not sure in which generic pci binding I should add ?
should it be part of
Documentation/devicetree/bindings/pci/host-generic-pci.txt

Can you please clarify Rob ?

Regards,
Oza.

Re: [PATCH 2/2] PCI: iproc: Add optional brcm,pci-hotplug

[Oza Oza]

On Wed, Aug 9, 2017 at 10:57 AM, Ray Jui  wrote:
>
>
> On 8/8/2017 10:22 PM, Oza Oza wrote:
>>
>> On Tue, Aug 8, 2017 at 7:50 PM, Rob Herring  wrote:
>>>
>>> Please send bindings to DT list.
>>
>> Sure, will do that.
>>
>>> On Mon, Aug 7, 2017 at 11:44 PM, Oza Pawandeep 
>>> wrote:

 Add description for optional device tree property
 'brcm,pci-hotplug' for PCI hotplug feature.

 Signed-off-by: Oza Pawandeep 
 Reviewed-by: Ray Jui 

 diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
 b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
 index b8e48b4..a3bad24 100644
 --- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
 +++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
 @@ -72,6 +72,29 @@ Optional properties:
   - brcm,pcie-msi-inten: Needs to be present for some older iProc
 platforms that
   require the interrupt enable registers to be set explicitly to enable
 MSI

 +Optional properties:
 +- brcm,pci-hotplug: PCI hotplug feature is supported.
>>>
>>> I think we should make this a common property. We already have
>>> "ibm,slot-pluggable", so I'd propose "slot-pluggable".
>>>
>>> There's also "hotpluggable" for memory nodes defined, so we could
>>> reuse that here.
>>>
>> ok I will rename this to
>> brcm,slot-pluggable
>
>
> How's brcm,slot-pluggable a common property? It's still brcm specific.
> Didn't Rob propose either "slot-pluggable" or "hotpluggable"?
>
> And note it goes to the generic PCI binding instead iProc PCIe specific
> binding.
>

Initially I thought, Rob suggested either "slot-pluggable".
followed by, "hotpluggable" since memory node already has such property.

but not sure in which generic pci binding I should add ?
should it be part of
Documentation/devicetree/bindings/pci/host-generic-pci.txt

Can you please clarify Rob ?

Regards,
Oza.

Re: [PATCH v4 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

Hi Felipe,

On 27 July 2017 at 13:14, Baolin Wang  wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this in their kernels
> or USB gadget devices based on Linux (such as mobile phones) may not behave
> as they should. Thus provide a standard USB charger support in USB phy core
> for doing this in kernel.
>
> Now introduce one user with wm831x_power to support and test the usb charger.
> In future we will also cnvert below power drivers:
> drivers/power/supply/axp288_charger.c
> drivers/power/supply/bq24190_charger.c
> drivers/power/supply/charger-manager.c
> drivers/power/supply/qcom_smbb.c
>
> Changes since v3:
>  - Bail out errors when failed to find usb phy for wm831x_power driver.
> Changes since v2:
>  - Add DT binding documentation for wm831x_power driver.
>  - Change 'usb-phy' as one optional property for wm831x_power driver.
> Changes since v1:
>  - Fix building errors.

Do you have any comments about usb charger support in usb phy core? Thanks.

>
> Baolin Wang (3):
>   include: uapi: usb: Introduce USB charger type and state definition
>   usb: phy: Add USB charger support
>   power: wm831x_power: Support USB charger current limit management
>
>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>  drivers/power/supply/wm831x_power.c  |   72 ++
>  drivers/usb/phy/phy.c|  272 
> ++
>  include/linux/usb/phy.h  |   49 
>  include/uapi/linux/usb/charger.h |   31 +++
>  5 files changed, 425 insertions(+)
>  create mode 100644 include/uapi/linux/usb/charger.h
>
> --
> 1.7.9.5
>



-- 
Baolin.wang
Best Regards

Re: [PATCH v4 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

Hi Felipe,

On 27 July 2017 at 13:14, Baolin Wang  wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this in their kernels
> or USB gadget devices based on Linux (such as mobile phones) may not behave
> as they should. Thus provide a standard USB charger support in USB phy core
> for doing this in kernel.
>
> Now introduce one user with wm831x_power to support and test the usb charger.
> In future we will also cnvert below power drivers:
> drivers/power/supply/axp288_charger.c
> drivers/power/supply/bq24190_charger.c
> drivers/power/supply/charger-manager.c
> drivers/power/supply/qcom_smbb.c
>
> Changes since v3:
>  - Bail out errors when failed to find usb phy for wm831x_power driver.
> Changes since v2:
>  - Add DT binding documentation for wm831x_power driver.
>  - Change 'usb-phy' as one optional property for wm831x_power driver.
> Changes since v1:
>  - Fix building errors.

Do you have any comments about usb charger support in usb phy core? Thanks.

>
> Baolin Wang (3):
>   include: uapi: usb: Introduce USB charger type and state definition
>   usb: phy: Add USB charger support
>   power: wm831x_power: Support USB charger current limit management
>
>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>  drivers/power/supply/wm831x_power.c  |   72 ++
>  drivers/usb/phy/phy.c|  272 
> ++
>  include/linux/usb/phy.h  |   49 
>  include/uapi/linux/usb/charger.h |   31 +++
>  5 files changed, 425 insertions(+)
>  create mode 100644 include/uapi/linux/usb/charger.h
>
> --
> 1.7.9.5
>



-- 
Baolin.wang
Best Regards

[PATCH] perf: Util.py add_stats() computes the mean correctly

[Dima Kogan]

add_stats() is a utility function for perf scripts to accumulate a value, and
keep track of some statistics. The mean is one of the statistics it keeps track
of, but due to a bug, this wasn't being computed properly. This patch makes the
computation correct

Signed-off-by: Dima Kogan 
---
 tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py 
b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py
index 1d95009592eb..3d1f08b8ba19 100644
--- a/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py
+++ b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py
@@ -41,7 +41,7 @@ def add_stats(dict, key, value):
min = value
if value > max:
max = value
-   avg = (avg + value) / 2
+   avg = (avg*count + float(value)) / (count + 1)
dict[key] = (min, max, avg, count + 1)
 
 def clear_term():
-- 
2.11.0

[PATCH] perf: Util.py add_stats() computes the mean correctly

[Dima Kogan]

add_stats() is a utility function for perf scripts to accumulate a value, and
keep track of some statistics. The mean is one of the statistics it keeps track
of, but due to a bug, this wasn't being computed properly. This patch makes the
computation correct

Signed-off-by: Dima Kogan 
---
 tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py 
b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py
index 1d95009592eb..3d1f08b8ba19 100644
--- a/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py
+++ b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py
@@ -41,7 +41,7 @@ def add_stats(dict, key, value):
min = value
if value > max:
max = value
-   avg = (avg + value) / 2
+   avg = (avg*count + float(value)) / (count + 1)
dict[key] = (min, max, avg, count + 1)
 
 def clear_term():
-- 
2.11.0

[PATCH v2 1/4] phy: phy-mt65xx-usb3: add PCIe PHY support

[Chunfeng Yun]

From: Ryder Lee 

This patch adds PCIe PHY setting part.

Signed-off-by: Ryder Lee 
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c | 228 ++
 1 file changed, 206 insertions(+), 22 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index 59b110f..a9a85fa 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -29,7 +29,7 @@
 #define SSUSB_SIFSLV_V1_U2FREQ 0x100   /* shared by u2 phys */
 /* u2 phy bank */
 #define SSUSB_SIFSLV_V1_U2PHY_COM  0x000
-/* u3 phy banks */
+/* u3/pcie phy banks */
 #define SSUSB_SIFSLV_V1_U3PHYD 0x000
 #define SSUSB_SIFSLV_V1_U3PHYA 0x200
 
@@ -99,6 +99,23 @@
 #define P2C_RG_SESSEND BIT(4)
 #define P2C_RG_AVALID  BIT(2)
 
+#define U3P_U3_CHIP_GPIO_CTLD  0x0c
+#define P3C_REG_IP_SW_RST  BIT(31)
+#define P3C_MCU_BUS_CK_GATE_EN BIT(30)
+#define P3C_FORCE_IP_SW_RSTBIT(29)
+
+#define U3P_U3_CHIP_GPIO_CTLE  0x10
+#define P3C_RG_SWRST_U3_PHYD   BIT(25)
+#define P3C_RG_SWRST_U3_PHYD_FORCE_EN  BIT(24)
+
+#define U3P_U3_PHYA_REG0   0x000
+#define P3A_RG_CLKDRV_OFF  GENMASK(3, 2)
+#define P3A_RG_CLKDRV_OFF_VAL(x)   ((0x3 & (x)) << 2)
+
+#define U3P_U3_PHYA_REG1   0x004
+#define P3A_RG_CLKDRV_AMP  GENMASK(31, 29)
+#define P3A_RG_CLKDRV_AMP_VAL(x)   ((0x7 & (x)) << 29)
+
 #define U3P_U3_PHYA_REG6   0x018
 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
 #define P3A_RG_TX_EIDLE_CM_VAL(x)  ((0xf & (x)) << 28)
@@ -108,9 +125,40 @@
 #define P3A_RG_RX_DAC_MUX_VAL(x)   ((0x1f & (x)) << 1)
 
 #define U3P_U3_PHYA_DA_REG00x100
+#define P3A_RG_XTAL_EXT_PE2H   GENMASK(17, 16)
+#define P3A_RG_XTAL_EXT_PE2H_VAL(x)((0x3 & (x)) << 16)
+#define P3A_RG_XTAL_EXT_PE1H   GENMASK(13, 12)
+#define P3A_RG_XTAL_EXT_PE1H_VAL(x)((0x3 & (x)) << 12)
 #define P3A_RG_XTAL_EXT_EN_U3  GENMASK(11, 10)
 #define P3A_RG_XTAL_EXT_EN_U3_VAL(x)   ((0x3 & (x)) << 10)
 
+#define U3P_U3_PHYA_DA_REG40x108
+#define P3A_RG_PLL_DIVEN_PE2H  GENMASK(21, 19)
+#define P3A_RG_PLL_BC_PE2H GENMASK(7, 6)
+#define P3A_RG_PLL_BC_PE2H_VAL(x)  ((0x3 & (x)) << 6)
+
+#define U3P_U3_PHYA_DA_REG50x10c
+#define P3A_RG_PLL_BR_PE2H GENMASK(29, 28)
+#define P3A_RG_PLL_BR_PE2H_VAL(x)  ((0x3 & (x)) << 28)
+#define P3A_RG_PLL_IC_PE2H GENMASK(15, 12)
+#define P3A_RG_PLL_IC_PE2H_VAL(x)  ((0xf & (x)) << 12)
+
+#define U3P_U3_PHYA_DA_REG60x110
+#define P3A_RG_PLL_IR_PE2H GENMASK(19, 16)
+#define P3A_RG_PLL_IR_PE2H_VAL(x)  ((0xf & (x)) << 16)
+
+#define U3P_U3_PHYA_DA_REG70x114
+#define P3A_RG_PLL_BP_PE2H GENMASK(19, 16)
+#define P3A_RG_PLL_BP_PE2H_VAL(x)  ((0xf & (x)) << 16)
+
+#define U3P_U3_PHYA_DA_REG20   0x13c
+#define P3A_RG_PLL_DELTA1_PE2H GENMASK(31, 16)
+#define P3A_RG_PLL_DELTA1_PE2H_VAL(x)  ((0x & (x)) << 16)
+
+#define U3P_U3_PHYA_DA_REG25   0x148
+#define P3A_RG_PLL_DELTA_PE2H  GENMASK(15, 0)
+#define P3A_RG_PLL_DELTA_PE2H_VAL(x)   (0x & (x))
+
 #define U3P_U3_PHYD_LFPS1  0x00c
 #define P3D_RG_FWAKE_THGENMASK(21, 16)
 #define P3D_RG_FWAKE_TH_VAL(x) ((0x3f & (x)) << 16)
@@ -322,8 +370,8 @@ static void u3_phy_instance_init(struct mt65xx_u3phy *u3phy,
dev_dbg(u3phy->dev, "%s(%d)\n", __func__, instance->index);
 }
 
-static void phy_instance_init(struct mt65xx_u3phy *u3phy,
-   struct mt65xx_phy_instance *instance)
+static void u2_phy_instance_init(struct mt65xx_u3phy *u3phy,
+struct mt65xx_phy_instance *instance)
 {
struct u2phy_banks *u2_banks = >u2_banks;
void __iomem *com = u2_banks->com;
@@ -384,8 +432,8 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
 }
 
-static void phy_instance_power_on(struct mt65xx_u3phy *u3phy,
-   struct mt65xx_phy_instance *instance)
+static void u2_phy_instance_power_on(struct mt65xx_u3phy *u3phy,
+struct mt65xx_phy_instance *instance)
 {
struct u2phy_banks *u2_banks = >u2_banks;
void __iomem *com = u2_banks->com;
@@ -420,8 +468,8 @@ static void phy_instance_power_on(struct mt65xx_u3phy 
*u3phy,
dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
 }
 
-static void phy_instance_power_off(struct mt65xx_u3phy *u3phy,
-   struct mt65xx_phy_instance *instance)
+static void u2_phy_instance_power_off(struct mt65xx_u3phy *u3phy,
+ struct mt65xx_phy_instance *instance)
 {
struct u2phy_banks *u2_banks = >u2_banks;
void __iomem *com = u2_banks->com;
@@ -458,8 +506,8 @@ static void phy_instance_power_off(struct mt65xx_u3phy 
*u3phy,

[PATCH v2 1/4] phy: phy-mt65xx-usb3: add PCIe PHY support

[Chunfeng Yun]

From: Ryder Lee 

This patch adds PCIe PHY setting part.

Signed-off-by: Ryder Lee 
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c | 228 ++
 1 file changed, 206 insertions(+), 22 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index 59b110f..a9a85fa 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -29,7 +29,7 @@
 #define SSUSB_SIFSLV_V1_U2FREQ 0x100   /* shared by u2 phys */
 /* u2 phy bank */
 #define SSUSB_SIFSLV_V1_U2PHY_COM  0x000
-/* u3 phy banks */
+/* u3/pcie phy banks */
 #define SSUSB_SIFSLV_V1_U3PHYD 0x000
 #define SSUSB_SIFSLV_V1_U3PHYA 0x200
 
@@ -99,6 +99,23 @@
 #define P2C_RG_SESSEND BIT(4)
 #define P2C_RG_AVALID  BIT(2)
 
+#define U3P_U3_CHIP_GPIO_CTLD  0x0c
+#define P3C_REG_IP_SW_RST  BIT(31)
+#define P3C_MCU_BUS_CK_GATE_EN BIT(30)
+#define P3C_FORCE_IP_SW_RSTBIT(29)
+
+#define U3P_U3_CHIP_GPIO_CTLE  0x10
+#define P3C_RG_SWRST_U3_PHYD   BIT(25)
+#define P3C_RG_SWRST_U3_PHYD_FORCE_EN  BIT(24)
+
+#define U3P_U3_PHYA_REG0   0x000
+#define P3A_RG_CLKDRV_OFF  GENMASK(3, 2)
+#define P3A_RG_CLKDRV_OFF_VAL(x)   ((0x3 & (x)) << 2)
+
+#define U3P_U3_PHYA_REG1   0x004
+#define P3A_RG_CLKDRV_AMP  GENMASK(31, 29)
+#define P3A_RG_CLKDRV_AMP_VAL(x)   ((0x7 & (x)) << 29)
+
 #define U3P_U3_PHYA_REG6   0x018
 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
 #define P3A_RG_TX_EIDLE_CM_VAL(x)  ((0xf & (x)) << 28)
@@ -108,9 +125,40 @@
 #define P3A_RG_RX_DAC_MUX_VAL(x)   ((0x1f & (x)) << 1)
 
 #define U3P_U3_PHYA_DA_REG00x100
+#define P3A_RG_XTAL_EXT_PE2H   GENMASK(17, 16)
+#define P3A_RG_XTAL_EXT_PE2H_VAL(x)((0x3 & (x)) << 16)
+#define P3A_RG_XTAL_EXT_PE1H   GENMASK(13, 12)
+#define P3A_RG_XTAL_EXT_PE1H_VAL(x)((0x3 & (x)) << 12)
 #define P3A_RG_XTAL_EXT_EN_U3  GENMASK(11, 10)
 #define P3A_RG_XTAL_EXT_EN_U3_VAL(x)   ((0x3 & (x)) << 10)
 
+#define U3P_U3_PHYA_DA_REG40x108
+#define P3A_RG_PLL_DIVEN_PE2H  GENMASK(21, 19)
+#define P3A_RG_PLL_BC_PE2H GENMASK(7, 6)
+#define P3A_RG_PLL_BC_PE2H_VAL(x)  ((0x3 & (x)) << 6)
+
+#define U3P_U3_PHYA_DA_REG50x10c
+#define P3A_RG_PLL_BR_PE2H GENMASK(29, 28)
+#define P3A_RG_PLL_BR_PE2H_VAL(x)  ((0x3 & (x)) << 28)
+#define P3A_RG_PLL_IC_PE2H GENMASK(15, 12)
+#define P3A_RG_PLL_IC_PE2H_VAL(x)  ((0xf & (x)) << 12)
+
+#define U3P_U3_PHYA_DA_REG60x110
+#define P3A_RG_PLL_IR_PE2H GENMASK(19, 16)
+#define P3A_RG_PLL_IR_PE2H_VAL(x)  ((0xf & (x)) << 16)
+
+#define U3P_U3_PHYA_DA_REG70x114
+#define P3A_RG_PLL_BP_PE2H GENMASK(19, 16)
+#define P3A_RG_PLL_BP_PE2H_VAL(x)  ((0xf & (x)) << 16)
+
+#define U3P_U3_PHYA_DA_REG20   0x13c
+#define P3A_RG_PLL_DELTA1_PE2H GENMASK(31, 16)
+#define P3A_RG_PLL_DELTA1_PE2H_VAL(x)  ((0x & (x)) << 16)
+
+#define U3P_U3_PHYA_DA_REG25   0x148
+#define P3A_RG_PLL_DELTA_PE2H  GENMASK(15, 0)
+#define P3A_RG_PLL_DELTA_PE2H_VAL(x)   (0x & (x))
+
 #define U3P_U3_PHYD_LFPS1  0x00c
 #define P3D_RG_FWAKE_THGENMASK(21, 16)
 #define P3D_RG_FWAKE_TH_VAL(x) ((0x3f & (x)) << 16)
@@ -322,8 +370,8 @@ static void u3_phy_instance_init(struct mt65xx_u3phy *u3phy,
dev_dbg(u3phy->dev, "%s(%d)\n", __func__, instance->index);
 }
 
-static void phy_instance_init(struct mt65xx_u3phy *u3phy,
-   struct mt65xx_phy_instance *instance)
+static void u2_phy_instance_init(struct mt65xx_u3phy *u3phy,
+struct mt65xx_phy_instance *instance)
 {
struct u2phy_banks *u2_banks = >u2_banks;
void __iomem *com = u2_banks->com;
@@ -384,8 +432,8 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
 }
 
-static void phy_instance_power_on(struct mt65xx_u3phy *u3phy,
-   struct mt65xx_phy_instance *instance)
+static void u2_phy_instance_power_on(struct mt65xx_u3phy *u3phy,
+struct mt65xx_phy_instance *instance)
 {
struct u2phy_banks *u2_banks = >u2_banks;
void __iomem *com = u2_banks->com;
@@ -420,8 +468,8 @@ static void phy_instance_power_on(struct mt65xx_u3phy 
*u3phy,
dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
 }
 
-static void phy_instance_power_off(struct mt65xx_u3phy *u3phy,
-   struct mt65xx_phy_instance *instance)
+static void u2_phy_instance_power_off(struct mt65xx_u3phy *u3phy,
+ struct mt65xx_phy_instance *instance)
 {
struct u2phy_banks *u2_banks = >u2_banks;
void __iomem *com = u2_banks->com;
@@ -458,8 +506,8 @@ static void phy_instance_power_off(struct mt65xx_u3phy 
*u3phy,
dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
 }
 
-static void 

[PATCH v2 2/4] phy: phy-mt65xx-usb3: add SATA PHY support

[Chunfeng Yun]

From: Ryder Lee 

This patch adds SATA setting part.

Signed-off-by: Ryder Lee 
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c | 133 --
 1 file changed, 129 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index a9a85fa..5e9a415 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -29,7 +29,7 @@
 #define SSUSB_SIFSLV_V1_U2FREQ 0x100   /* shared by u2 phys */
 /* u2 phy bank */
 #define SSUSB_SIFSLV_V1_U2PHY_COM  0x000
-/* u3/pcie phy banks */
+/* u3/pcie/sata phy banks */
 #define SSUSB_SIFSLV_V1_U3PHYD 0x000
 #define SSUSB_SIFSLV_V1_U3PHYA 0x200
 
@@ -199,6 +199,65 @@
 #define U3P_SR_COEF_DIVISOR1000
 #define U3P_FM_DET_CYCLE_CNT   1024
 
+/* SATA register setting */
+#define PHYD_CTRL_SIGNAL_MODE4 0x1c
+/* CDR Charge Pump P-path current adjustment */
+#define RG_CDR_BICLTD1_GEN1_MSKGENMASK(23, 20)
+#define RG_CDR_BICLTD1_GEN1_VAL(x) ((0xf & (x)) << 20)
+#define RG_CDR_BICLTD0_GEN1_MSKGENMASK(11, 8)
+#define RG_CDR_BICLTD0_GEN1_VAL(x) ((0xf & (x)) << 8)
+
+#define PHYD_DESIGN_OPTION20x24
+/* Symbol lock count selection */
+#define RG_LOCK_CNT_SEL_MSKGENMASK(5, 4)
+#define RG_LOCK_CNT_SEL_VAL(x) ((0x3 & (x)) << 4)
+
+#define PHYD_DESIGN_OPTION90x40
+/* COMWAK GAP width window */
+#define RG_TG_MAX_MSK  GENMASK(20, 16)
+#define RG_TG_MAX_VAL(x)   ((0x1f & (x)) << 16)
+/* COMINIT GAP width window */
+#define RG_T2_MAX_MSK  GENMASK(13, 8)
+#define RG_T2_MAX_VAL(x)   ((0x3f & (x)) << 8)
+/* COMWAK GAP width window */
+#define RG_TG_MIN_MSK  GENMASK(7, 5)
+#define RG_TG_MIN_VAL(x)   ((0x7 & (x)) << 5)
+/* COMINIT GAP width window */
+#define RG_T2_MIN_MSK  GENMASK(4, 0)
+#define RG_T2_MIN_VAL(x)   (0x1f & (x))
+
+#define ANA_RG_CTRL_SIGNAL10x4c
+/* TX driver tail current control for 0dB de-empahsis mdoe for Gen1 speed */
+#define RG_IDRV_0DB_GEN1_MSK   GENMASK(13, 8)
+#define RG_IDRV_0DB_GEN1_VAL(x)((0x3f & (x)) << 8)
+
+#define ANA_RG_CTRL_SIGNAL40x58
+#define RG_CDR_BICLTR_GEN1_MSK GENMASK(23, 20)
+#define RG_CDR_BICLTR_GEN1_VAL(x)  ((0xf & (x)) << 20)
+/* Loop filter R1 resistance adjustment for Gen1 speed */
+#define RG_CDR_BR_GEN2_MSK GENMASK(10, 8)
+#define RG_CDR_BR_GEN2_VAL(x)  ((0x7 & (x)) << 8)
+
+#define ANA_RG_CTRL_SIGNAL60x60
+/* I-path capacitance adjustment for Gen1 */
+#define RG_CDR_BC_GEN1_MSK GENMASK(28, 24)
+#define RG_CDR_BC_GEN1_VAL(x)  ((0x1f & (x)) << 24)
+#define RG_CDR_BIRLTR_GEN1_MSK GENMASK(4, 0)
+#define RG_CDR_BIRLTR_GEN1_VAL(x)  (0x1f & (x))
+
+#define ANA_EQ_EYE_CTRL_SIGNAL10x6c
+/* RX Gen1 LEQ tuning step */
+#define RG_EQ_DLEQ_LFI_GEN1_MSKGENMASK(11, 8)
+#define RG_EQ_DLEQ_LFI_GEN1_VAL(x) ((0xf & (x)) << 8)
+
+#define ANA_EQ_EYE_CTRL_SIGNAL40xd8
+#define RG_CDR_BIRLTD0_GEN1_MSKGENMASK(20, 16)
+#define RG_CDR_BIRLTD0_GEN1_VAL(x) ((0x1f & (x)) << 16)
+
+#define ANA_EQ_EYE_CTRL_SIGNAL50xdc
+#define RG_CDR_BIRLTD0_GEN3_MSKGENMASK(4, 0)
+#define RG_CDR_BIRLTD0_GEN3_VAL(x) (0x1f & (x))
+
 enum mt_phy_version {
MT_PHY_V1 = 1,
MT_PHY_V2,
@@ -630,6 +689,64 @@ static void pcie_phy_instance_power_off(struct 
mt65xx_u3phy *u3phy,
writel(tmp, bank->chip + U3P_U3_CHIP_GPIO_CTLE);
 }
 
+static void sata_phy_instance_init(struct mt65xx_u3phy *u3phy,
+  struct mt65xx_phy_instance *instance)
+{
+   struct u3phy_banks *u3_banks = >u3_banks;
+   void __iomem *phyd = u3_banks->phyd;
+   u32 tmp;
+
+   /* charge current adjustment */
+   tmp = readl(phyd + ANA_RG_CTRL_SIGNAL6);
+   tmp &= ~(RG_CDR_BIRLTR_GEN1_MSK | RG_CDR_BC_GEN1_MSK);
+   tmp |= RG_CDR_BIRLTR_GEN1_VAL(0x6) | RG_CDR_BC_GEN1_VAL(0x1a);
+   writel(tmp, phyd + ANA_RG_CTRL_SIGNAL6);
+
+   tmp = readl(phyd + ANA_EQ_EYE_CTRL_SIGNAL4);
+   tmp &= ~RG_CDR_BIRLTD0_GEN1_MSK;
+   tmp |= RG_CDR_BIRLTD0_GEN1_VAL(0x18);
+   writel(tmp, phyd + ANA_EQ_EYE_CTRL_SIGNAL4);
+
+   tmp = readl(phyd + ANA_EQ_EYE_CTRL_SIGNAL5);
+   tmp &= ~RG_CDR_BIRLTD0_GEN3_MSK;
+   tmp |= RG_CDR_BIRLTD0_GEN3_VAL(0x06);
+   writel(tmp, phyd + ANA_EQ_EYE_CTRL_SIGNAL5);
+
+   tmp = readl(phyd + ANA_RG_CTRL_SIGNAL4);
+   tmp &= ~(RG_CDR_BICLTR_GEN1_MSK | RG_CDR_BR_GEN2_MSK);
+   tmp |= RG_CDR_BICLTR_GEN1_VAL(0x0c) | RG_CDR_BR_GEN2_VAL(0x07);
+   writel(tmp, phyd + ANA_RG_CTRL_SIGNAL4);
+
+   tmp = readl(phyd + PHYD_CTRL_SIGNAL_MODE4);
+   tmp &= ~(RG_CDR_BICLTD0_GEN1_MSK | RG_CDR_BICLTD1_GEN1_MSK);
+   tmp |= 

[PATCH v2 2/4] phy: phy-mt65xx-usb3: add SATA PHY support

[Chunfeng Yun]

From: Ryder Lee 

This patch adds SATA setting part.

Signed-off-by: Ryder Lee 
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c | 133 --
 1 file changed, 129 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index a9a85fa..5e9a415 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -29,7 +29,7 @@
 #define SSUSB_SIFSLV_V1_U2FREQ 0x100   /* shared by u2 phys */
 /* u2 phy bank */
 #define SSUSB_SIFSLV_V1_U2PHY_COM  0x000
-/* u3/pcie phy banks */
+/* u3/pcie/sata phy banks */
 #define SSUSB_SIFSLV_V1_U3PHYD 0x000
 #define SSUSB_SIFSLV_V1_U3PHYA 0x200
 
@@ -199,6 +199,65 @@
 #define U3P_SR_COEF_DIVISOR1000
 #define U3P_FM_DET_CYCLE_CNT   1024
 
+/* SATA register setting */
+#define PHYD_CTRL_SIGNAL_MODE4 0x1c
+/* CDR Charge Pump P-path current adjustment */
+#define RG_CDR_BICLTD1_GEN1_MSKGENMASK(23, 20)
+#define RG_CDR_BICLTD1_GEN1_VAL(x) ((0xf & (x)) << 20)
+#define RG_CDR_BICLTD0_GEN1_MSKGENMASK(11, 8)
+#define RG_CDR_BICLTD0_GEN1_VAL(x) ((0xf & (x)) << 8)
+
+#define PHYD_DESIGN_OPTION20x24
+/* Symbol lock count selection */
+#define RG_LOCK_CNT_SEL_MSKGENMASK(5, 4)
+#define RG_LOCK_CNT_SEL_VAL(x) ((0x3 & (x)) << 4)
+
+#define PHYD_DESIGN_OPTION90x40
+/* COMWAK GAP width window */
+#define RG_TG_MAX_MSK  GENMASK(20, 16)
+#define RG_TG_MAX_VAL(x)   ((0x1f & (x)) << 16)
+/* COMINIT GAP width window */
+#define RG_T2_MAX_MSK  GENMASK(13, 8)
+#define RG_T2_MAX_VAL(x)   ((0x3f & (x)) << 8)
+/* COMWAK GAP width window */
+#define RG_TG_MIN_MSK  GENMASK(7, 5)
+#define RG_TG_MIN_VAL(x)   ((0x7 & (x)) << 5)
+/* COMINIT GAP width window */
+#define RG_T2_MIN_MSK  GENMASK(4, 0)
+#define RG_T2_MIN_VAL(x)   (0x1f & (x))
+
+#define ANA_RG_CTRL_SIGNAL10x4c
+/* TX driver tail current control for 0dB de-empahsis mdoe for Gen1 speed */
+#define RG_IDRV_0DB_GEN1_MSK   GENMASK(13, 8)
+#define RG_IDRV_0DB_GEN1_VAL(x)((0x3f & (x)) << 8)
+
+#define ANA_RG_CTRL_SIGNAL40x58
+#define RG_CDR_BICLTR_GEN1_MSK GENMASK(23, 20)
+#define RG_CDR_BICLTR_GEN1_VAL(x)  ((0xf & (x)) << 20)
+/* Loop filter R1 resistance adjustment for Gen1 speed */
+#define RG_CDR_BR_GEN2_MSK GENMASK(10, 8)
+#define RG_CDR_BR_GEN2_VAL(x)  ((0x7 & (x)) << 8)
+
+#define ANA_RG_CTRL_SIGNAL60x60
+/* I-path capacitance adjustment for Gen1 */
+#define RG_CDR_BC_GEN1_MSK GENMASK(28, 24)
+#define RG_CDR_BC_GEN1_VAL(x)  ((0x1f & (x)) << 24)
+#define RG_CDR_BIRLTR_GEN1_MSK GENMASK(4, 0)
+#define RG_CDR_BIRLTR_GEN1_VAL(x)  (0x1f & (x))
+
+#define ANA_EQ_EYE_CTRL_SIGNAL10x6c
+/* RX Gen1 LEQ tuning step */
+#define RG_EQ_DLEQ_LFI_GEN1_MSKGENMASK(11, 8)
+#define RG_EQ_DLEQ_LFI_GEN1_VAL(x) ((0xf & (x)) << 8)
+
+#define ANA_EQ_EYE_CTRL_SIGNAL40xd8
+#define RG_CDR_BIRLTD0_GEN1_MSKGENMASK(20, 16)
+#define RG_CDR_BIRLTD0_GEN1_VAL(x) ((0x1f & (x)) << 16)
+
+#define ANA_EQ_EYE_CTRL_SIGNAL50xdc
+#define RG_CDR_BIRLTD0_GEN3_MSKGENMASK(4, 0)
+#define RG_CDR_BIRLTD0_GEN3_VAL(x) (0x1f & (x))
+
 enum mt_phy_version {
MT_PHY_V1 = 1,
MT_PHY_V2,
@@ -630,6 +689,64 @@ static void pcie_phy_instance_power_off(struct 
mt65xx_u3phy *u3phy,
writel(tmp, bank->chip + U3P_U3_CHIP_GPIO_CTLE);
 }
 
+static void sata_phy_instance_init(struct mt65xx_u3phy *u3phy,
+  struct mt65xx_phy_instance *instance)
+{
+   struct u3phy_banks *u3_banks = >u3_banks;
+   void __iomem *phyd = u3_banks->phyd;
+   u32 tmp;
+
+   /* charge current adjustment */
+   tmp = readl(phyd + ANA_RG_CTRL_SIGNAL6);
+   tmp &= ~(RG_CDR_BIRLTR_GEN1_MSK | RG_CDR_BC_GEN1_MSK);
+   tmp |= RG_CDR_BIRLTR_GEN1_VAL(0x6) | RG_CDR_BC_GEN1_VAL(0x1a);
+   writel(tmp, phyd + ANA_RG_CTRL_SIGNAL6);
+
+   tmp = readl(phyd + ANA_EQ_EYE_CTRL_SIGNAL4);
+   tmp &= ~RG_CDR_BIRLTD0_GEN1_MSK;
+   tmp |= RG_CDR_BIRLTD0_GEN1_VAL(0x18);
+   writel(tmp, phyd + ANA_EQ_EYE_CTRL_SIGNAL4);
+
+   tmp = readl(phyd + ANA_EQ_EYE_CTRL_SIGNAL5);
+   tmp &= ~RG_CDR_BIRLTD0_GEN3_MSK;
+   tmp |= RG_CDR_BIRLTD0_GEN3_VAL(0x06);
+   writel(tmp, phyd + ANA_EQ_EYE_CTRL_SIGNAL5);
+
+   tmp = readl(phyd + ANA_RG_CTRL_SIGNAL4);
+   tmp &= ~(RG_CDR_BICLTR_GEN1_MSK | RG_CDR_BR_GEN2_MSK);
+   tmp |= RG_CDR_BICLTR_GEN1_VAL(0x0c) | RG_CDR_BR_GEN2_VAL(0x07);
+   writel(tmp, phyd + ANA_RG_CTRL_SIGNAL4);
+
+   tmp = readl(phyd + PHYD_CTRL_SIGNAL_MODE4);
+   tmp &= ~(RG_CDR_BICLTD0_GEN1_MSK | RG_CDR_BICLTD1_GEN1_MSK);
+   tmp |= RG_CDR_BICLTD0_GEN1_VAL(0x08) | RG_CDR_BICLTD1_GEN1_VAL(0x02);
+   writel(tmp, phyd + 

[PATCH v2 3/4] phy: phy-mt65xx-usb3: add mediatek directory and rename file

[Chunfeng Yun]

The driver is actually for T-PHY which supports USB3.0, PCIe and SATA,
and supports more SoCs now, but not just only for series of mt65xx SoCs,
so the name of file, data struct, functions etc with 'mt65xx' may cause
misunderstanding when new SoCs are supported. Here rename them to reflect
the real functions and also enhance readability.

And also update MAINTAINERS file to reflect the correct driver

Signed-off-by: Chunfeng Yun 
---
 MAINTAINERS|   2 +-
 drivers/phy/Kconfig|   9 +-
 drivers/phy/Makefile   |   2 +-
 drivers/phy/mediatek/Kconfig   |  14 ++
 drivers/phy/mediatek/Makefile  |   5 +
 .../{phy-mt65xx-usb3.c => mediatek/phy-mtk-tphy.c} | 273 ++---
 6 files changed, 158 insertions(+), 147 deletions(-)
 create mode 100644 drivers/phy/mediatek/Kconfig
 create mode 100644 drivers/phy/mediatek/Makefile
 rename drivers/phy/{phy-mt65xx-usb3.c => mediatek/phy-mtk-tphy.c} (81%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 205d397..428e5d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1599,7 +1599,7 @@ M:Chunfeng Yun 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 L: linux-media...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
-F: drivers/phy/phy-mt65xx-usb3.c
+F: drivers/phy/mediatek/phy-mtk-tphy.c
 
 ARM/MICREL KS8695 ARCHITECTURE
 M: Greg Ungerer 
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c1807d4..d16704e 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -26,14 +26,6 @@ config PHY_LPC18XX_USB_OTG
  This driver is need for USB0 support on LPC18xx/43xx and takes
  care of enabling and clock setup.
 
-config PHY_MT65XX_USB3
-   tristate "Mediatek USB3.0 PHY Driver"
-   depends on ARCH_MEDIATEK && OF
-   select GENERIC_PHY
-   help
- Say 'Y' here to add support for Mediatek USB3.0 PHY driver,
- it supports multiple usb2.0 and usb3.0 ports.
-
 config PHY_PISTACHIO_USB
tristate "IMG Pistachio USB2.0 PHY driver"
depends on MACH_PISTACHIO
@@ -53,6 +45,7 @@ source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/broadcom/Kconfig"
 source "drivers/phy/hisilicon/Kconfig"
 source "drivers/phy/marvell/Kconfig"
+source "drivers/phy/mediatek/Kconfig"
 source "drivers/phy/motorola/Kconfig"
 source "drivers/phy/qualcomm/Kconfig"
 source "drivers/phy/renesas/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f252201..1c68189 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,12 +4,12 @@
 
 obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
 obj-$(CONFIG_PHY_LPC18XX_USB_OTG)  += phy-lpc18xx-usb-otg.o
-obj-$(CONFIG_PHY_MT65XX_USB3)  += phy-mt65xx-usb3.o
 obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
 
 obj-$(CONFIG_ARCH_SUNXI)   += allwinner/
 obj-$(CONFIG_ARCH_MESON)   += amlogic/
+obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
 obj-$(CONFIG_ARCH_RENESAS) += renesas/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
new file mode 100644
index 000..be2a846
--- /dev/null
+++ b/drivers/phy/mediatek/Kconfig
@@ -0,0 +1,14 @@
+#
+# Phy drivers for MediaTek devices
+#
+config PHY_MTK_TPHY
+tristate "MediaTek T-PHY Driver"
+depends on ARCH_MEDIATEK && OF
+select GENERIC_PHY
+help
+  Enable this to add support for MediaTek T-PHY driver,
+  it supports physical layer functionality for usb2.0, usb3.0,
+  PCIe and SATA, and meanwhile supports two version T-PHY which
+  have different banks layout, the T-PHY with shared banks between
+  multi-ports is first version, otherwise is second veriosn,
+  so you can easily distinguish them by banks layout.
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
new file mode 100644
index 000..763a92e
--- /dev/null
+++ b/drivers/phy/mediatek/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/mediatek/phy-mtk-tphy.c
similarity index 81%
rename from drivers/phy/phy-mt65xx-usb3.c
rename to drivers/phy/mediatek/phy-mtk-tphy.c
index 5e9a415..1ca7fe3 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -38,7 +39,7 @@
 #define SSUSB_SIFSLV_V2_MISC   0x000
 #define SSUSB_SIFSLV_V2_U2FREQ 0x100
 #define SSUSB_SIFSLV_V2_U2PHY_COM  0x300
-/* u3 phy banks */
+/* u3/pcie/sata 

[PATCH v2 3/4] phy: phy-mt65xx-usb3: add mediatek directory and rename file

[Chunfeng Yun]

The driver is actually for T-PHY which supports USB3.0, PCIe and SATA,
and supports more SoCs now, but not just only for series of mt65xx SoCs,
so the name of file, data struct, functions etc with 'mt65xx' may cause
misunderstanding when new SoCs are supported. Here rename them to reflect
the real functions and also enhance readability.

And also update MAINTAINERS file to reflect the correct driver

Signed-off-by: Chunfeng Yun 
---
 MAINTAINERS|   2 +-
 drivers/phy/Kconfig|   9 +-
 drivers/phy/Makefile   |   2 +-
 drivers/phy/mediatek/Kconfig   |  14 ++
 drivers/phy/mediatek/Makefile  |   5 +
 .../{phy-mt65xx-usb3.c => mediatek/phy-mtk-tphy.c} | 273 ++---
 6 files changed, 158 insertions(+), 147 deletions(-)
 create mode 100644 drivers/phy/mediatek/Kconfig
 create mode 100644 drivers/phy/mediatek/Makefile
 rename drivers/phy/{phy-mt65xx-usb3.c => mediatek/phy-mtk-tphy.c} (81%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 205d397..428e5d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1599,7 +1599,7 @@ M:Chunfeng Yun 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 L: linux-media...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
-F: drivers/phy/phy-mt65xx-usb3.c
+F: drivers/phy/mediatek/phy-mtk-tphy.c
 
 ARM/MICREL KS8695 ARCHITECTURE
 M: Greg Ungerer 
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c1807d4..d16704e 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -26,14 +26,6 @@ config PHY_LPC18XX_USB_OTG
  This driver is need for USB0 support on LPC18xx/43xx and takes
  care of enabling and clock setup.
 
-config PHY_MT65XX_USB3
-   tristate "Mediatek USB3.0 PHY Driver"
-   depends on ARCH_MEDIATEK && OF
-   select GENERIC_PHY
-   help
- Say 'Y' here to add support for Mediatek USB3.0 PHY driver,
- it supports multiple usb2.0 and usb3.0 ports.
-
 config PHY_PISTACHIO_USB
tristate "IMG Pistachio USB2.0 PHY driver"
depends on MACH_PISTACHIO
@@ -53,6 +45,7 @@ source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/broadcom/Kconfig"
 source "drivers/phy/hisilicon/Kconfig"
 source "drivers/phy/marvell/Kconfig"
+source "drivers/phy/mediatek/Kconfig"
 source "drivers/phy/motorola/Kconfig"
 source "drivers/phy/qualcomm/Kconfig"
 source "drivers/phy/renesas/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f252201..1c68189 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,12 +4,12 @@
 
 obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
 obj-$(CONFIG_PHY_LPC18XX_USB_OTG)  += phy-lpc18xx-usb-otg.o
-obj-$(CONFIG_PHY_MT65XX_USB3)  += phy-mt65xx-usb3.o
 obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
 
 obj-$(CONFIG_ARCH_SUNXI)   += allwinner/
 obj-$(CONFIG_ARCH_MESON)   += amlogic/
+obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
 obj-$(CONFIG_ARCH_RENESAS) += renesas/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
new file mode 100644
index 000..be2a846
--- /dev/null
+++ b/drivers/phy/mediatek/Kconfig
@@ -0,0 +1,14 @@
+#
+# Phy drivers for MediaTek devices
+#
+config PHY_MTK_TPHY
+tristate "MediaTek T-PHY Driver"
+depends on ARCH_MEDIATEK && OF
+select GENERIC_PHY
+help
+  Enable this to add support for MediaTek T-PHY driver,
+  it supports physical layer functionality for usb2.0, usb3.0,
+  PCIe and SATA, and meanwhile supports two version T-PHY which
+  have different banks layout, the T-PHY with shared banks between
+  multi-ports is first version, otherwise is second veriosn,
+  so you can easily distinguish them by banks layout.
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
new file mode 100644
index 000..763a92e
--- /dev/null
+++ b/drivers/phy/mediatek/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/mediatek/phy-mtk-tphy.c
similarity index 81%
rename from drivers/phy/phy-mt65xx-usb3.c
rename to drivers/phy/mediatek/phy-mtk-tphy.c
index 5e9a415..1ca7fe3 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -38,7 +39,7 @@
 #define SSUSB_SIFSLV_V2_MISC   0x000
 #define SSUSB_SIFSLV_V2_U2FREQ 0x100
 #define SSUSB_SIFSLV_V2_U2PHY_COM  0x300
-/* u3 phy banks */
+/* u3/pcie/sata phy banks */
 #define SSUSB_SIFSLV_V2_SPLLC  0x000
 #define 

[PATCH v2 4/4] dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file

[Chunfeng Yun]

add support for PCIe and SATA, also add some new compatibles.

due to phy-mt65xx-usb.txt holds the bindings for all mediatek SoCs
with T-PHY controller, change the name to phy-mtk-tphy.txt to
reflect that.

Signed-off-by: Chunfeng Yun 
---
 .../phy/{phy-mt65xx-usb.txt => phy-mtk-tphy.txt}| 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)
 rename Documentation/devicetree/bindings/phy/{phy-mt65xx-usb.txt => 
phy-mtk-tphy.txt} (88%)

diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
similarity index 88%
rename from Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
rename to Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
index 0acc5a9..faf1808 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
@@ -1,13 +1,18 @@
-mt65xx USB3.0 PHY binding
+MediaTek T-PHY binding
 --
 
-This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
+T-phy controller supports physical layer functionality for a number of
+controllers on MediaTek SoCs, such as, USB2.0, USB3.0, PCIe, and SATA.
 
 Required properties (controller (parent) node):
  - compatible  : should be one of
- "mediatek,mt2701-u3phy"
- "mediatek,mt2712-u3phy"
- "mediatek,mt8173-u3phy"
+ "mediatek,generic-tphy-v1"
+ "mediatek,generic-tphy-v2"
+ "mediatek,mt2701-u3phy" (deprecated)
+ "mediatek,mt2712-u3phy" (deprecated)
+ "mediatek,mt8173-u3phy";
+ make use of "mediatek,generic-tphy-v1" on mt2701 instead and
+ "mediatek,generic-tphy-v2" on mt2712 instead.
  - clocks  : (deprecated, use port's clocks instead) a list of phandle +
  clock-specifier pairs, one for each entry in clock-names
  - clock-names : (deprecated, use port's one instead) must contain
@@ -35,6 +40,8 @@ Required properties (port (child) node):
  cell after port phandle is phy type from:
- PHY_TYPE_USB2
- PHY_TYPE_USB3
+   - PHY_TYPE_PCIE
+   - PHY_TYPE_SATA
 
 Example:
 
-- 
1.9.1

[PATCH v2 4/4] dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file

[Chunfeng Yun]

add support for PCIe and SATA, also add some new compatibles.

due to phy-mt65xx-usb.txt holds the bindings for all mediatek SoCs
with T-PHY controller, change the name to phy-mtk-tphy.txt to
reflect that.

Signed-off-by: Chunfeng Yun 
---
 .../phy/{phy-mt65xx-usb.txt => phy-mtk-tphy.txt}| 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)
 rename Documentation/devicetree/bindings/phy/{phy-mt65xx-usb.txt => 
phy-mtk-tphy.txt} (88%)

diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
similarity index 88%
rename from Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
rename to Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
index 0acc5a9..faf1808 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
@@ -1,13 +1,18 @@
-mt65xx USB3.0 PHY binding
+MediaTek T-PHY binding
 --
 
-This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
+T-phy controller supports physical layer functionality for a number of
+controllers on MediaTek SoCs, such as, USB2.0, USB3.0, PCIe, and SATA.
 
 Required properties (controller (parent) node):
  - compatible  : should be one of
- "mediatek,mt2701-u3phy"
- "mediatek,mt2712-u3phy"
- "mediatek,mt8173-u3phy"
+ "mediatek,generic-tphy-v1"
+ "mediatek,generic-tphy-v2"
+ "mediatek,mt2701-u3phy" (deprecated)
+ "mediatek,mt2712-u3phy" (deprecated)
+ "mediatek,mt8173-u3phy";
+ make use of "mediatek,generic-tphy-v1" on mt2701 instead and
+ "mediatek,generic-tphy-v2" on mt2712 instead.
  - clocks  : (deprecated, use port's clocks instead) a list of phandle +
  clock-specifier pairs, one for each entry in clock-names
  - clock-names : (deprecated, use port's one instead) must contain
@@ -35,6 +40,8 @@ Required properties (port (child) node):
  cell after port phandle is phy type from:
- PHY_TYPE_USB2
- PHY_TYPE_USB3
+   - PHY_TYPE_PCIE
+   - PHY_TYPE_SATA
 
 Example:
 
-- 
1.9.1

Re: [PATCH 2/2] PCI: iproc: Add optional brcm,pci-hotplug

[Ray Jui]

On 8/8/2017 10:22 PM, Oza Oza wrote:

On Tue, Aug 8, 2017 at 7:50 PM, Rob Herring  wrote:

Please send bindings to DT list.

Sure, will do that.


On Mon, Aug 7, 2017 at 11:44 PM, Oza Pawandeep  wrote:

Add description for optional device tree property
'brcm,pci-hotplug' for PCI hotplug feature.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 

diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt 
b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
index b8e48b4..a3bad24 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -72,6 +72,29 @@ Optional properties:
  - brcm,pcie-msi-inten: Needs to be present for some older iProc platforms that
  require the interrupt enable registers to be set explicitly to enable MSI

+Optional properties:
+- brcm,pci-hotplug: PCI hotplug feature is supported.

I think we should make this a common property. We already have
"ibm,slot-pluggable", so I'd propose "slot-pluggable".

There's also "hotpluggable" for memory nodes defined, so we could
reuse that here.


ok I will rename this to
brcm,slot-pluggable


How's brcm,slot-pluggable a common property? It's still brcm specific. 
Didn't Rob propose either "slot-pluggable" or "hotpluggable"?


And note it goes to the generic PCI binding instead iProc PCIe specific 
binding.

Re: [PATCH 2/2] PCI: iproc: Add optional brcm,pci-hotplug

[Ray Jui]

On 8/8/2017 10:22 PM, Oza Oza wrote:

On Tue, Aug 8, 2017 at 7:50 PM, Rob Herring  wrote:

Please send bindings to DT list.

Sure, will do that.


On Mon, Aug 7, 2017 at 11:44 PM, Oza Pawandeep  wrote:

Add description for optional device tree property
'brcm,pci-hotplug' for PCI hotplug feature.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 

diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt 
b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
index b8e48b4..a3bad24 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -72,6 +72,29 @@ Optional properties:
  - brcm,pcie-msi-inten: Needs to be present for some older iProc platforms that
  require the interrupt enable registers to be set explicitly to enable MSI

+Optional properties:
+- brcm,pci-hotplug: PCI hotplug feature is supported.

I think we should make this a common property. We already have
"ibm,slot-pluggable", so I'd propose "slot-pluggable".

There's also "hotpluggable" for memory nodes defined, so we could
reuse that here.


ok I will rename this to
brcm,slot-pluggable


How's brcm,slot-pluggable a common property? It's still brcm specific. 
Didn't Rob propose either "slot-pluggable" or "hotpluggable"?


And note it goes to the generic PCI binding instead iProc PCIe specific 
binding.

Re: [PATCH 2/2] PCI: iproc: Add optional brcm,pci-hotplug

[Oza Oza]

On Tue, Aug 8, 2017 at 7:50 PM, Rob Herring  wrote:
> Please send bindings to DT list.

Sure, will do that.

>
> On Mon, Aug 7, 2017 at 11:44 PM, Oza Pawandeep  wrote:
>> Add description for optional device tree property
>> 'brcm,pci-hotplug' for PCI hotplug feature.
>>
>> Signed-off-by: Oza Pawandeep 
>> Reviewed-by: Ray Jui 
>>
>> diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt 
>> b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> index b8e48b4..a3bad24 100644
>> --- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> @@ -72,6 +72,29 @@ Optional properties:
>>  - brcm,pcie-msi-inten: Needs to be present for some older iProc platforms 
>> that
>>  require the interrupt enable registers to be set explicitly to enable MSI
>>
>> +Optional properties:
>> +- brcm,pci-hotplug: PCI hotplug feature is supported.
>
> I think we should make this a common property. We already have
> "ibm,slot-pluggable", so I'd propose "slot-pluggable".
>
> There's also "hotpluggable" for memory nodes defined, so we could
> reuse that here.
>

ok I will rename this to
brcm,slot-pluggable

>> +
>> +If the brcm,pcie-hotplug property is present, the following properties 
>> become
>> +effective:
>> +
>> +- brcm,prsnt-gpio: Array of gpios, needs to be present if Hotplug is 
>> supported.
>
> prsnt-gpios

will take care.

>
>> +
>> +PCI hotplug implementation is SOC/Board specific, and also it depends on
>> +how add-in card is designed (e.g. how many present pins are implemented).
>> +
>> +If x8 card is connected, then it might be possible that all the
>> +3 present pins could go low, or at least one pin goes low.
>> +
>> +If x4 card is connected, then it might be possible that 2 present
>> +pins go low, or at least one pin goes low.
>> +
>> +Example:
>> +brcm,prsnt-gpio: < 32 1>, < 33 1>;
>> +This is x4 connector: monitoring max 2 present lines.
>> +brcm,prsnt-gpio: < 32 1>, < 33 1>, < 34 1>;
>> +This is x8 connector: monitoring max 3 present lines.
>> +
>>  Example:
>> pcie0: pcie@18012000 {
>> compatible = "brcm,iproc-pcie";
>> --
>> 1.9.1
>>

Re: [patch v2 1/2] drivers: jtag: Add JTAG core driver

[kbuild test robot]

Hi Oleksandr,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc4 next-20170808]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Oleksandr-Shamray/drivers-jtag-Add-JTAG-core-driver/20170809-100030
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from include/linux/jtag.h:14:0,
from drivers/jtag/jtag.c:13:
>> include/uapi/linux/jtag.h:14:19: fatal error: types.h: No such file or 
>> directory
#include 
  ^
   compilation terminated.

vim +14 include/uapi/linux/jtag.h

13  
  > 14  #include 
15  

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


.config.gz
Description: application/gzip

Re: [PATCH 2/2] PCI: iproc: Add optional brcm,pci-hotplug

[Oza Oza]

On Tue, Aug 8, 2017 at 7:50 PM, Rob Herring  wrote:
> Please send bindings to DT list.

Sure, will do that.

>
> On Mon, Aug 7, 2017 at 11:44 PM, Oza Pawandeep  wrote:
>> Add description for optional device tree property
>> 'brcm,pci-hotplug' for PCI hotplug feature.
>>
>> Signed-off-by: Oza Pawandeep 
>> Reviewed-by: Ray Jui 
>>
>> diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt 
>> b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> index b8e48b4..a3bad24 100644
>> --- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> @@ -72,6 +72,29 @@ Optional properties:
>>  - brcm,pcie-msi-inten: Needs to be present for some older iProc platforms 
>> that
>>  require the interrupt enable registers to be set explicitly to enable MSI
>>
>> +Optional properties:
>> +- brcm,pci-hotplug: PCI hotplug feature is supported.
>
> I think we should make this a common property. We already have
> "ibm,slot-pluggable", so I'd propose "slot-pluggable".
>
> There's also "hotpluggable" for memory nodes defined, so we could
> reuse that here.
>

ok I will rename this to
brcm,slot-pluggable

>> +
>> +If the brcm,pcie-hotplug property is present, the following properties 
>> become
>> +effective:
>> +
>> +- brcm,prsnt-gpio: Array of gpios, needs to be present if Hotplug is 
>> supported.
>
> prsnt-gpios

will take care.

>
>> +
>> +PCI hotplug implementation is SOC/Board specific, and also it depends on
>> +how add-in card is designed (e.g. how many present pins are implemented).
>> +
>> +If x8 card is connected, then it might be possible that all the
>> +3 present pins could go low, or at least one pin goes low.
>> +
>> +If x4 card is connected, then it might be possible that 2 present
>> +pins go low, or at least one pin goes low.
>> +
>> +Example:
>> +brcm,prsnt-gpio: < 32 1>, < 33 1>;
>> +This is x4 connector: monitoring max 2 present lines.
>> +brcm,prsnt-gpio: < 32 1>, < 33 1>, < 34 1>;
>> +This is x8 connector: monitoring max 3 present lines.
>> +
>>  Example:
>> pcie0: pcie@18012000 {
>> compatible = "brcm,iproc-pcie";
>> --
>> 1.9.1
>>

Re: [patch v2 1/2] drivers: jtag: Add JTAG core driver

[kbuild test robot]

Hi Oleksandr,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc4 next-20170808]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Oleksandr-Shamray/drivers-jtag-Add-JTAG-core-driver/20170809-100030
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from include/linux/jtag.h:14:0,
from drivers/jtag/jtag.c:13:
>> include/uapi/linux/jtag.h:14:19: fatal error: types.h: No such file or 
>> directory
#include 
  ^
   compilation terminated.

vim +14 include/uapi/linux/jtag.h

13  
  > 14  #include 
15  

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


.config.gz
Description: application/gzip

Re: [PATCH v4 02/19] crypto: ccm: use -EAGAIN for transient busy indication

[Gilad Ben-Yossef]

On Tue, Aug 8, 2017 at 6:24 PM, Gary R Hook  wrote:
> On 08/08/2017 07:03 AM, Gilad Ben-Yossef wrote:
>>
>> Replace -EBUSY with -EAGAIN when reporting transient busy
>> indication in the absence of backlog.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>
>
> Could we use "ccp" in the subject line, please?

Of course, sorry about the the typo.

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH v4 02/19] crypto: ccm: use -EAGAIN for transient busy indication

[Gilad Ben-Yossef]

On Tue, Aug 8, 2017 at 6:24 PM, Gary R Hook  wrote:
> On 08/08/2017 07:03 AM, Gilad Ben-Yossef wrote:
>>
>> Replace -EBUSY with -EAGAIN when reporting transient busy
>> indication in the absence of backlog.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>
>
> Could we use "ccp" in the subject line, please?

Of course, sorry about the the typo.

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH] modpost: simplify sec_name()

[Kees Cook]

On Tue, Aug 8, 2017 at 8:18 PM, Masahiro Yamada
 wrote:
> There is code duplication between sec_name() and sech_name().
> Simplify sec_name() by re-using sech_name().  Also, move them up
> to remove the forward declaration of sec_name().
>
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Kees Cook 

-Kees

> ---
>
>  scripts/mod/modpost.c | 27 +++
>  1 file changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 48397feb08fb..b920d186ad4a 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -261,7 +261,17 @@ static enum export export_no(const char *s)
> return export_unknown;
>  }
>
> -static const char *sec_name(struct elf_info *elf, int secindex);
> +static const char *sech_name(struct elf_info *elf, Elf_Shdr *sechdr)
> +{
> +   return (void *)elf->hdr +
> +   elf->sechdrs[elf->secindex_strings].sh_offset +
> +   sechdr->sh_name;
> +}
> +
> +static const char *sec_name(struct elf_info *elf, int secindex)
> +{
> +   return sech_name(elf, >sechdrs[secindex]);
> +}
>
>  #define strstarts(str, prefix) (strncmp(str, prefix, strlen(prefix)) == 0)
>
> @@ -775,21 +785,6 @@ static const char *sym_name(struct elf_info *elf, 
> Elf_Sym *sym)
> return "(unknown)";
>  }
>
> -static const char *sec_name(struct elf_info *elf, int secindex)
> -{
> -   Elf_Shdr *sechdrs = elf->sechdrs;
> -   return (void *)elf->hdr +
> -   elf->sechdrs[elf->secindex_strings].sh_offset +
> -   sechdrs[secindex].sh_name;
> -}
> -
> -static const char *sech_name(struct elf_info *elf, Elf_Shdr *sechdr)
> -{
> -   return (void *)elf->hdr +
> -   elf->sechdrs[elf->secindex_strings].sh_offset +
> -   sechdr->sh_name;
> -}
> -
>  /* The pattern is an array of simple patterns.
>   * "foo" will match an exact string equal to "foo"
>   * "*foo" will match a string that ends with "foo"
> --
> 2.7.4
>



-- 
Kees Cook
Pixel Security

Re: [PATCH] modpost: simplify sec_name()

[Kees Cook]

On Tue, Aug 8, 2017 at 8:18 PM, Masahiro Yamada
 wrote:
> There is code duplication between sec_name() and sech_name().
> Simplify sec_name() by re-using sech_name().  Also, move them up
> to remove the forward declaration of sec_name().
>
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Kees Cook 

-Kees

> ---
>
>  scripts/mod/modpost.c | 27 +++
>  1 file changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 48397feb08fb..b920d186ad4a 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -261,7 +261,17 @@ static enum export export_no(const char *s)
> return export_unknown;
>  }
>
> -static const char *sec_name(struct elf_info *elf, int secindex);
> +static const char *sech_name(struct elf_info *elf, Elf_Shdr *sechdr)
> +{
> +   return (void *)elf->hdr +
> +   elf->sechdrs[elf->secindex_strings].sh_offset +
> +   sechdr->sh_name;
> +}
> +
> +static const char *sec_name(struct elf_info *elf, int secindex)
> +{
> +   return sech_name(elf, >sechdrs[secindex]);
> +}
>
>  #define strstarts(str, prefix) (strncmp(str, prefix, strlen(prefix)) == 0)
>
> @@ -775,21 +785,6 @@ static const char *sym_name(struct elf_info *elf, 
> Elf_Sym *sym)
> return "(unknown)";
>  }
>
> -static const char *sec_name(struct elf_info *elf, int secindex)
> -{
> -   Elf_Shdr *sechdrs = elf->sechdrs;
> -   return (void *)elf->hdr +
> -   elf->sechdrs[elf->secindex_strings].sh_offset +
> -   sechdrs[secindex].sh_name;
> -}
> -
> -static const char *sech_name(struct elf_info *elf, Elf_Shdr *sechdr)
> -{
> -   return (void *)elf->hdr +
> -   elf->sechdrs[elf->secindex_strings].sh_offset +
> -   sechdr->sh_name;
> -}
> -
>  /* The pattern is an array of simple patterns.
>   * "foo" will match an exact string equal to "foo"
>   * "*foo" will match a string that ends with "foo"
> --
> 2.7.4
>



-- 
Kees Cook
Pixel Security

[PATCH] net: dsa: make dsa_switch_ops const

[Bhumika Goyal]

Make these structures const as they are only stored in the ops field of
a dsa_switch structure, which is const.
Done using Coccinelle.

Signed-off-by: Bhumika Goyal 
---
 drivers/net/dsa/dsa_loop.c | 2 +-
 drivers/net/dsa/lan9303-core.c | 2 +-
 drivers/net/dsa/mt7530.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index 76d6660..7819a9f 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -257,7 +257,7 @@ static int dsa_loop_port_vlan_del(struct dsa_switch *ds, 
int port,
return 0;
 }
 
-static struct dsa_switch_ops dsa_loop_driver = {
+static const struct dsa_switch_ops dsa_loop_driver = {
.get_tag_protocol   = dsa_loop_get_protocol,
.setup  = dsa_loop_setup,
.get_strings= dsa_loop_get_strings,
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 15befd1..f058f98 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -797,7 +797,7 @@ static void lan9303_port_disable(struct dsa_switch *ds, int 
port,
}
 }
 
-static struct dsa_switch_ops lan9303_switch_ops = {
+static const struct dsa_switch_ops lan9303_switch_ops = {
.get_tag_protocol = lan9303_get_tag_protocol,
.setup = lan9303_setup,
.get_strings = lan9303_get_strings,
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 1270071..7d8cf927 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -979,7 +979,7 @@ static void mt7530_adjust_link(struct dsa_switch *ds, int 
port,
return 0;
 }
 
-static struct dsa_switch_ops mt7530_switch_ops = {
+static const struct dsa_switch_ops mt7530_switch_ops = {
.get_tag_protocol   = mtk_get_tag_protocol,
.setup  = mt7530_setup,
.get_strings= mt7530_get_strings,
-- 
1.9.1

[PATCH] net: dsa: make dsa_switch_ops const

[Bhumika Goyal]

Make these structures const as they are only stored in the ops field of
a dsa_switch structure, which is const.
Done using Coccinelle.

Signed-off-by: Bhumika Goyal 
---
 drivers/net/dsa/dsa_loop.c | 2 +-
 drivers/net/dsa/lan9303-core.c | 2 +-
 drivers/net/dsa/mt7530.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index 76d6660..7819a9f 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -257,7 +257,7 @@ static int dsa_loop_port_vlan_del(struct dsa_switch *ds, 
int port,
return 0;
 }
 
-static struct dsa_switch_ops dsa_loop_driver = {
+static const struct dsa_switch_ops dsa_loop_driver = {
.get_tag_protocol   = dsa_loop_get_protocol,
.setup  = dsa_loop_setup,
.get_strings= dsa_loop_get_strings,
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 15befd1..f058f98 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -797,7 +797,7 @@ static void lan9303_port_disable(struct dsa_switch *ds, int 
port,
}
 }
 
-static struct dsa_switch_ops lan9303_switch_ops = {
+static const struct dsa_switch_ops lan9303_switch_ops = {
.get_tag_protocol = lan9303_get_tag_protocol,
.setup = lan9303_setup,
.get_strings = lan9303_get_strings,
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 1270071..7d8cf927 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -979,7 +979,7 @@ static void mt7530_adjust_link(struct dsa_switch *ds, int 
port,
return 0;
 }
 
-static struct dsa_switch_ops mt7530_switch_ops = {
+static const struct dsa_switch_ops mt7530_switch_ops = {
.get_tag_protocol   = mtk_get_tag_protocol,
.setup  = mt7530_setup,
.get_strings= mt7530_get_strings,
-- 
1.9.1

[BUG] resolver strangeness in 4.12

[Bob Tracy]

No idea where to begin tracking this down :-(.  After approximately six
days of uptime with a 4.12.0 kernel, the DNS resolver simply quits
working.  All query attempts come back with "no DNS servers can be
reached".  External hosts can still query the BIND server running on
the host with the non-functional resolver.

Restarting "named" has no effect.  Rebooting the machine restores
functionality.  So far, this is completely reproducible.

Everything worked fine with 4.11.0.  Going to try a 4.13-rc4 kernel.

--Bob

[BUG] resolver strangeness in 4.12

[Bob Tracy]

No idea where to begin tracking this down :-(.  After approximately six
days of uptime with a 4.12.0 kernel, the DNS resolver simply quits
working.  All query attempts come back with "no DNS servers can be
reached".  External hosts can still query the BIND server running on
the host with the non-functional resolver.

Restarting "named" has no effect.  Rebooting the machine restores
functionality.  So far, this is completely reproducible.

Everything worked fine with 4.11.0.  Going to try a 4.13-rc4 kernel.

--Bob

Re: [PATCH] acpi: apei: fix GHES estatus iteration

[Borislav Petkov]

On Wed, Aug 09, 2017 at 02:52:06AM +0200, Rafael J. Wysocki wrote:
> Actually I will if Boris ACKs these.

It's all on the TODO list for when I get back from vacation next week.
Unless Tony gets to them before me...

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH] acpi: apei: fix GHES estatus iteration

[Borislav Petkov]

On Wed, Aug 09, 2017 at 02:52:06AM +0200, Rafael J. Wysocki wrote:
> Actually I will if Boris ACKs these.

It's all on the TODO list for when I get back from vacation next week.
Unless Tony gets to them before me...

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

linux-next: manual merge of the rpmsg tree with the qcom tree

[Stephen Rothwell]

Hi Bjorn,

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

  drivers/soc/qcom/Kconfig

between commit:

  2a464815d326 ("soc: qcom: bring all qcom drivers into a submenu")

from the qcom tree and commit:

  c4d77d5fcd8b ("soc: qcom: GLINK SSR notifier")

from the rpmsg 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/soc/qcom/Kconfig
index 5f12657fc552,d0fc331972d2..
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@@ -1,8 -1,15 +1,17 @@@
  #
  # QCOM Soc drivers
  #
 +menu "Qualcomm SoC drivers"
 +
+ config QCOM_GLINK_SSR
+   tristate "Qualcomm Glink SSR driver"
+   depends on RPMSG
+   depends on QCOM_RPROC_COMMON
+   help
+ Say y here to enable GLINK SSR support. The GLINK SSR driver
+ implements the SSR protocol for notifying the remote processor about
+ neighboring subsystems going up or down.
+ 
  config QCOM_GSBI
  tristate "QCOM General Serial Bus Interface"
  depends on ARCH_QCOM

linux-next: manual merge of the rpmsg tree with the qcom tree

[Stephen Rothwell]

Hi Bjorn,

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

  drivers/soc/qcom/Kconfig

between commit:

  2a464815d326 ("soc: qcom: bring all qcom drivers into a submenu")

from the qcom tree and commit:

  c4d77d5fcd8b ("soc: qcom: GLINK SSR notifier")

from the rpmsg 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/soc/qcom/Kconfig
index 5f12657fc552,d0fc331972d2..
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@@ -1,8 -1,15 +1,17 @@@
  #
  # QCOM Soc drivers
  #
 +menu "Qualcomm SoC drivers"
 +
+ config QCOM_GLINK_SSR
+   tristate "Qualcomm Glink SSR driver"
+   depends on RPMSG
+   depends on QCOM_RPROC_COMMON
+   help
+ Say y here to enable GLINK SSR support. The GLINK SSR driver
+ implements the SSR protocol for notifying the remote processor about
+ neighboring subsystems going up or down.
+ 
  config QCOM_GSBI
  tristate "QCOM General Serial Bus Interface"
  depends on ARCH_QCOM

Re: [PATCH v1] crypto: caam - set hwrng quality level

[Herbert Xu]

On Thu, Aug 03, 2017 at 07:48:51AM +, Horia Geantă wrote:
>
> Right now it's configured as a DRBG.
> If I read correctly, it doesn't matter it's using the internal TRNG for
> (automated) seeding, it still shouldn't use hwrng.
> This means it's broken since the very beginning:
> e24f7c9e87d4 crypto: caam - hwrng support

Right.  If it can be switched over to a TRNG then we should do that.
Otherwise it should be converted over to use the crypto rng API.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v1] crypto: caam - set hwrng quality level

[Herbert Xu]

On Thu, Aug 03, 2017 at 07:48:51AM +, Horia Geantă wrote:
>
> Right now it's configured as a DRBG.
> If I read correctly, it doesn't matter it's using the internal TRNG for
> (automated) seeding, it still shouldn't use hwrng.
> This means it's broken since the very beginning:
> e24f7c9e87d4 crypto: caam - hwrng support

Right.  If it can be switched over to a TRNG then we should do that.
Otherwise it should be converted over to use the crypto rng API.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] cpufreq: Return 0 from ->fast_switch() on errors

[Viresh Kumar]

CPUFREQ_ENTRY_INVALID is a special symbol which is used to specify that
an entry in the cpufreq table is invalid. But using it outside of the
scope of the cpufreq table looks a bit incorrect.

We can represent an invalid frequency by writing it as 0 instead if we
need. Note that it is already done that way for the return value of the
->get() callback.

Lets do the same for ->fast_switch() and not use CPUFREQ_ENTRY_INVALID
outside of the scope of cpufreq table.

Also update the comment over cpufreq_driver_fast_switch() to clearly
mention what this returns.

None of the drivers return CPUFREQ_ENTRY_INVALID as of now from
->fast_switch() callback and so we don't need to update any of those.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c| 7 ---
 kernel/sched/cpufreq_schedutil.c | 2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b2cc98551fc3..9588e15da26b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1832,9 +1832,10 @@ EXPORT_SYMBOL(cpufreq_unregister_notifier);
  * twice in parallel for the same policy and that it will never be called in
  * parallel with either ->target() or ->target_index() for the same policy.
  *
- * If CPUFREQ_ENTRY_INVALID is returned by the driver's ->fast_switch()
- * callback to indicate an error condition, the hardware configuration must be
- * preserved.
+ * Returns the actual frequency set for the CPU.
+ *
+ * If 0 is returned by the driver's ->fast_switch() callback to indicate an
+ * error condition, the hardware configuration must be preserved.
  */
 unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
unsigned int target_freq)
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 5465bf221e8f..2e74c49776be 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -123,7 +123,7 @@ static void sugov_update_commit(struct sugov_policy 
*sg_policy, u64 time,
 
if (policy->fast_switch_enabled) {
next_freq = cpufreq_driver_fast_switch(policy, next_freq);
-   if (next_freq == CPUFREQ_ENTRY_INVALID)
+   if (!next_freq)
return;
 
policy->cur = next_freq;
-- 
2.13.0.71.gd7076ec9c9cb

[PATCH] cpufreq: Return 0 from ->fast_switch() on errors

[Viresh Kumar]

CPUFREQ_ENTRY_INVALID is a special symbol which is used to specify that
an entry in the cpufreq table is invalid. But using it outside of the
scope of the cpufreq table looks a bit incorrect.

We can represent an invalid frequency by writing it as 0 instead if we
need. Note that it is already done that way for the return value of the
->get() callback.

Lets do the same for ->fast_switch() and not use CPUFREQ_ENTRY_INVALID
outside of the scope of cpufreq table.

Also update the comment over cpufreq_driver_fast_switch() to clearly
mention what this returns.

None of the drivers return CPUFREQ_ENTRY_INVALID as of now from
->fast_switch() callback and so we don't need to update any of those.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c| 7 ---
 kernel/sched/cpufreq_schedutil.c | 2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b2cc98551fc3..9588e15da26b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1832,9 +1832,10 @@ EXPORT_SYMBOL(cpufreq_unregister_notifier);
  * twice in parallel for the same policy and that it will never be called in
  * parallel with either ->target() or ->target_index() for the same policy.
  *
- * If CPUFREQ_ENTRY_INVALID is returned by the driver's ->fast_switch()
- * callback to indicate an error condition, the hardware configuration must be
- * preserved.
+ * Returns the actual frequency set for the CPU.
+ *
+ * If 0 is returned by the driver's ->fast_switch() callback to indicate an
+ * error condition, the hardware configuration must be preserved.
  */
 unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
unsigned int target_freq)
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 5465bf221e8f..2e74c49776be 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -123,7 +123,7 @@ static void sugov_update_commit(struct sugov_policy 
*sg_policy, u64 time,
 
if (policy->fast_switch_enabled) {
next_freq = cpufreq_driver_fast_switch(policy, next_freq);
-   if (next_freq == CPUFREQ_ENTRY_INVALID)
+   if (!next_freq)
return;
 
policy->cur = next_freq;
-- 
2.13.0.71.gd7076ec9c9cb

[RFT v2] mfd: exynos-lpass: Handle return value of clk_prepare_enable

[Arvind Yadav]

clk_prepare_enable() can fail here and we must check its return value.
we must call pm_runtime_disable() and pm_runtime_set_suspended(),
If exynos_lpass_probe is not successful.

Signed-off-by: Arvind Yadav 
---
changes in v2:
 added regmap_exit(lpass->top) and blank line before return.

 drivers/mfd/exynos-lpass.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/exynos-lpass.c b/drivers/mfd/exynos-lpass.c
index ca829f8..1ab7210 100644
--- a/drivers/mfd/exynos-lpass.c
+++ b/drivers/mfd/exynos-lpass.c
@@ -73,9 +73,13 @@ static void exynos_lpass_core_sw_reset(struct exynos_lpass 
*lpass, int mask)
regmap_write(lpass->top, SFR_LPASS_CORE_SW_RESET, val);
 }
 
-static void exynos_lpass_enable(struct exynos_lpass *lpass)
+static int exynos_lpass_enable(struct exynos_lpass *lpass)
 {
-   clk_prepare_enable(lpass->sfr0_clk);
+   int ret;
+
+   ret = clk_prepare_enable(lpass->sfr0_clk);
+   if (ret)
+   return ret;
 
/* Unmask SFR, DMA and I2S interrupt */
regmap_write(lpass->top, SFR_LPASS_INTR_CA5_MASK,
@@ -87,6 +91,8 @@ static void exynos_lpass_enable(struct exynos_lpass *lpass)
exynos_lpass_core_sw_reset(lpass, LPASS_I2S_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_DMA_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_MEM_SW_RESET);
+
+   return 0;
 }
 
 static void exynos_lpass_disable(struct exynos_lpass *lpass)
@@ -112,6 +118,7 @@ static int exynos_lpass_probe(struct platform_device *pdev)
struct exynos_lpass *lpass;
void __iomem *base_top;
struct resource *res;
+   int ret;
 
lpass = devm_kzalloc(dev, sizeof(*lpass), GFP_KERNEL);
if (!lpass)
@@ -136,7 +143,13 @@ static int exynos_lpass_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, lpass);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
-   exynos_lpass_enable(lpass);
+   ret = exynos_lpass_enable(lpass);
+   if (ret) {
+   pm_runtime_disable(dev);
+   pm_runtime_set_suspended(dev);
+   regmap_exit(lpass->top);
+   return ret;
+   }
 
return devm_of_platform_populate(dev);
 }
@@ -167,9 +180,7 @@ static int __maybe_unused exynos_lpass_resume(struct device 
*dev)
 {
struct exynos_lpass *lpass = dev_get_drvdata(dev);
 
-   exynos_lpass_enable(lpass);
-
-   return 0;
+   return exynos_lpass_enable(lpass);
 }
 
 static const struct dev_pm_ops lpass_pm_ops = {
-- 
1.9.1

[RFT v2] mfd: exynos-lpass: Handle return value of clk_prepare_enable

[Arvind Yadav]

clk_prepare_enable() can fail here and we must check its return value.
we must call pm_runtime_disable() and pm_runtime_set_suspended(),
If exynos_lpass_probe is not successful.

Signed-off-by: Arvind Yadav 
---
changes in v2:
 added regmap_exit(lpass->top) and blank line before return.

 drivers/mfd/exynos-lpass.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/exynos-lpass.c b/drivers/mfd/exynos-lpass.c
index ca829f8..1ab7210 100644
--- a/drivers/mfd/exynos-lpass.c
+++ b/drivers/mfd/exynos-lpass.c
@@ -73,9 +73,13 @@ static void exynos_lpass_core_sw_reset(struct exynos_lpass 
*lpass, int mask)
regmap_write(lpass->top, SFR_LPASS_CORE_SW_RESET, val);
 }
 
-static void exynos_lpass_enable(struct exynos_lpass *lpass)
+static int exynos_lpass_enable(struct exynos_lpass *lpass)
 {
-   clk_prepare_enable(lpass->sfr0_clk);
+   int ret;
+
+   ret = clk_prepare_enable(lpass->sfr0_clk);
+   if (ret)
+   return ret;
 
/* Unmask SFR, DMA and I2S interrupt */
regmap_write(lpass->top, SFR_LPASS_INTR_CA5_MASK,
@@ -87,6 +91,8 @@ static void exynos_lpass_enable(struct exynos_lpass *lpass)
exynos_lpass_core_sw_reset(lpass, LPASS_I2S_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_DMA_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_MEM_SW_RESET);
+
+   return 0;
 }
 
 static void exynos_lpass_disable(struct exynos_lpass *lpass)
@@ -112,6 +118,7 @@ static int exynos_lpass_probe(struct platform_device *pdev)
struct exynos_lpass *lpass;
void __iomem *base_top;
struct resource *res;
+   int ret;
 
lpass = devm_kzalloc(dev, sizeof(*lpass), GFP_KERNEL);
if (!lpass)
@@ -136,7 +143,13 @@ static int exynos_lpass_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, lpass);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
-   exynos_lpass_enable(lpass);
+   ret = exynos_lpass_enable(lpass);
+   if (ret) {
+   pm_runtime_disable(dev);
+   pm_runtime_set_suspended(dev);
+   regmap_exit(lpass->top);
+   return ret;
+   }
 
return devm_of_platform_populate(dev);
 }
@@ -167,9 +180,7 @@ static int __maybe_unused exynos_lpass_resume(struct device 
*dev)
 {
struct exynos_lpass *lpass = dev_get_drvdata(dev);
 
-   exynos_lpass_enable(lpass);
-
-   return 0;
+   return exynos_lpass_enable(lpass);
 }
 
 static const struct dev_pm_ops lpass_pm_ops = {
-- 
1.9.1

Re: [PATCH] mfd: exynos-lpass: Handle return value of clk_prepare_enable

[Arvind Yadav]

Thanks :)


On Tuesday 08 August 2017 11:55 PM, Krzysztof Kozlowski wrote:

On Tue, Aug 08, 2017 at 05:20:55PM +0530, Arvind Yadav wrote:

clk_prepare_enable() can fail here and we must check its return value.
we must call pm_runtime_disable() and pm_runtime_set_suspended(),
If exynos_lpass_probe is not successful.

Signed-off-by: Arvind Yadav 

This is not a trivial change so please mark all such patches as RFT.
Submit checklist mentions testing in multiple steps and last time your
ASoC changes were not tested.

I will ask for RFT.



---
  drivers/mfd/exynos-lpass.c | 23 ---
  1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/exynos-lpass.c b/drivers/mfd/exynos-lpass.c
index ca829f8..c74ff62 100644
--- a/drivers/mfd/exynos-lpass.c
+++ b/drivers/mfd/exynos-lpass.c
@@ -73,9 +73,13 @@ static void exynos_lpass_core_sw_reset(struct exynos_lpass 
*lpass, int mask)
regmap_write(lpass->top, SFR_LPASS_CORE_SW_RESET, val);
  }
  
-static void exynos_lpass_enable(struct exynos_lpass *lpass)

+static int exynos_lpass_enable(struct exynos_lpass *lpass)
  {
-   clk_prepare_enable(lpass->sfr0_clk);
+   int ret;
+
+   ret = clk_prepare_enable(lpass->sfr0_clk);
+   if (ret)
+   return ret;
  
  	/* Unmask SFR, DMA and I2S interrupt */

regmap_write(lpass->top, SFR_LPASS_INTR_CA5_MASK,
@@ -87,6 +91,8 @@ static void exynos_lpass_enable(struct exynos_lpass *lpass)
exynos_lpass_core_sw_reset(lpass, LPASS_I2S_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_DMA_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_MEM_SW_RESET);
+
+   return 0;
  }
  
  static void exynos_lpass_disable(struct exynos_lpass *lpass)

@@ -112,6 +118,7 @@ static int exynos_lpass_probe(struct platform_device *pdev)
struct exynos_lpass *lpass;
void __iomem *base_top;
struct resource *res;
+   int ret;
  
  	lpass = devm_kzalloc(dev, sizeof(*lpass), GFP_KERNEL);

if (!lpass)
@@ -136,8 +143,12 @@ static int exynos_lpass_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, lpass);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
-   exynos_lpass_enable(lpass);
-
+   ret = exynos_lpass_enable(lpass);
+   if (ret) {
+   pm_runtime_disable(dev);
+   pm_runtime_set_suspended(dev);

You need also regmap_exit().


+   return ret;
+   }

Leave one blank line before return.

Best regards,
Krzysztof


~arvind

Re: [PATCH] mfd: exynos-lpass: Handle return value of clk_prepare_enable

[Arvind Yadav]

Thanks :)


On Tuesday 08 August 2017 11:55 PM, Krzysztof Kozlowski wrote:

On Tue, Aug 08, 2017 at 05:20:55PM +0530, Arvind Yadav wrote:

clk_prepare_enable() can fail here and we must check its return value.
we must call pm_runtime_disable() and pm_runtime_set_suspended(),
If exynos_lpass_probe is not successful.

Signed-off-by: Arvind Yadav 

This is not a trivial change so please mark all such patches as RFT.
Submit checklist mentions testing in multiple steps and last time your
ASoC changes were not tested.

I will ask for RFT.



---
  drivers/mfd/exynos-lpass.c | 23 ---
  1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/exynos-lpass.c b/drivers/mfd/exynos-lpass.c
index ca829f8..c74ff62 100644
--- a/drivers/mfd/exynos-lpass.c
+++ b/drivers/mfd/exynos-lpass.c
@@ -73,9 +73,13 @@ static void exynos_lpass_core_sw_reset(struct exynos_lpass 
*lpass, int mask)
regmap_write(lpass->top, SFR_LPASS_CORE_SW_RESET, val);
  }
  
-static void exynos_lpass_enable(struct exynos_lpass *lpass)

+static int exynos_lpass_enable(struct exynos_lpass *lpass)
  {
-   clk_prepare_enable(lpass->sfr0_clk);
+   int ret;
+
+   ret = clk_prepare_enable(lpass->sfr0_clk);
+   if (ret)
+   return ret;
  
  	/* Unmask SFR, DMA and I2S interrupt */

regmap_write(lpass->top, SFR_LPASS_INTR_CA5_MASK,
@@ -87,6 +91,8 @@ static void exynos_lpass_enable(struct exynos_lpass *lpass)
exynos_lpass_core_sw_reset(lpass, LPASS_I2S_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_DMA_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_MEM_SW_RESET);
+
+   return 0;
  }
  
  static void exynos_lpass_disable(struct exynos_lpass *lpass)

@@ -112,6 +118,7 @@ static int exynos_lpass_probe(struct platform_device *pdev)
struct exynos_lpass *lpass;
void __iomem *base_top;
struct resource *res;
+   int ret;
  
  	lpass = devm_kzalloc(dev, sizeof(*lpass), GFP_KERNEL);

if (!lpass)
@@ -136,8 +143,12 @@ static int exynos_lpass_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, lpass);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
-   exynos_lpass_enable(lpass);
-
+   ret = exynos_lpass_enable(lpass);
+   if (ret) {
+   pm_runtime_disable(dev);
+   pm_runtime_set_suspended(dev);

You need also regmap_exit().


+   return ret;
+   }

Leave one blank line before return.

Best regards,
Krzysztof


~arvind

Re: [PATCH net] Revert "vhost: cache used event for better performance"

[Michael S. Tsirkin]

On Wed, Aug 09, 2017 at 10:38:10AM +0800, Jason Wang wrote:
> I think don't think current code can work well if vq.num is grater than
> 2^15. Since all cached idx is u16. This looks like a bug which needs to be
> fixed.

That's a limitation of virtio 1.0.

> > * else if the interval of vq.num is [2^15, 2^16):
> > the logic in the original patch (809ecb9bca6a9) suffices
> > * else (= less than 2^15) (optional):
> > checking only (vring_need_event(vq->last_used_event, new + vq->num, new)
> > would suffice.
> > 
> > Am I missing something, or is this irrelevant?

Could you pls repost the suggestion copying virtio-dev mailing list
(subscriber only, sorry about that, but host/guest ABI discussions
need to copy that list)?

> Looks not, I think this may work. Let me do some test.
> 
> Thanks

I think that at this point it's prudent to add a feature bit
as the virtio spec does not require to never move the event index back.

Re: [PATCH net] Revert "vhost: cache used event for better performance"

[Michael S. Tsirkin]

On Wed, Aug 09, 2017 at 10:38:10AM +0800, Jason Wang wrote:
> I think don't think current code can work well if vq.num is grater than
> 2^15. Since all cached idx is u16. This looks like a bug which needs to be
> fixed.

That's a limitation of virtio 1.0.

> > * else if the interval of vq.num is [2^15, 2^16):
> > the logic in the original patch (809ecb9bca6a9) suffices
> > * else (= less than 2^15) (optional):
> > checking only (vring_need_event(vq->last_used_event, new + vq->num, new)
> > would suffice.
> > 
> > Am I missing something, or is this irrelevant?

Could you pls repost the suggestion copying virtio-dev mailing list
(subscriber only, sorry about that, but host/guest ABI discussions
need to copy that list)?

> Looks not, I think this may work. Let me do some test.
> 
> Thanks

I think that at this point it's prudent to add a feature bit
as the virtio spec does not require to never move the event index back.

Re: [RFC] hwmon: (ibmpowernv) Add support for reset-history sensors

[Guenter Roeck]

On 07/25/2017 10:55 PM, Shilpasri G Bhat wrote:

In P9, OCC allows for clearing the sensor min-max history. This patch
exports attribute to reset history when set will clear the history of
all the sensors owned by CSM and belonging to the chip.

Signed-off-by: Shilpasri G Bhat 
---
This patch is on top of this patchset:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1453891.html

This patch creates a non-standard attribute called as reset_historyX
which clears the lowest and highest of all the sensors like power,
temperature, voltage belonging to the chip.

  drivers/hwmon/ibmpowernv.c | 31 +++
  1 file changed, 31 insertions(+)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 5ccdd0b..611e472 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -51,6 +51,7 @@ enum sensors {
POWER_SUPPLY,
POWER_INPUT,
CURRENT,
+   RESET_HISTORY,
MAX_SENSOR_TYPE,
  };
  
@@ -78,6 +79,7 @@ enum sensors {

{ "in"},
{ "power" },
{ "curr"  },
+   { "reset_history" },
  };
  
  struct sensor_data {

@@ -126,6 +128,25 @@ static ssize_t show_label(struct device *dev, struct 
device_attribute *devattr,
return sprintf(buf, "%s\n", sdata->label);
  }
  
+static ssize_t store_reset_history(struct device *dev,

+  struct device_attribute *devattr,
+  const char *buf, size_t count)
+{
+   struct sensor_data *sdata = container_of(devattr, struct sensor_data,
+dev_attr);
+   int rc;
+   int reset;
+
+   rc = kstrtoint(buf, 0, );
+   if (rc)
+   return rc;
+
+   if (reset == 1)
+   rc = opal_sensor_groups_clear_history(sdata->id);
+


Which of course doesn't exist, so it is hard to determine if this is
all that is offered.

I'd rather stick with the existing ABI, which resets the history either
per sensor(inX_reset_history) or per group (in_reset_history).

Guenter


+   return rc ? rc : count;
+}
+
  static int __init get_logical_cpu(int hwcpu)
  {
int cpu;
@@ -458,6 +479,16 @@ static int create_device_attrs(struct platform_device 
*pdev)
  
  		create_hwmon_attr([count], attr_name, show_sensor);
  
+		if (type == RESET_HISTORY) {

+   snprintf(sdata[count].name, MAX_ATTR_LEN, "%s%d",
+sensor_groups[type].name,
+sdata[count].hwmon_index);
+
+   sdata[count].dev_attr.attr.mode = 0220;
+   sdata[count].dev_attr.store = store_reset_history;
+   sdata[count].dev_attr.show = NULL;
+   }
+
pgroups[type]->attrs[sensor_groups[type].attr_count++] =
[count++].dev_attr.attr;
  

Re: [RFC] hwmon: (ibmpowernv) Add support for reset-history sensors

[Guenter Roeck]

On 07/25/2017 10:55 PM, Shilpasri G Bhat wrote:

In P9, OCC allows for clearing the sensor min-max history. This patch
exports attribute to reset history when set will clear the history of
all the sensors owned by CSM and belonging to the chip.

Signed-off-by: Shilpasri G Bhat 
---
This patch is on top of this patchset:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1453891.html

This patch creates a non-standard attribute called as reset_historyX
which clears the lowest and highest of all the sensors like power,
temperature, voltage belonging to the chip.

  drivers/hwmon/ibmpowernv.c | 31 +++
  1 file changed, 31 insertions(+)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 5ccdd0b..611e472 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -51,6 +51,7 @@ enum sensors {
POWER_SUPPLY,
POWER_INPUT,
CURRENT,
+   RESET_HISTORY,
MAX_SENSOR_TYPE,
  };
  
@@ -78,6 +79,7 @@ enum sensors {

{ "in"},
{ "power" },
{ "curr"  },
+   { "reset_history" },
  };
  
  struct sensor_data {

@@ -126,6 +128,25 @@ static ssize_t show_label(struct device *dev, struct 
device_attribute *devattr,
return sprintf(buf, "%s\n", sdata->label);
  }
  
+static ssize_t store_reset_history(struct device *dev,

+  struct device_attribute *devattr,
+  const char *buf, size_t count)
+{
+   struct sensor_data *sdata = container_of(devattr, struct sensor_data,
+dev_attr);
+   int rc;
+   int reset;
+
+   rc = kstrtoint(buf, 0, );
+   if (rc)
+   return rc;
+
+   if (reset == 1)
+   rc = opal_sensor_groups_clear_history(sdata->id);
+


Which of course doesn't exist, so it is hard to determine if this is
all that is offered.

I'd rather stick with the existing ABI, which resets the history either
per sensor(inX_reset_history) or per group (in_reset_history).

Guenter


+   return rc ? rc : count;
+}
+
  static int __init get_logical_cpu(int hwcpu)
  {
int cpu;
@@ -458,6 +479,16 @@ static int create_device_attrs(struct platform_device 
*pdev)
  
  		create_hwmon_attr([count], attr_name, show_sensor);
  
+		if (type == RESET_HISTORY) {

+   snprintf(sdata[count].name, MAX_ATTR_LEN, "%s%d",
+sensor_groups[type].name,
+sdata[count].hwmon_index);
+
+   sdata[count].dev_attr.attr.mode = 0220;
+   sdata[count].dev_attr.store = store_reset_history;
+   sdata[count].dev_attr.show = NULL;
+   }
+
pgroups[type]->attrs[sensor_groups[type].attr_count++] =
[count++].dev_attr.attr;
  

Re: [PATCH v2 18/18] cpufreq: scmi: add support for fast frequency switching

[Viresh Kumar]

On 04-08-17, 15:31, Sudeep Holla wrote:
> The cpufreq core provides option for drivers to implement fast_switch
> callback which is invoked for frequency switching from interrupt context.
> 
> This patch adds support for fast_switch callback in SCMI cpufreq driver
> by making use of polling based SCMI transfer. It also sets the flag
> fast_switch_possible.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/cpufreq/scmi-cpufreq.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index 034359cafea5..cb1084cb1ef1 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -61,6 +61,19 @@ scmi_cpufreq_set_target(struct cpufreq_policy *policy, 
> unsigned int index)
>   return perf_ops->freq_set(priv->handle, priv->domain_id, freq, false);
>  }
>  
> +static unsigned int scmi_cpufreq_fast_switch(struct cpufreq_policy *policy,
> +  unsigned int target_freq)
> +{
> + struct scmi_data *priv = policy->driver_data;
> + struct scmi_perf_ops *perf_ops = priv->handle->perf_ops;
> +
> + if (!perf_ops->freq_set(priv->handle, priv->domain_id,
> + target_freq * 1000, true))
> + return target_freq;
> +
> + return CPUFREQ_ENTRY_INVALID;
> +}

This is very much similar to the target routine, perhaps we should write another
local routine which is used by both target and fast switch.

Do we guarantee that the frequency is changed by the time this routine returns?
Or we just send a SCMI request and return back ?

If we just send the request and don't wait for freq to get changed, what
protects another scmi_cpufreq_fast_switch() to get called before the first one
is finished? And what will happen on that call ?

>  static int
>  scmi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
>  {
> @@ -164,6 +177,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy 
> *policy)
>  
>   policy->cpuinfo.transition_latency = latency;
>  
> + policy->fast_switch_possible = true;
>   return 0;
>  
>  out_free_cpufreq_table:
> @@ -180,6 +194,7 @@ static int scmi_cpufreq_exit(struct cpufreq_policy 
> *policy)
>  {
>   struct scmi_data *priv = policy->driver_data;
>  
> + policy->fast_switch_possible = false;
>   cpufreq_cooling_unregister(priv->cdev);
>   dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
>   dev_pm_opp_cpumask_remove_table(policy->related_cpus);
> @@ -228,6 +243,7 @@ static struct cpufreq_driver scmi_cpufreq_driver = {
>   .init   = scmi_cpufreq_init,
>   .exit   = scmi_cpufreq_exit,
>   .ready  = scmi_cpufreq_ready,
> + .fast_switch= scmi_cpufreq_fast_switch,

Maybe add it right after target_index ?

-- 
viresh

Re: [PATCH v2 18/18] cpufreq: scmi: add support for fast frequency switching

[Viresh Kumar]

On 04-08-17, 15:31, Sudeep Holla wrote:
> The cpufreq core provides option for drivers to implement fast_switch
> callback which is invoked for frequency switching from interrupt context.
> 
> This patch adds support for fast_switch callback in SCMI cpufreq driver
> by making use of polling based SCMI transfer. It also sets the flag
> fast_switch_possible.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/cpufreq/scmi-cpufreq.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index 034359cafea5..cb1084cb1ef1 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -61,6 +61,19 @@ scmi_cpufreq_set_target(struct cpufreq_policy *policy, 
> unsigned int index)
>   return perf_ops->freq_set(priv->handle, priv->domain_id, freq, false);
>  }
>  
> +static unsigned int scmi_cpufreq_fast_switch(struct cpufreq_policy *policy,
> +  unsigned int target_freq)
> +{
> + struct scmi_data *priv = policy->driver_data;
> + struct scmi_perf_ops *perf_ops = priv->handle->perf_ops;
> +
> + if (!perf_ops->freq_set(priv->handle, priv->domain_id,
> + target_freq * 1000, true))
> + return target_freq;
> +
> + return CPUFREQ_ENTRY_INVALID;
> +}

This is very much similar to the target routine, perhaps we should write another
local routine which is used by both target and fast switch.

Do we guarantee that the frequency is changed by the time this routine returns?
Or we just send a SCMI request and return back ?

If we just send the request and don't wait for freq to get changed, what
protects another scmi_cpufreq_fast_switch() to get called before the first one
is finished? And what will happen on that call ?

>  static int
>  scmi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
>  {
> @@ -164,6 +177,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy 
> *policy)
>  
>   policy->cpuinfo.transition_latency = latency;
>  
> + policy->fast_switch_possible = true;
>   return 0;
>  
>  out_free_cpufreq_table:
> @@ -180,6 +194,7 @@ static int scmi_cpufreq_exit(struct cpufreq_policy 
> *policy)
>  {
>   struct scmi_data *priv = policy->driver_data;
>  
> + policy->fast_switch_possible = false;
>   cpufreq_cooling_unregister(priv->cdev);
>   dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
>   dev_pm_opp_cpumask_remove_table(policy->related_cpus);
> @@ -228,6 +243,7 @@ static struct cpufreq_driver scmi_cpufreq_driver = {
>   .init   = scmi_cpufreq_init,
>   .exit   = scmi_cpufreq_exit,
>   .ready  = scmi_cpufreq_ready,
> + .fast_switch= scmi_cpufreq_fast_switch,

Maybe add it right after target_index ?

-- 
viresh

Re: [v3, 1/2] hwmon: (it87) Split out chip registers setting code on probe path

[Guenter Roeck]

On Wed, Aug 02, 2017 at 01:06:23AM +0200, Maciej S. Szmigiero wrote:
> This commit splits out chip registers setting code on probe path to
> separate functions so they can be reused for setting the device properly
> again when system resumes from suspend.
> 
> While we are at it let's also make clear that on IT8720 and IT8782 it's
> the VCCH5V line that is (possibly) routed to in7.
> This will make it consistent with a similar message that it printed on
> IT8783.
> 
> Signed-off-by: Maciej S. Szmigiero 

I finally got to this and tried to apply it, but it fails spectacularly.
Even patch fails to apply each and every chunk. No idea what is going on.
How did you generate the patch, and what was your baseline ?

Guenter

> ---
> Changes from v1: Move code of common probe / resume steps to new functions
> so we don't need to make large parts of probe function conditional on a
> newly added 'resume' parameter.
> 
> Changes from v2: Code move of common probe / resume steps to new functions
> and actual resume functionality split into two, separate patches.
> 
> Made a message about VCCH5V being routed to in7 consistent across all
> chips.
> 
>   drivers/hwmon/it87.c | 138 
> ---
>   1 file changed, 88 insertions(+), 50 deletions(-)
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
> index 4dfc7238313e..818f123ac475 100644
> --- a/drivers/hwmon/it87.c
> +++ b/drivers/hwmon/it87.c
> @@ -2761,13 +2761,13 @@ static int __init it87_find(int sioaddr, unsigned 
> short *address,
>   uart6 = sio_data->type == it8782 && (reg & BIT(2));
>   
>   /*
> -  * The IT8720F has no VIN7 pin, so VCCH should always be
> +  * The IT8720F has no VIN7 pin, so VCCH5V should always be
>* routed internally to VIN7 with an internal divider.
>* Curiously, there still is a configuration bit to control
>* this, which means it can be set incorrectly. And even
>* more curiously, many boards out there are improperly
>* configured, even though the IT8720F datasheet claims
> -  * that the internal routing of VCCH to VIN7 is the default
> +  * that the internal routing of VCCH5V to VIN7 is the default
>* setting. So we force the internal routing in this case.
>*
>* On IT8782F, VIN7 is multiplexed with one of the UART6 pins.
> @@ -2777,7 +2777,7 @@ static int __init it87_find(int sioaddr, unsigned short 
> *address,
>   if ((sio_data->type == it8720 || uart6) && !(reg & BIT(1))) {
>   reg |= BIT(1);
>   superio_outb(sioaddr, IT87_SIO_PINX2_REG, reg);
> - pr_notice("Routing internal VCCH to in7\n");
> + pr_notice("Routing internal VCCH5V to in7\n");
>   }
>   if (reg & BIT(0))
>   sio_data->internal |= BIT(0);
> @@ -2828,13 +2828,89 @@ static int __init it87_find(int sioaddr, unsigned 
> short *address,
>   return err;
>   }
>   
> +/*
> + * Some chips seem to have default value 0xff for all limit
> + * registers. For low voltage limits it makes no sense and triggers
> + * alarms, so change to 0 instead. For high temperature limits, it
> + * means -1 degree C, which surprisingly doesn't trigger an alarm,
> + * but is still confusing, so change to 127 degrees C.
> + */
> +static void it87_check_limit_regs(struct it87_data *data)
> +{
> + int i, reg;
> +
> + for (i = 0; i < NUM_VIN_LIMIT; i++) {
> + reg = it87_read_value(data, IT87_REG_VIN_MIN(i));
> + if (reg == 0xff)
> + it87_write_value(data, IT87_REG_VIN_MIN(i), 0);
> + }
> + for (i = 0; i < NUM_TEMP_LIMIT; i++) {
> + reg = it87_read_value(data, IT87_REG_TEMP_HIGH(i));
> + if (reg == 0xff)
> + it87_write_value(data, IT87_REG_TEMP_HIGH(i), 127);
> + }
> +}
> +
> +/* Check if voltage monitors are reset manually or by some reason */
> +static void it87_check_voltage_monitors_reset(struct it87_data *data)
> +{
> + int reg;
> +
> + reg = it87_read_value(data, IT87_REG_VIN_ENABLE);
> + if ((reg & 0xff) == 0) {
> + /* Enable all voltage monitors */
> + it87_write_value(data, IT87_REG_VIN_ENABLE, 0xff);
> + }
> +}
> +
> +/* Check if tachometers are reset manually or by some reason */
> +static void it87_check_tachometers_reset(struct platform_device *pdev)
> +{
> + struct it87_sio_data *sio_data = dev_get_platdata(>dev);
> + struct it87_data *data = platform_get_drvdata(pdev);
> + u8 mask, fan_main_ctrl;
> +
> + mask = 

Re: [v3, 1/2] hwmon: (it87) Split out chip registers setting code on probe path

[Guenter Roeck]

On Wed, Aug 02, 2017 at 01:06:23AM +0200, Maciej S. Szmigiero wrote:
> This commit splits out chip registers setting code on probe path to
> separate functions so they can be reused for setting the device properly
> again when system resumes from suspend.
> 
> While we are at it let's also make clear that on IT8720 and IT8782 it's
> the VCCH5V line that is (possibly) routed to in7.
> This will make it consistent with a similar message that it printed on
> IT8783.
> 
> Signed-off-by: Maciej S. Szmigiero 

I finally got to this and tried to apply it, but it fails spectacularly.
Even patch fails to apply each and every chunk. No idea what is going on.
How did you generate the patch, and what was your baseline ?

Guenter

> ---
> Changes from v1: Move code of common probe / resume steps to new functions
> so we don't need to make large parts of probe function conditional on a
> newly added 'resume' parameter.
> 
> Changes from v2: Code move of common probe / resume steps to new functions
> and actual resume functionality split into two, separate patches.
> 
> Made a message about VCCH5V being routed to in7 consistent across all
> chips.
> 
>   drivers/hwmon/it87.c | 138 
> ---
>   1 file changed, 88 insertions(+), 50 deletions(-)
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
> index 4dfc7238313e..818f123ac475 100644
> --- a/drivers/hwmon/it87.c
> +++ b/drivers/hwmon/it87.c
> @@ -2761,13 +2761,13 @@ static int __init it87_find(int sioaddr, unsigned 
> short *address,
>   uart6 = sio_data->type == it8782 && (reg & BIT(2));
>   
>   /*
> -  * The IT8720F has no VIN7 pin, so VCCH should always be
> +  * The IT8720F has no VIN7 pin, so VCCH5V should always be
>* routed internally to VIN7 with an internal divider.
>* Curiously, there still is a configuration bit to control
>* this, which means it can be set incorrectly. And even
>* more curiously, many boards out there are improperly
>* configured, even though the IT8720F datasheet claims
> -  * that the internal routing of VCCH to VIN7 is the default
> +  * that the internal routing of VCCH5V to VIN7 is the default
>* setting. So we force the internal routing in this case.
>*
>* On IT8782F, VIN7 is multiplexed with one of the UART6 pins.
> @@ -2777,7 +2777,7 @@ static int __init it87_find(int sioaddr, unsigned short 
> *address,
>   if ((sio_data->type == it8720 || uart6) && !(reg & BIT(1))) {
>   reg |= BIT(1);
>   superio_outb(sioaddr, IT87_SIO_PINX2_REG, reg);
> - pr_notice("Routing internal VCCH to in7\n");
> + pr_notice("Routing internal VCCH5V to in7\n");
>   }
>   if (reg & BIT(0))
>   sio_data->internal |= BIT(0);
> @@ -2828,13 +2828,89 @@ static int __init it87_find(int sioaddr, unsigned 
> short *address,
>   return err;
>   }
>   
> +/*
> + * Some chips seem to have default value 0xff for all limit
> + * registers. For low voltage limits it makes no sense and triggers
> + * alarms, so change to 0 instead. For high temperature limits, it
> + * means -1 degree C, which surprisingly doesn't trigger an alarm,
> + * but is still confusing, so change to 127 degrees C.
> + */
> +static void it87_check_limit_regs(struct it87_data *data)
> +{
> + int i, reg;
> +
> + for (i = 0; i < NUM_VIN_LIMIT; i++) {
> + reg = it87_read_value(data, IT87_REG_VIN_MIN(i));
> + if (reg == 0xff)
> + it87_write_value(data, IT87_REG_VIN_MIN(i), 0);
> + }
> + for (i = 0; i < NUM_TEMP_LIMIT; i++) {
> + reg = it87_read_value(data, IT87_REG_TEMP_HIGH(i));
> + if (reg == 0xff)
> + it87_write_value(data, IT87_REG_TEMP_HIGH(i), 127);
> + }
> +}
> +
> +/* Check if voltage monitors are reset manually or by some reason */
> +static void it87_check_voltage_monitors_reset(struct it87_data *data)
> +{
> + int reg;
> +
> + reg = it87_read_value(data, IT87_REG_VIN_ENABLE);
> + if ((reg & 0xff) == 0) {
> + /* Enable all voltage monitors */
> + it87_write_value(data, IT87_REG_VIN_ENABLE, 0xff);
> + }
> +}
> +
> +/* Check if tachometers are reset manually or by some reason */
> +static void it87_check_tachometers_reset(struct platform_device *pdev)
> +{
> + struct it87_sio_data *sio_data = dev_get_platdata(>dev);
> + struct it87_data *data = platform_get_drvdata(pdev);
> + u8 mask, fan_main_ctrl;
> +
> + mask = 0x70 & ~(sio_data->skip_fan 

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

[Leizhen (ThunderTown)]

On 2017/8/9 11:24, Ganapatrao Kulkarni wrote:
> On Wed, Aug 9, 2017 at 7:12 AM, Leizhen (ThunderTown)
>  wrote:
>>
>>
>> On 2017/8/8 20:03, Ganapatrao Kulkarni wrote:
>>> On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown)
>>>  wrote:


 On 2017/7/26 19:08, Joerg Roedel wrote:
> Hi Robin.
>
> On Fri, Jul 21, 2017 at 12:41:57PM +0100, Robin Murphy wrote:
>> Hi all,
>>
>> In the wake of the ARM SMMU optimisation efforts, it seems that certain
>> workloads (e.g. storage I/O with large scatterlists) probably remain 
>> quite
>> heavily influenced by IOVA allocation performance. Separately, Ard also
>> reported massive performance drops for a graphical desktop on AMD Seattle
>> when enabling SMMUs via IORT, which we traced to dma_32bit_pfn in the DMA
>> ops domain getting initialised differently for ACPI vs. DT, and exposing
>> the overhead of the rbtree slow path. Whilst we could go around trying to
>> close up all the little gaps that lead to hitting the slowest case, it
>> seems a much better idea to simply make said slowest case a lot less 
>> slow.
>
> Do you have some numbers here? How big was the impact before these
> patches and how is it with the patches?
 Here are some numbers:

 (before)$ iperf -s
 
 Server listening on TCP port 5001
 TCP window size: 85.3 KByte (default)
 
 [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35898
 [ ID] Interval   Transfer Bandwidth
 [  4]  0.0-10.2 sec  7.88 MBytes  6.48 Mbits/sec
 [  5] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35900
 [  5]  0.0-10.3 sec  7.88 MBytes  6.43 Mbits/sec
 [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35902
 [  4]  0.0-10.3 sec  7.88 MBytes  6.43 Mbits/sec

 (after)$ iperf -s
 
 Server listening on TCP port 5001
 TCP window size: 85.3 KByte (default)
 
 [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36330
 [ ID] Interval   Transfer Bandwidth
 [  4]  0.0-10.0 sec  1.09 GBytes   933 Mbits/sec
 [  5] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36332
 [  5]  0.0-10.0 sec  1.10 GBytes   939 Mbits/sec
 [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36334
 [  4]  0.0-10.0 sec  1.10 GBytes   938 Mbits/sec

>>>
>>> Is this testing done on Host or on Guest/VM?
>> Host
> 
> As per your log, iperf throughput is improved to 938 Mbits/sec
> from  6.43 Mbits/sec.
> IMO, this seems to be unrealistic, some thing wrong with the testing?
For 64bits non-pci devices, the iova allocation is always searched from the 
last rb-tree node.
When many iovas allocated and keep a long time, the search process should check 
many rb nodes
then find a suitable free space. As my tracking, the average times exceeds 10K.
[free-space][free][used][...][used]
  ^ ^  ^
  | |  |-rb_last
  | |- maybe more than 10K allocated iova nodes
  |--- for 32bits devices, cached32_node remember the 
lastest freed node, which can help us reduce check times

This patch series add a new member "cached_node" to service for 64bits devices, 
like cached32_node service for 32bits devices.

> 
>>
>>>
>
>
>   Joerg
>
>
> .
>

 --
 Thanks!
 BestRegards


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>> thanks
>>> Ganapat
>>>
>>> .
>>>
>>
>> --
>> Thanks!
>> BestRegards
>>
> 
> thanks
> Ganapat
> 
> .
> 

-- 
Thanks!
BestRegards

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

[Leizhen (ThunderTown)]

On 2017/8/9 11:24, Ganapatrao Kulkarni wrote:
> On Wed, Aug 9, 2017 at 7:12 AM, Leizhen (ThunderTown)
>  wrote:
>>
>>
>> On 2017/8/8 20:03, Ganapatrao Kulkarni wrote:
>>> On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown)
>>>  wrote:


 On 2017/7/26 19:08, Joerg Roedel wrote:
> Hi Robin.
>
> On Fri, Jul 21, 2017 at 12:41:57PM +0100, Robin Murphy wrote:
>> Hi all,
>>
>> In the wake of the ARM SMMU optimisation efforts, it seems that certain
>> workloads (e.g. storage I/O with large scatterlists) probably remain 
>> quite
>> heavily influenced by IOVA allocation performance. Separately, Ard also
>> reported massive performance drops for a graphical desktop on AMD Seattle
>> when enabling SMMUs via IORT, which we traced to dma_32bit_pfn in the DMA
>> ops domain getting initialised differently for ACPI vs. DT, and exposing
>> the overhead of the rbtree slow path. Whilst we could go around trying to
>> close up all the little gaps that lead to hitting the slowest case, it
>> seems a much better idea to simply make said slowest case a lot less 
>> slow.
>
> Do you have some numbers here? How big was the impact before these
> patches and how is it with the patches?
 Here are some numbers:

 (before)$ iperf -s
 
 Server listening on TCP port 5001
 TCP window size: 85.3 KByte (default)
 
 [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35898
 [ ID] Interval   Transfer Bandwidth
 [  4]  0.0-10.2 sec  7.88 MBytes  6.48 Mbits/sec
 [  5] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35900
 [  5]  0.0-10.3 sec  7.88 MBytes  6.43 Mbits/sec
 [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35902
 [  4]  0.0-10.3 sec  7.88 MBytes  6.43 Mbits/sec

 (after)$ iperf -s
 
 Server listening on TCP port 5001
 TCP window size: 85.3 KByte (default)
 
 [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36330
 [ ID] Interval   Transfer Bandwidth
 [  4]  0.0-10.0 sec  1.09 GBytes   933 Mbits/sec
 [  5] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36332
 [  5]  0.0-10.0 sec  1.10 GBytes   939 Mbits/sec
 [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36334
 [  4]  0.0-10.0 sec  1.10 GBytes   938 Mbits/sec

>>>
>>> Is this testing done on Host or on Guest/VM?
>> Host
> 
> As per your log, iperf throughput is improved to 938 Mbits/sec
> from  6.43 Mbits/sec.
> IMO, this seems to be unrealistic, some thing wrong with the testing?
For 64bits non-pci devices, the iova allocation is always searched from the 
last rb-tree node.
When many iovas allocated and keep a long time, the search process should check 
many rb nodes
then find a suitable free space. As my tracking, the average times exceeds 10K.
[free-space][free][used][...][used]
  ^ ^  ^
  | |  |-rb_last
  | |- maybe more than 10K allocated iova nodes
  |--- for 32bits devices, cached32_node remember the 
lastest freed node, which can help us reduce check times

This patch series add a new member "cached_node" to service for 64bits devices, 
like cached32_node service for 32bits devices.

> 
>>
>>>
>
>
>   Joerg
>
>
> .
>

 --
 Thanks!
 BestRegards


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>> thanks
>>> Ganapat
>>>
>>> .
>>>
>>
>> --
>> Thanks!
>> BestRegards
>>
> 
> thanks
> Ganapat
> 
> .
> 

-- 
Thanks!
BestRegards

Re: [PATCH v2 17/18] cpufreq: add support for CPU DVFS based on SCMI message protocol

[Viresh Kumar]

On 04-08-17, 15:31, Sudeep Holla wrote:

I don't think its the Microsoft exchange server which screwed up tabs and
spaces, but you.

> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 2011fec2d6ad..c34633855bc7 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -215,6 +215,17 @@ config ARM_SA1100_CPUFREQ
>  config ARM_SA1110_CPUFREQ
>   bool
>  
> +config ARM_SCMI_CPUFREQ
> +tristate "SCMI based CPUfreq driver"

You have used spaces here instead of tab and at multiple other places, can you
please fix them all ?

> + depends on ARM_SCMI_PROTOCOL || COMPILE_TEST
> + select PM_OPP
> +help
> +   This adds the CPUfreq driver support for ARM platforms using SCMI
> +   protocol for CPU power management.
> +
> +   This driver uses SCMI Message Protocol driver to interact with the
> +   firmware providing the CPU DVFS functionality.
> +
>  config ARM_SCPI_CPUFREQ
>  tristate "SCPI based CPUfreq driver"
>   depends on ARM_BIG_LITTLE_CPUFREQ && ARM_SCPI_PROTOCOL && 
> COMMON_CLK_SCPI
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index ab3a42cd29ef..4810b45568d3 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_ARM_S3C64XX_CPUFREQ)   += s3c64xx-cpufreq.o
>  obj-$(CONFIG_ARM_S5PV210_CPUFREQ)+= s5pv210-cpufreq.o
>  obj-$(CONFIG_ARM_SA1100_CPUFREQ) += sa1100-cpufreq.o
>  obj-$(CONFIG_ARM_SA1110_CPUFREQ) += sa1110-cpufreq.o
> +obj-$(CONFIG_ARM_SCMI_CPUFREQ)   += scmi-cpufreq.o
>  obj-$(CONFIG_ARM_SCPI_CPUFREQ)   += scpi-cpufreq.o
>  obj-$(CONFIG_ARM_SPEAR_CPUFREQ)  += spear-cpufreq.o
>  obj-$(CONFIG_ARM_STI_CPUFREQ)+= sti-cpufreq.o
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> new file mode 100644
> index ..034359cafea5
> --- /dev/null
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -0,0 +1,268 @@
> +/*
> + * System Control and Power Interface (SCMI) based CPUFreq Interface driver
> + *
> + * Copyright (C) 2017 ARM Ltd.
> + * Sudeep Holla 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct scmi_data {
> + int domain_id;
> + struct device *cpu_dev;
> + struct thermal_cooling_device *cdev;
> + const struct scmi_handle *handle;

This stores the same handle pointer which is stored in the global variable
below. Right? Why keep a local variable here at all ?

> +};
> +
> +static const struct scmi_handle *handle;
> +
> +unsigned int scmi_cpufreq_get_rate(unsigned int cpu)
> +{
> + int ret;
> + unsigned long rate;
> + struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
> + struct scmi_data *priv = policy->driver_data;
> + struct scmi_perf_ops *perf_ops = priv->handle->perf_ops;

Normally people prefer to keep these definitions in decreasing order of their
lengths. i.e. ret and rate would be defined in the last line. Though I would
leave it to you to decide.

> +
> + ret = perf_ops->freq_get(priv->handle, priv->domain_id, , false);
> + if (ret)
> + return CPUFREQ_ENTRY_INVALID;

This is something special which is used only when we are returning indexes and
I am not sure if this will have benefit here. I will rather return 0 here.
That's what other drivers are doing.

> + return rate / 1000;
> +}
> +
> +static int
> +scmi_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index)
> +{
> + struct scmi_data *priv = policy->driver_data;
> + struct scmi_perf_ops *perf_ops = priv->handle->perf_ops;
> + u64 freq = policy->freq_table[index].frequency * 1000;
> +
> + return perf_ops->freq_set(priv->handle, priv->domain_id, freq, false);
> +}

I suppose any CPU can change the frequency of any other CPU here, right? You
must set policy->dvfs_possible_from_any_cpu = true, from ->init() then.

> +static int
> +scmi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
> +{
> + int cpu, domain, ret = 0;

You don't need to initialize ret here and I would rather name it tdomain or
something else. ret is a lot used to store error/success values, which isn't
your case.

> + struct device *tcpu_dev;
> +
> + domain = handle->perf_ops->device_domain_id(cpu_dev);
> + if (domain < 0)

Re: [PATCH v2 17/18] cpufreq: add support for CPU DVFS based on SCMI message protocol

[Viresh Kumar]

On 04-08-17, 15:31, Sudeep Holla wrote:

I don't think its the Microsoft exchange server which screwed up tabs and
spaces, but you.

> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 2011fec2d6ad..c34633855bc7 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -215,6 +215,17 @@ config ARM_SA1100_CPUFREQ
>  config ARM_SA1110_CPUFREQ
>   bool
>  
> +config ARM_SCMI_CPUFREQ
> +tristate "SCMI based CPUfreq driver"

You have used spaces here instead of tab and at multiple other places, can you
please fix them all ?

> + depends on ARM_SCMI_PROTOCOL || COMPILE_TEST
> + select PM_OPP
> +help
> +   This adds the CPUfreq driver support for ARM platforms using SCMI
> +   protocol for CPU power management.
> +
> +   This driver uses SCMI Message Protocol driver to interact with the
> +   firmware providing the CPU DVFS functionality.
> +
>  config ARM_SCPI_CPUFREQ
>  tristate "SCPI based CPUfreq driver"
>   depends on ARM_BIG_LITTLE_CPUFREQ && ARM_SCPI_PROTOCOL && 
> COMMON_CLK_SCPI
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index ab3a42cd29ef..4810b45568d3 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_ARM_S3C64XX_CPUFREQ)   += s3c64xx-cpufreq.o
>  obj-$(CONFIG_ARM_S5PV210_CPUFREQ)+= s5pv210-cpufreq.o
>  obj-$(CONFIG_ARM_SA1100_CPUFREQ) += sa1100-cpufreq.o
>  obj-$(CONFIG_ARM_SA1110_CPUFREQ) += sa1110-cpufreq.o
> +obj-$(CONFIG_ARM_SCMI_CPUFREQ)   += scmi-cpufreq.o
>  obj-$(CONFIG_ARM_SCPI_CPUFREQ)   += scpi-cpufreq.o
>  obj-$(CONFIG_ARM_SPEAR_CPUFREQ)  += spear-cpufreq.o
>  obj-$(CONFIG_ARM_STI_CPUFREQ)+= sti-cpufreq.o
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> new file mode 100644
> index ..034359cafea5
> --- /dev/null
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -0,0 +1,268 @@
> +/*
> + * System Control and Power Interface (SCMI) based CPUFreq Interface driver
> + *
> + * Copyright (C) 2017 ARM Ltd.
> + * Sudeep Holla 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct scmi_data {
> + int domain_id;
> + struct device *cpu_dev;
> + struct thermal_cooling_device *cdev;
> + const struct scmi_handle *handle;

This stores the same handle pointer which is stored in the global variable
below. Right? Why keep a local variable here at all ?

> +};
> +
> +static const struct scmi_handle *handle;
> +
> +unsigned int scmi_cpufreq_get_rate(unsigned int cpu)
> +{
> + int ret;
> + unsigned long rate;
> + struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
> + struct scmi_data *priv = policy->driver_data;
> + struct scmi_perf_ops *perf_ops = priv->handle->perf_ops;

Normally people prefer to keep these definitions in decreasing order of their
lengths. i.e. ret and rate would be defined in the last line. Though I would
leave it to you to decide.

> +
> + ret = perf_ops->freq_get(priv->handle, priv->domain_id, , false);
> + if (ret)
> + return CPUFREQ_ENTRY_INVALID;

This is something special which is used only when we are returning indexes and
I am not sure if this will have benefit here. I will rather return 0 here.
That's what other drivers are doing.

> + return rate / 1000;
> +}
> +
> +static int
> +scmi_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index)
> +{
> + struct scmi_data *priv = policy->driver_data;
> + struct scmi_perf_ops *perf_ops = priv->handle->perf_ops;
> + u64 freq = policy->freq_table[index].frequency * 1000;
> +
> + return perf_ops->freq_set(priv->handle, priv->domain_id, freq, false);
> +}

I suppose any CPU can change the frequency of any other CPU here, right? You
must set policy->dvfs_possible_from_any_cpu = true, from ->init() then.

> +static int
> +scmi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
> +{
> + int cpu, domain, ret = 0;

You don't need to initialize ret here and I would rather name it tdomain or
something else. ret is a lot used to store error/success values, which isn't
your case.

> + struct device *tcpu_dev;
> +
> + domain = handle->perf_ops->device_domain_id(cpu_dev);
> + if (domain < 0)
> + return 

Re: [v2] hwmon: adt7475: constify attribute_group structures

[Arvind Yadav]

yes, Sorry for noise. After rebase, it' was showing unchanged.


On Wednesday 09 August 2017 07:35 AM, Guenter Roeck wrote:

On Mon, Aug 07, 2017 at 03:06:29PM +0530, Arvind Yadav wrote:

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 

Kind of confused by this one. I applied a similar patch from you
back in July ??

Guenter


---
change in v2:
 subject was not correct. Removed 'wusbhc' and '.'.

  drivers/hwmon/adt7475.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index 1baa213..9ef8499 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -1319,14 +1319,14 @@ static SENSOR_DEVICE_ATTR_2(pwm3_stall_disable, S_IRUGO 
| S_IWUSR,
NULL
  };
  
-static struct attribute_group adt7475_attr_group = { .attrs = adt7475_attrs };

-static struct attribute_group fan4_attr_group = { .attrs = fan4_attrs };
-static struct attribute_group pwm2_attr_group = { .attrs = pwm2_attrs };
-static struct attribute_group in0_attr_group = { .attrs = in0_attrs };
-static struct attribute_group in3_attr_group = { .attrs = in3_attrs };
-static struct attribute_group in4_attr_group = { .attrs = in4_attrs };
-static struct attribute_group in5_attr_group = { .attrs = in5_attrs };
-static struct attribute_group vid_attr_group = { .attrs = vid_attrs };
+static const struct attribute_group adt7475_attr_group = { .attrs = 
adt7475_attrs };
+static const struct attribute_group fan4_attr_group = { .attrs = fan4_attrs };
+static const struct attribute_group pwm2_attr_group = { .attrs = pwm2_attrs };
+static const struct attribute_group in0_attr_group = { .attrs = in0_attrs };
+static const struct attribute_group in3_attr_group = { .attrs = in3_attrs };
+static const struct attribute_group in4_attr_group = { .attrs = in4_attrs };
+static const struct attribute_group in5_attr_group = { .attrs = in5_attrs };
+static const struct attribute_group vid_attr_group = { .attrs = vid_attrs };
  
  static int adt7475_detect(struct i2c_client *client,

  struct i2c_board_info *info)

~arvind

Re: [v2] hwmon: adt7475: constify attribute_group structures

[Arvind Yadav]

yes, Sorry for noise. After rebase, it' was showing unchanged.


On Wednesday 09 August 2017 07:35 AM, Guenter Roeck wrote:

On Mon, Aug 07, 2017 at 03:06:29PM +0530, Arvind Yadav wrote:

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 

Kind of confused by this one. I applied a similar patch from you
back in July ??

Guenter


---
change in v2:
 subject was not correct. Removed 'wusbhc' and '.'.

  drivers/hwmon/adt7475.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index 1baa213..9ef8499 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -1319,14 +1319,14 @@ static SENSOR_DEVICE_ATTR_2(pwm3_stall_disable, S_IRUGO 
| S_IWUSR,
NULL
  };
  
-static struct attribute_group adt7475_attr_group = { .attrs = adt7475_attrs };

-static struct attribute_group fan4_attr_group = { .attrs = fan4_attrs };
-static struct attribute_group pwm2_attr_group = { .attrs = pwm2_attrs };
-static struct attribute_group in0_attr_group = { .attrs = in0_attrs };
-static struct attribute_group in3_attr_group = { .attrs = in3_attrs };
-static struct attribute_group in4_attr_group = { .attrs = in4_attrs };
-static struct attribute_group in5_attr_group = { .attrs = in5_attrs };
-static struct attribute_group vid_attr_group = { .attrs = vid_attrs };
+static const struct attribute_group adt7475_attr_group = { .attrs = 
adt7475_attrs };
+static const struct attribute_group fan4_attr_group = { .attrs = fan4_attrs };
+static const struct attribute_group pwm2_attr_group = { .attrs = pwm2_attrs };
+static const struct attribute_group in0_attr_group = { .attrs = in0_attrs };
+static const struct attribute_group in3_attr_group = { .attrs = in3_attrs };
+static const struct attribute_group in4_attr_group = { .attrs = in4_attrs };
+static const struct attribute_group in5_attr_group = { .attrs = in5_attrs };
+static const struct attribute_group vid_attr_group = { .attrs = vid_attrs };
  
  static int adt7475_detect(struct i2c_client *client,

  struct i2c_board_info *info)

~arvind

Re: [PATCH 2/2] lib: add test for bitmap_parselist()

[kbuild test robot]

Hi Yury,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.13-rc4 next-20170808]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Yury-Norov/lib-make-bitmap_parselist-thread-safe-and-much-faster/20170809-105307
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   lib/test_bitmap.c:180:5: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
0xfffe, 0x, 0x};
^
   lib/test_bitmap.c:180:5: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
   lib/test_bitmap.c:181:1: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
static const unsigned long exp2[] = {0x, 
0x};
^
   lib/test_bitmap.c:181:1: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
   lib/test_bitmap.c: In function 'test_bitmap_parselist':
>> lib/test_bitmap.c:235:4: warning: format '%lu' expects argument of type 
>> 'long unsigned int', but argument 4 has type 'cycles_t' [-Wformat=]
   pr_err("test %d: input is '%s' OK, Time: %lu\n",
   ^

vim +235 lib/test_bitmap.c

   177  
   178  static const unsigned long exp[] = {1, 2, 0x, 0x, 
0x,
   179  0x, 0x, 0x, 
0x,
 > 180  0xfffe, 0x, 
 > 0x};
   181  static const unsigned long exp2[] = {0x, 
0x};
   182  
   183  static const struct test_bitmap_parselist parselist_tests[] __initconst 
= {
   184  {0, "0",[0], 8, 0},
   185  {0, "1",[1], 8, 0},
   186  {0, "0-15", [2], 32, 0},
   187  {0, "16-31",[3], 32, 0},
   188  {0, "0-31:1/2", [4], 32, 0},
   189  {0, "1-31:1/2", [5], 32, 0},
   190  {0, "0-31:1/4", [6], 32, 0},
   191  {0, "1-31:1/4", [7], 32, 0},
   192  {0, "0-31:4/4", [8], 32, 0},
   193  {0, "1-31:4/4", [9], 32, 0},
   194  {0, "0-31:1/4,32-63:2/4",   [10], 64, 0},
   195  {0, "0-31:3/4,32-63:4/4",   [11], 64, 0},
   196  
   197  {0, "0-31:1/4,32-63:2/4,64-95:3/4,96-127:4/4",  exp2, 128, 0},
   198  
   199  {0, "0-2047:128/256", NULL, 2048, PARSE_TIME},
   200  
   201  {-EINVAL, "-1", NULL, 8, 0},
   202  {-EINVAL, "-0", NULL, 8, 0},
   203  {-EINVAL, "10-1", NULL, 8, 0},
   204  {-EINVAL, "0-31:10/1", NULL, 8, 0},
   205  };
   206  
   207  static void __init test_bitmap_parselist(void)
   208  {
   209  int i;
   210  int err;
   211  cycles_t cycles;
   212  DECLARE_BITMAP(bmap, 2048);
   213  
   214  for (i = 0; i < ARRAY_SIZE(parselist_tests); i++) {
   215  #define ptest parselist_tests[i]
   216  
   217  cycles = get_cycles();
   218  err = bitmap_parselist(ptest.in, bmap, ptest.nbits);
   219  cycles = get_cycles() - cycles;
   220  
   221  if (err != ptest.errno) {
   222  pr_err("test %d: input is %s, errno is %d, 
expected %d\n",
   223  i, ptest.in, err, ptest.errno);
   224  continue;
   225  }
   226  
   227  if (!err && ptest.expected
   228   && !__bitmap_equal(bmap, ptest.expected, 
ptest.nbits)) {
   229  pr_err("test %d: input is %s, result is 0x%lx, 
expected 0x%lx\n",
   230  i, ptest.in, bmap[0], 
*ptest.expected);
   231  continue;
   232  }
   233  
   234  if (ptest.flags & PARSE_TIME)
 > 235  pr_err("test %d: input is '%s' OK, Time: %lu\n",
   236  i, ptest.in, cycles);
   237  }
   238  }
   239  

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


.config.gz
Description: application/gzip

Re: [PATCH 2/2] lib: add test for bitmap_parselist()

[kbuild test robot]

Hi Yury,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.13-rc4 next-20170808]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Yury-Norov/lib-make-bitmap_parselist-thread-safe-and-much-faster/20170809-105307
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   lib/test_bitmap.c:180:5: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
0xfffe, 0x, 0x};
^
   lib/test_bitmap.c:180:5: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
   lib/test_bitmap.c:181:1: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
static const unsigned long exp2[] = {0x, 
0x};
^
   lib/test_bitmap.c:181:1: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
   lib/test_bitmap.c: In function 'test_bitmap_parselist':
>> lib/test_bitmap.c:235:4: warning: format '%lu' expects argument of type 
>> 'long unsigned int', but argument 4 has type 'cycles_t' [-Wformat=]
   pr_err("test %d: input is '%s' OK, Time: %lu\n",
   ^

vim +235 lib/test_bitmap.c

   177  
   178  static const unsigned long exp[] = {1, 2, 0x, 0x, 
0x,
   179  0x, 0x, 0x, 
0x,
 > 180  0xfffe, 0x, 
 > 0x};
   181  static const unsigned long exp2[] = {0x, 
0x};
   182  
   183  static const struct test_bitmap_parselist parselist_tests[] __initconst 
= {
   184  {0, "0",[0], 8, 0},
   185  {0, "1",[1], 8, 0},
   186  {0, "0-15", [2], 32, 0},
   187  {0, "16-31",[3], 32, 0},
   188  {0, "0-31:1/2", [4], 32, 0},
   189  {0, "1-31:1/2", [5], 32, 0},
   190  {0, "0-31:1/4", [6], 32, 0},
   191  {0, "1-31:1/4", [7], 32, 0},
   192  {0, "0-31:4/4", [8], 32, 0},
   193  {0, "1-31:4/4", [9], 32, 0},
   194  {0, "0-31:1/4,32-63:2/4",   [10], 64, 0},
   195  {0, "0-31:3/4,32-63:4/4",   [11], 64, 0},
   196  
   197  {0, "0-31:1/4,32-63:2/4,64-95:3/4,96-127:4/4",  exp2, 128, 0},
   198  
   199  {0, "0-2047:128/256", NULL, 2048, PARSE_TIME},
   200  
   201  {-EINVAL, "-1", NULL, 8, 0},
   202  {-EINVAL, "-0", NULL, 8, 0},
   203  {-EINVAL, "10-1", NULL, 8, 0},
   204  {-EINVAL, "0-31:10/1", NULL, 8, 0},
   205  };
   206  
   207  static void __init test_bitmap_parselist(void)
   208  {
   209  int i;
   210  int err;
   211  cycles_t cycles;
   212  DECLARE_BITMAP(bmap, 2048);
   213  
   214  for (i = 0; i < ARRAY_SIZE(parselist_tests); i++) {
   215  #define ptest parselist_tests[i]
   216  
   217  cycles = get_cycles();
   218  err = bitmap_parselist(ptest.in, bmap, ptest.nbits);
   219  cycles = get_cycles() - cycles;
   220  
   221  if (err != ptest.errno) {
   222  pr_err("test %d: input is %s, errno is %d, 
expected %d\n",
   223  i, ptest.in, err, ptest.errno);
   224  continue;
   225  }
   226  
   227  if (!err && ptest.expected
   228   && !__bitmap_equal(bmap, ptest.expected, 
ptest.nbits)) {
   229  pr_err("test %d: input is %s, result is 0x%lx, 
expected 0x%lx\n",
   230  i, ptest.in, bmap[0], 
*ptest.expected);
   231  continue;
   232  }
   233  
   234  if (ptest.flags & PARSE_TIME)
 > 235  pr_err("test %d: input is '%s' OK, Time: %lu\n",
   236  i, ptest.in, cycles);
   237  }
   238  }
   239  

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


.config.gz
Description: application/gzip

Re: [PATCH] hv_set_ifconfig.sh double check before setting ip

[David Miller]

From: Eduardo Otubo 
Date: Tue,  8 Aug 2017 15:53:45 +0200

> This patch fixes the behavior of the hv_set_ifconfig script when setting
> the interface ip. Sometimes the interface has already been configured by
> network daemon, in this case hv_set_ifconfig causes "RTNETLINK: file
> exists error"; in order to avoid this error this patch makes sure double
> checks the interface before trying anything.
> 
> Signed-off-by: Eduardo Otubo 

And if the daemon sets the address after you test it but before
you try to set it in the script, what happens?

This is why I hate changes like this.  They don't remove the problem,
they make it smaller.  And smaller in a bad way.  Smaller makes the
problem even more harder to diagnose when it happens.

There is implicitly no synchonization between network configuration
daemons and things people run by hand like this script.

So, caveat emptor.

I'm not applying this, sorry.

Re: [PATCH] hv_set_ifconfig.sh double check before setting ip

[David Miller]

From: Eduardo Otubo 
Date: Tue,  8 Aug 2017 15:53:45 +0200

> This patch fixes the behavior of the hv_set_ifconfig script when setting
> the interface ip. Sometimes the interface has already been configured by
> network daemon, in this case hv_set_ifconfig causes "RTNETLINK: file
> exists error"; in order to avoid this error this patch makes sure double
> checks the interface before trying anything.
> 
> Signed-off-by: Eduardo Otubo 

And if the daemon sets the address after you test it but before
you try to set it in the script, what happens?

This is why I hate changes like this.  They don't remove the problem,
they make it smaller.  And smaller in a bad way.  Smaller makes the
problem even more harder to diagnose when it happens.

There is implicitly no synchonization between network configuration
daemons and things people run by hand like this script.

So, caveat emptor.

I'm not applying this, sorry.

Re: [PATCH 33/35] wireless: realtek: rtl8192cu: constify usb_device_id

[Larry Finger]

On 08/08/2017 11:05 AM, Arvind Yadav wrote:

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---


Acked-by: Larry Finger 

Thanks,

Larry


  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
index 96c923b..e673bc2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
@@ -275,7 +275,7 @@ static struct rtl_hal_cfg rtl92cu_hal_cfg = {
  #define USB_VENDER_ID_REALTEK 0x0bda
  
  /* 2010-10-19 DID_USB_V3.4 */

-static struct usb_device_id rtl8192c_usb_ids[] = {
+static const struct usb_device_id rtl8192c_usb_ids[] = {
  
  	/*=== Realtek demoboard ===*/

/* Default ID */

Re: [PATCH 33/35] wireless: realtek: rtl8192cu: constify usb_device_id

[Larry Finger]

On 08/08/2017 11:05 AM, Arvind Yadav wrote:

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---


Acked-by: Larry Finger 

Thanks,

Larry


  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
index 96c923b..e673bc2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
@@ -275,7 +275,7 @@ static struct rtl_hal_cfg rtl92cu_hal_cfg = {
  #define USB_VENDER_ID_REALTEK 0x0bda
  
  /* 2010-10-19 DID_USB_V3.4 */

-static struct usb_device_id rtl8192c_usb_ids[] = {
+static const struct usb_device_id rtl8192c_usb_ids[] = {
  
  	/*=== Realtek demoboard ===*/

/* Default ID */

Re: [PATCH][next] net: phy: mdio-bcm-unimac: fix unsigned wrap-around when decrementing timeout

[David Miller]

From: Colin King 
Date: Tue,  8 Aug 2017 10:52:32 +0100

> From: Colin Ian King 
> 
> Change post-decrement compare to pre-decrement to avoid an
> unsigned integer wrap-around on timeout. This leads to the following
> !timeout check to never to be true so -ETIMEDOUT is never returned.
> 
> Detected by CoverityScan, CID#1452623 ("Logically dead code")
> 
> Fixes: 69a60b0579a4 ("net: phy: mdio-bcm-unimac: factor busy polling loop")
> Signed-off-by: Colin Ian King 

Applied.

Re: [PATCH][next] net: phy: mdio-bcm-unimac: fix unsigned wrap-around when decrementing timeout

[David Miller]

From: Colin King 
Date: Tue,  8 Aug 2017 10:52:32 +0100

> From: Colin Ian King 
> 
> Change post-decrement compare to pre-decrement to avoid an
> unsigned integer wrap-around on timeout. This leads to the following
> !timeout check to never to be true so -ETIMEDOUT is never returned.
> 
> Detected by CoverityScan, CID#1452623 ("Logically dead code")
> 
> Fixes: 69a60b0579a4 ("net: phy: mdio-bcm-unimac: factor busy polling loop")
> Signed-off-by: Colin Ian King 

Applied.

[PATCH] parse-maintainers: Add ability to specify filenames

[Joe Perches]

parse-maintainers.pl is convenient, but currently hard-code the
filenames that are used.

Allow user-specified filenames to simplify the use of the script.

Miscellanea:

o Change the file permissions to 755 to the script is executable

Signed-off-by: Joe Perches 
---
 scripts/parse-maintainers.pl | 52 +++-
 1 file changed, 47 insertions(+), 5 deletions(-)
 mode change 100644 => 100755 scripts/parse-maintainers.pl

diff --git a/scripts/parse-maintainers.pl b/scripts/parse-maintainers.pl
old mode 100644
new mode 100755
index e40b53db7f9f..4499cefce348
--- a/scripts/parse-maintainers.pl
+++ b/scripts/parse-maintainers.pl
@@ -1,9 +1,44 @@
 #!/usr/bin/perl -w
 
 use strict;
+use Getopt::Long qw(:config no_auto_abbrev);
+
+my $input_file = "MAINTAINERS";
+my $output_file = "MAINTAINERS.new";
+my $output_section = "SECTION.new";
+my $help = 0;
 
 my $P = $0;
 
+if (!GetOptions(
+   'input=s' => \$input_file,
+   'output=s' => \$output_file,
+   'section=s' => \$output_section,
+   'h|help|usage' => \$help,
+   )) {
+die "$P: invalid argument - use --help if necessary\n";
+}
+
+if ($help != 0) {
+usage();
+exit 0;
+}
+
+sub usage {
+print < MAINTAINERS file to read (default: MAINTAINERS)
+  --output => sorted MAINTAINERS file to write (default: MAINTAINERS.new)
+  --section => new sorted MAINTAINERS file to write to (default: SECTION.new)
+
+If  exist, then the sections that match the
+regexes are not written to the output file but are written to the
+section file.
+
+EOT
+}
+
 # sort comparison functions
 sub by_category($$) {
 my ($a, $b) = @_;
@@ -55,13 +90,20 @@ sub trim {
 sub alpha_output {
 my ($hashref, $filename) = (@_);
 
+return if ! scalar(keys %$hashref);
+
 open(my $file, '>', "$filename") or die "$P: $filename: open failed - 
$!\n";
+my $separator;
 foreach my $key (sort by_category keys %$hashref) {
if ($key eq " ") {
-   chomp $$hashref{$key};
print $file $$hashref{$key};
} else {
-   print $file "\n" . $key . "\n";
+   if (! defined $separator) {
+   $separator = "\n";
+   } else {
+   print $file $separator;
+   }
+   print $file $key . "\n";
foreach my $pattern (sort by_pattern split('\n', %$hashref{$key})) {
print $file ($pattern . "\n");
}
@@ -111,7 +153,7 @@ sub file_input {
 my %hash;
 my %new_hash;
 
-file_input(\%hash, "MAINTAINERS");
+file_input(\%hash, $input_file);
 
 foreach my $type (@ARGV) {
 foreach my $key (keys %hash) {
@@ -122,7 +164,7 @@ foreach my $type (@ARGV) {
 }
 }
 
-alpha_output(\%hash, "MAINTAINERS.new");
-alpha_output(\%new_hash, "SECTION.new");
+alpha_output(\%hash, $output_file);
+alpha_output(\%new_hash, $output_section);
 
 exit(0);
-- 
2.10.0.rc2.1.g053435c

[PATCH] parse-maintainers: Add ability to specify filenames

[Joe Perches]

parse-maintainers.pl is convenient, but currently hard-code the
filenames that are used.

Allow user-specified filenames to simplify the use of the script.

Miscellanea:

o Change the file permissions to 755 to the script is executable

Signed-off-by: Joe Perches 
---
 scripts/parse-maintainers.pl | 52 +++-
 1 file changed, 47 insertions(+), 5 deletions(-)
 mode change 100644 => 100755 scripts/parse-maintainers.pl

diff --git a/scripts/parse-maintainers.pl b/scripts/parse-maintainers.pl
old mode 100644
new mode 100755
index e40b53db7f9f..4499cefce348
--- a/scripts/parse-maintainers.pl
+++ b/scripts/parse-maintainers.pl
@@ -1,9 +1,44 @@
 #!/usr/bin/perl -w
 
 use strict;
+use Getopt::Long qw(:config no_auto_abbrev);
+
+my $input_file = "MAINTAINERS";
+my $output_file = "MAINTAINERS.new";
+my $output_section = "SECTION.new";
+my $help = 0;
 
 my $P = $0;
 
+if (!GetOptions(
+   'input=s' => \$input_file,
+   'output=s' => \$output_file,
+   'section=s' => \$output_section,
+   'h|help|usage' => \$help,
+   )) {
+die "$P: invalid argument - use --help if necessary\n";
+}
+
+if ($help != 0) {
+usage();
+exit 0;
+}
+
+sub usage {
+print <
+
+  --input => MAINTAINERS file to read (default: MAINTAINERS)
+  --output => sorted MAINTAINERS file to write (default: MAINTAINERS.new)
+  --section => new sorted MAINTAINERS file to write to (default: SECTION.new)
+
+If  exist, then the sections that match the
+regexes are not written to the output file but are written to the
+section file.
+
+EOT
+}
+
 # sort comparison functions
 sub by_category($$) {
 my ($a, $b) = @_;
@@ -55,13 +90,20 @@ sub trim {
 sub alpha_output {
 my ($hashref, $filename) = (@_);
 
+return if ! scalar(keys %$hashref);
+
 open(my $file, '>', "$filename") or die "$P: $filename: open failed - 
$!\n";
+my $separator;
 foreach my $key (sort by_category keys %$hashref) {
if ($key eq " ") {
-   chomp $$hashref{$key};
print $file $$hashref{$key};
} else {
-   print $file "\n" . $key . "\n";
+   if (! defined $separator) {
+   $separator = "\n";
+   } else {
+   print $file $separator;
+   }
+   print $file $key . "\n";
foreach my $pattern (sort by_pattern split('\n', %$hashref{$key})) {
print $file ($pattern . "\n");
}
@@ -111,7 +153,7 @@ sub file_input {
 my %hash;
 my %new_hash;
 
-file_input(\%hash, "MAINTAINERS");
+file_input(\%hash, $input_file);
 
 foreach my $type (@ARGV) {
 foreach my $key (keys %hash) {
@@ -122,7 +164,7 @@ foreach my $type (@ARGV) {
 }
 }
 
-alpha_output(\%hash, "MAINTAINERS.new");
-alpha_output(\%new_hash, "SECTION.new");
+alpha_output(\%hash, $output_file);
+alpha_output(\%new_hash, $output_section);
 
 exit(0);
-- 
2.10.0.rc2.1.g053435c

Re: [PATCH] net: phy: Use tab for indentation in Kconfig

[David Miller]

From: Michal Simek 
Date: Tue,  8 Aug 2017 11:32:25 +0200

> Using tabs instead of space for indentaion
> 
> Signed-off-by: Michal Simek 

This really isn't appropriate for the 'net' tree, it doesn't fix
anything it just makes the spacing consistent.

Please respin this patch against net-next, thank you.

Re: [PATCH] net: phy: Use tab for indentation in Kconfig

[David Miller]

From: Michal Simek 
Date: Tue,  8 Aug 2017 11:32:25 +0200

> Using tabs instead of space for indentaion
> 
> Signed-off-by: Michal Simek 

This really isn't appropriate for the 'net' tree, it doesn't fix
anything it just makes the spacing consistent.

Please respin this patch against net-next, thank you.

Re: [PATCH net] rds: Reintroduce statistics counting

[David Miller]

From: Håkon Bugge 
Date: Tue,  8 Aug 2017 11:13:32 +0200

> In commit 7e3f2952eeb1 ("rds: don't let RDS shutdown a connection
> while senders are present"), refilling the receive queue was removed
> from rds_ib_recv(), along with the increment of
> s_ib_rx_refill_from_thread.
> 
> Commit 73ce4317bf98 ("RDS: make sure we post recv buffers")
> re-introduces filling the receive queue from rds_ib_recv(), but does
> not add the statistics counter. rds_ib_recv() was later renamed to
> rds_ib_recv_path().
> 
> This commit reintroduces the statistics counting of
> s_ib_rx_refill_from_thread and s_ib_rx_refill_from_cq.
> 
> Signed-off-by: Håkon Bugge 
> Reviewed-by: Knut Omang 
> Reviewed-by: Wei Lin Guay 

Applied.

Re: [PATCH net] rds: Reintroduce statistics counting

[David Miller]

From: Håkon Bugge 
Date: Tue,  8 Aug 2017 11:13:32 +0200

> In commit 7e3f2952eeb1 ("rds: don't let RDS shutdown a connection
> while senders are present"), refilling the receive queue was removed
> from rds_ib_recv(), along with the increment of
> s_ib_rx_refill_from_thread.
> 
> Commit 73ce4317bf98 ("RDS: make sure we post recv buffers")
> re-introduces filling the receive queue from rds_ib_recv(), but does
> not add the statistics counter. rds_ib_recv() was later renamed to
> rds_ib_recv_path().
> 
> This commit reintroduces the statistics counting of
> s_ib_rx_refill_from_thread and s_ib_rx_refill_from_cq.
> 
> Signed-off-by: Håkon Bugge 
> Reviewed-by: Knut Omang 
> Reviewed-by: Wei Lin Guay 

Applied.

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Masahiro Yamada]

Hi Marc,


2017-08-08 16:39 GMT+09:00 Marc Zyngier :
> On 08/08/17 02:30, Masahiro Yamada wrote:
>> Hi Marc,
>>
>> 2017-08-07 17:17 GMT+09:00 Marc Zyngier :
>>> On 07/08/17 05:45, Masahiro Yamada wrote:
 Hi Marc,


 2017-08-03 22:30 GMT+09:00 Marc Zyngier :
> On 03/08/17 13:52, Masahiro Yamada wrote:
>> Hi Marc,
>>
>> 2017-08-03 17:41 GMT+09:00 Marc Zyngier :
>>> Hi Masahiro,
>>>
>>> On 03/08/17 08:32, Masahiro Yamada wrote:
 Hi.

 2017-08-01 0:55 GMT+09:00 Thomas Gleixner :
> On Mon, 31 Jul 2017, Tomi Sarvela wrote:
>> On 31/07/17 18:06, Thomas Gleixner wrote:
>>> Can you please remove the patch. And try the following:
>>>
>>> # echo N > /sys/module/printk/parameters/console_suspend
>>>
>>> # echo mem > /sys/power/state
>>>
>>> and log the output of the serial console. That way we might get a 
>>> clue
>>> where it gets stuck.
>>
>> I'm afraid it hangs right away. No response from SSH, no output to 
>> serial.
>
> What means hangs right away? Is there no output at all on the serial
> console? Or does it just stop at some point?
>
> Thanks,
>
> tglx
>

 Sorry for jumping in.
 Finally, I found this thread.


 My environment is completely different (ARM64 board),
 I am also suffering from a hibernation problem
 since this commit.


 I get no response on the serial console
 after "Restarting tasks ... done." log message.


 By reverting bf22ff45bed6 ("genirq: Avoid unnecessary low level
 irq function calls", I can get hibernation working again.


 SW info:
 defconfig:  arch/arm64/configs/defconfig
 DT   :  arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
 PSCI :  ARM Trusted Firmware


 SoC info:
 CPU  :  Cortex-A72 * 2 + Cortex-A53 * 2
 irqchip  :  GICv3 (drivers/irq/irq-gic-v3.c)
>>>
>>> Let me take an educated guess: It feels like your firmware doesn't
>>> save/restore the GIC context across suspend/resume. Is that something
>>> you could check, assuming you have access to the firmware source code?
>>
>> Thanks for your comments.
>>
>>
>> I do not know much about the manner of preserving GICv3 context.
>>
>> I can see this patch  (rejected?) :
>> https://patchwork.kernel.org/patch/9343061/
>>
>>
>> Is it something that should be completely cared by firmware
>> instead of kernel?
>
> That was definitely the intention, but it looks like something that ATF
> has only started supporting very recently:
>
> https://github.com/ARM-software/arm-trusted-firmware/pull/1047
>
>> ARM Trusted Firmware 
>> (https://github.com/ARM-software/arm-trusted-firmware)
>> is open source software, and I pushed my platform code to the upstream.
>>
>> So, yes, I (and everybody) can have access to the firmware source code.
>>
>>
>> I am not sure how ATF saves the context during hibernation, though.
>
> See the above link. Is there any chance of you trying this into your
> firmware?
>
> Thanks,

 Thanks for the pointer.


 Yes.  I will try that once GIC-v3 context save/restore is supported in ATF.

 I think that will basically work for suspend-to-ram
 because all contexts including both non-secure and secure worlds will
 be retained in the main memory.

 However, I still do not understand how the context is preserved during
 the hibernation (suspend-to-disk).


 If my understanding is correct, hibernation on Linux works like follows:

 [1] Freeze all tasks
 [2] CPU_OFF for non-boot CPUs
 [3] Create a hibernation image
 [4] CPU_ON for non-boot CPUs
 [5] Write the hibernation image to the disk (=swap area)
 [6] SYSTEM_OFF


 IIUC, [5] only writes the context Linux takes care of (only non-secure).

 If so, where and how does the firmware write the GIC-v3 context
 to the disk?
>>>
>>> Gah, I completely missed the fact that you were talking about suspend to
>>> disk, sorry about that.
>>>
>>> It is likely that some driver doesn't restore its state properly. Is
>>> there any chance that you could pinpoint which device creates the issue?
>>>
>>
>> I use eMMC to store the hibernation image, but
>> I do not think eMMC driver is the cause of the issue.
>>
>> I guess the cause of the issue is GIC-v3 context is lost.
>
> It is not lost. The boot kernel has re-initialized its state. What is
> missing is that one driver 

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

[Masahiro Yamada]

Hi Marc,


2017-08-08 16:39 GMT+09:00 Marc Zyngier :
> On 08/08/17 02:30, Masahiro Yamada wrote:
>> Hi Marc,
>>
>> 2017-08-07 17:17 GMT+09:00 Marc Zyngier :
>>> On 07/08/17 05:45, Masahiro Yamada wrote:
 Hi Marc,


 2017-08-03 22:30 GMT+09:00 Marc Zyngier :
> On 03/08/17 13:52, Masahiro Yamada wrote:
>> Hi Marc,
>>
>> 2017-08-03 17:41 GMT+09:00 Marc Zyngier :
>>> Hi Masahiro,
>>>
>>> On 03/08/17 08:32, Masahiro Yamada wrote:
 Hi.

 2017-08-01 0:55 GMT+09:00 Thomas Gleixner :
> On Mon, 31 Jul 2017, Tomi Sarvela wrote:
>> On 31/07/17 18:06, Thomas Gleixner wrote:
>>> Can you please remove the patch. And try the following:
>>>
>>> # echo N > /sys/module/printk/parameters/console_suspend
>>>
>>> # echo mem > /sys/power/state
>>>
>>> and log the output of the serial console. That way we might get a 
>>> clue
>>> where it gets stuck.
>>
>> I'm afraid it hangs right away. No response from SSH, no output to 
>> serial.
>
> What means hangs right away? Is there no output at all on the serial
> console? Or does it just stop at some point?
>
> Thanks,
>
> tglx
>

 Sorry for jumping in.
 Finally, I found this thread.


 My environment is completely different (ARM64 board),
 I am also suffering from a hibernation problem
 since this commit.


 I get no response on the serial console
 after "Restarting tasks ... done." log message.


 By reverting bf22ff45bed6 ("genirq: Avoid unnecessary low level
 irq function calls", I can get hibernation working again.


 SW info:
 defconfig:  arch/arm64/configs/defconfig
 DT   :  arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
 PSCI :  ARM Trusted Firmware


 SoC info:
 CPU  :  Cortex-A72 * 2 + Cortex-A53 * 2
 irqchip  :  GICv3 (drivers/irq/irq-gic-v3.c)
>>>
>>> Let me take an educated guess: It feels like your firmware doesn't
>>> save/restore the GIC context across suspend/resume. Is that something
>>> you could check, assuming you have access to the firmware source code?
>>
>> Thanks for your comments.
>>
>>
>> I do not know much about the manner of preserving GICv3 context.
>>
>> I can see this patch  (rejected?) :
>> https://patchwork.kernel.org/patch/9343061/
>>
>>
>> Is it something that should be completely cared by firmware
>> instead of kernel?
>
> That was definitely the intention, but it looks like something that ATF
> has only started supporting very recently:
>
> https://github.com/ARM-software/arm-trusted-firmware/pull/1047
>
>> ARM Trusted Firmware 
>> (https://github.com/ARM-software/arm-trusted-firmware)
>> is open source software, and I pushed my platform code to the upstream.
>>
>> So, yes, I (and everybody) can have access to the firmware source code.
>>
>>
>> I am not sure how ATF saves the context during hibernation, though.
>
> See the above link. Is there any chance of you trying this into your
> firmware?
>
> Thanks,

 Thanks for the pointer.


 Yes.  I will try that once GIC-v3 context save/restore is supported in ATF.

 I think that will basically work for suspend-to-ram
 because all contexts including both non-secure and secure worlds will
 be retained in the main memory.

 However, I still do not understand how the context is preserved during
 the hibernation (suspend-to-disk).


 If my understanding is correct, hibernation on Linux works like follows:

 [1] Freeze all tasks
 [2] CPU_OFF for non-boot CPUs
 [3] Create a hibernation image
 [4] CPU_ON for non-boot CPUs
 [5] Write the hibernation image to the disk (=swap area)
 [6] SYSTEM_OFF


 IIUC, [5] only writes the context Linux takes care of (only non-secure).

 If so, where and how does the firmware write the GIC-v3 context
 to the disk?
>>>
>>> Gah, I completely missed the fact that you were talking about suspend to
>>> disk, sorry about that.
>>>
>>> It is likely that some driver doesn't restore its state properly. Is
>>> there any chance that you could pinpoint which device creates the issue?
>>>
>>
>> I use eMMC to store the hibernation image, but
>> I do not think eMMC driver is the cause of the issue.
>>
>> I guess the cause of the issue is GIC-v3 context is lost.
>
> It is not lost. The boot kernel has re-initialized its state. What is
> missing is that one driver in your system fails to restore its own state
> correctly, and relies on doing something such as 

Re: [PATCH v9 2/2] mmc: dw_mmc-k3: add sd support for hi3660

[Shawn Lin]

On 2017/8/9 11:25, Li Wei wrote:

Add sd card support for hi3660 soc

Signed-off-by: Li Wei 
Signed-off-by: Chen Jun 



I did some comment for your v6 but probably you miss them.

And it's still incorrect for your changelog.


--
Major changes in v3:
  - solve review comments from Heiner Kallweit.
*use the GENMASK and FIELD_PREP macros replace the bit shift operation.
*use usleep_range() replace udelay() and mdelay().

Major changes in v4:
  - solve review comments from Jaehoon Chung.
*move common register for dwmmc controller to dwmmc header file.
*modify definitions type of some register variables.
*get rid of the magic numbers.

Major changes in v5:
  - further improve coding style.

Major changes in v6:
  - solve review comments for Jaehoon Chung.
*modify dw_mci_hi3660_set_ios() to static.
*fix the comment style.

Major changes in v7:
  - solve review comments for John Stultz.
*remove reset code in dw_mmc-k3.c,use reset in core mmc.

Major changes in v8:
  - modify patch v7 name and dependency order.

Major changes in v9:
  - solve review comments for Ulf Hansson.
*use mmc_regulator_set_vqmmc() instead of regulator_set_voltage().
---


should be here...


  drivers/mmc/host/dw_mmc-k3.c | 301 +++
  drivers/mmc/host/dw_mmc.h|   2 +
  2 files changed, 303 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
index e38fb0020bb1..f6910bed55ef 100644
--- a/drivers/mmc/host/dw_mmc-k3.c
+++ b/drivers/mmc/host/dw_mmc-k3.c
@@ -8,6 +8,8 @@
   * (at your option) any later version.
   */
  
+#include 

+#include 
  #include 
  #include 
  #include 
@@ -28,7 +30,38 @@
  #define AO_SCTRL_SEL18BIT(10)
  #define AO_SCTRL_CTRL30x40C
  
+#define DWMMC_SDIO_ID 2

+
+#define SOC_SCTRL_SCPERCTRL5(0x314)
+#define SDCARD_IO_SEL18 BIT(2)
+
+#define SDCARD_RD_THRESHOLD  (512)
+
+#define GENCLK_DIV (7)
+
+#define GPIO_CLK_ENABLE   BIT(16)
+#define GPIO_CLK_DIV_MASK GENMASK(11, 8)
+#define GPIO_USE_SAMPLE_DLY_MASK  GENMASK(13, 13)
+#define UHS_REG_EXT_SAMPLE_PHASE_MASK GENMASK(20, 16)
+#define UHS_REG_EXT_SAMPLE_DRVPHASE_MASK  GENMASK(25, 21)
+#define UHS_REG_EXT_SAMPLE_DLY_MASK   GENMASK(30, 26)
+
+#define TIMING_MODE 3
+#define TIMING_CFG_NUM 10
+
+#define PULL_DOWN BIT(1)
+#define PULL_UP   BIT(0)
+
+#define NUM_PHASES (40)
+
+#define ENABLE_SHIFT_MIN_SMPL (4)
+#define ENABLE_SHIFT_MAX_SMPL (12)
+#define USE_DLY_MIN_SMPL (11)
+#define USE_DLY_MAX_SMPL (14)
+


I said some of this macro newly added aren't
used anywhere.


  struct k3_priv {
+   int ctrl_id;
+   u32 cur_speed;
struct regmap   *reg;
  };
  
@@ -38,6 +71,41 @@ static unsigned long dw_mci_hi6220_caps[] = {

0
  };
  
+struct hs_timing {

+   u32 drv_phase;
+   u32 smpl_dly;
+   u32 smpl_phase_max;
+   u32 smpl_phase_min;
+};
+
+struct hs_timing hs_timing_cfg[TIMING_MODE][TIMING_CFG_NUM] = {
+   { /* reserved */ },
+   { /* SD */
+   {7, 0, 15, 15,},  /* 0: LEGACY 400k */
+   {6, 0,  4,  4,},  /* 1: MMC_HS */
+   {6, 0,  3,  3,},  /* 2: SD_HS */
+   {6, 0, 15, 15,},  /* 3: SDR12 */
+   {6, 0,  2,  2,},  /* 4: SDR25 */
+   {4, 0, 11,  0,},  /* 5: SDR50 */
+   {6, 4, 15,  0,},  /* 6: SDR104 */
+   {0},  /* 7: DDR50 */
+   {0},  /* 8: DDR52 */
+   {0},  /* 9: HS200 */
+   },
+   { /* SDIO */
+   {7, 0, 15, 15,},  /* 0: LEGACY 400k */
+   {0},  /* 1: MMC_HS */
+   {6, 0, 15, 15,},  /* 2: SD_HS */
+   {6, 0, 15, 15,},  /* 3: SDR12 */
+   {6, 0,  0,  0,},  /* 4: SDR25 */
+   {4, 0, 12,  0,},  /* 5: SDR50 */
+   {5, 4, 15,  0,},  /* 6: SDR104 */
+   {0},  /* 7: DDR50 */
+   {0},  /* 8: DDR52 */
+   {0},  /* 9: HS200 */
+   }
+};
+


Does it work for hard-coding the delay timing? All the different boards
with different cards work fine?

And tuning process is also work for SDR50 although it's optional. So how
would that work for your case?


  static void dw_mci_k3_set_ios(struct dw_mci *host, struct mmc_ios *ios)
  {
int ret;
@@ -66,6 +134,10 @@ static int dw_mci_hi6220_parse_dt(struct dw_mci *host)
if (IS_ERR(priv->reg))
priv->reg = NULL;
  
+	priv->ctrl_id = of_alias_get_id(host->dev->of_node, "mshc");

+   if (priv->ctrl_id < 0)
+   priv->ctrl_id = 0;
+
host->priv = priv;
return 0;
  }
@@ -144,7 +216,236 @@ static const struct dw_mci_drv_data hi6220_data = {
.execute_tuning = dw_mci_hi6220_execute_tuning,
  };
  

Re: [PATCH v9 2/2] mmc: dw_mmc-k3: add sd support for hi3660

[Shawn Lin]

On 2017/8/9 11:25, Li Wei wrote:

Add sd card support for hi3660 soc

Signed-off-by: Li Wei 
Signed-off-by: Chen Jun 



I did some comment for your v6 but probably you miss them.

And it's still incorrect for your changelog.


--
Major changes in v3:
  - solve review comments from Heiner Kallweit.
*use the GENMASK and FIELD_PREP macros replace the bit shift operation.
*use usleep_range() replace udelay() and mdelay().

Major changes in v4:
  - solve review comments from Jaehoon Chung.
*move common register for dwmmc controller to dwmmc header file.
*modify definitions type of some register variables.
*get rid of the magic numbers.

Major changes in v5:
  - further improve coding style.

Major changes in v6:
  - solve review comments for Jaehoon Chung.
*modify dw_mci_hi3660_set_ios() to static.
*fix the comment style.

Major changes in v7:
  - solve review comments for John Stultz.
*remove reset code in dw_mmc-k3.c,use reset in core mmc.

Major changes in v8:
  - modify patch v7 name and dependency order.

Major changes in v9:
  - solve review comments for Ulf Hansson.
*use mmc_regulator_set_vqmmc() instead of regulator_set_voltage().
---


should be here...


  drivers/mmc/host/dw_mmc-k3.c | 301 +++
  drivers/mmc/host/dw_mmc.h|   2 +
  2 files changed, 303 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
index e38fb0020bb1..f6910bed55ef 100644
--- a/drivers/mmc/host/dw_mmc-k3.c
+++ b/drivers/mmc/host/dw_mmc-k3.c
@@ -8,6 +8,8 @@
   * (at your option) any later version.
   */
  
+#include 

+#include 
  #include 
  #include 
  #include 
@@ -28,7 +30,38 @@
  #define AO_SCTRL_SEL18BIT(10)
  #define AO_SCTRL_CTRL30x40C
  
+#define DWMMC_SDIO_ID 2

+
+#define SOC_SCTRL_SCPERCTRL5(0x314)
+#define SDCARD_IO_SEL18 BIT(2)
+
+#define SDCARD_RD_THRESHOLD  (512)
+
+#define GENCLK_DIV (7)
+
+#define GPIO_CLK_ENABLE   BIT(16)
+#define GPIO_CLK_DIV_MASK GENMASK(11, 8)
+#define GPIO_USE_SAMPLE_DLY_MASK  GENMASK(13, 13)
+#define UHS_REG_EXT_SAMPLE_PHASE_MASK GENMASK(20, 16)
+#define UHS_REG_EXT_SAMPLE_DRVPHASE_MASK  GENMASK(25, 21)
+#define UHS_REG_EXT_SAMPLE_DLY_MASK   GENMASK(30, 26)
+
+#define TIMING_MODE 3
+#define TIMING_CFG_NUM 10
+
+#define PULL_DOWN BIT(1)
+#define PULL_UP   BIT(0)
+
+#define NUM_PHASES (40)
+
+#define ENABLE_SHIFT_MIN_SMPL (4)
+#define ENABLE_SHIFT_MAX_SMPL (12)
+#define USE_DLY_MIN_SMPL (11)
+#define USE_DLY_MAX_SMPL (14)
+


I said some of this macro newly added aren't
used anywhere.


  struct k3_priv {
+   int ctrl_id;
+   u32 cur_speed;
struct regmap   *reg;
  };
  
@@ -38,6 +71,41 @@ static unsigned long dw_mci_hi6220_caps[] = {

0
  };
  
+struct hs_timing {

+   u32 drv_phase;
+   u32 smpl_dly;
+   u32 smpl_phase_max;
+   u32 smpl_phase_min;
+};
+
+struct hs_timing hs_timing_cfg[TIMING_MODE][TIMING_CFG_NUM] = {
+   { /* reserved */ },
+   { /* SD */
+   {7, 0, 15, 15,},  /* 0: LEGACY 400k */
+   {6, 0,  4,  4,},  /* 1: MMC_HS */
+   {6, 0,  3,  3,},  /* 2: SD_HS */
+   {6, 0, 15, 15,},  /* 3: SDR12 */
+   {6, 0,  2,  2,},  /* 4: SDR25 */
+   {4, 0, 11,  0,},  /* 5: SDR50 */
+   {6, 4, 15,  0,},  /* 6: SDR104 */
+   {0},  /* 7: DDR50 */
+   {0},  /* 8: DDR52 */
+   {0},  /* 9: HS200 */
+   },
+   { /* SDIO */
+   {7, 0, 15, 15,},  /* 0: LEGACY 400k */
+   {0},  /* 1: MMC_HS */
+   {6, 0, 15, 15,},  /* 2: SD_HS */
+   {6, 0, 15, 15,},  /* 3: SDR12 */
+   {6, 0,  0,  0,},  /* 4: SDR25 */
+   {4, 0, 12,  0,},  /* 5: SDR50 */
+   {5, 4, 15,  0,},  /* 6: SDR104 */
+   {0},  /* 7: DDR50 */
+   {0},  /* 8: DDR52 */
+   {0},  /* 9: HS200 */
+   }
+};
+


Does it work for hard-coding the delay timing? All the different boards
with different cards work fine?

And tuning process is also work for SDR50 although it's optional. So how
would that work for your case?


  static void dw_mci_k3_set_ios(struct dw_mci *host, struct mmc_ios *ios)
  {
int ret;
@@ -66,6 +134,10 @@ static int dw_mci_hi6220_parse_dt(struct dw_mci *host)
if (IS_ERR(priv->reg))
priv->reg = NULL;
  
+	priv->ctrl_id = of_alias_get_id(host->dev->of_node, "mshc");

+   if (priv->ctrl_id < 0)
+   priv->ctrl_id = 0;
+
host->priv = priv;
return 0;
  }
@@ -144,7 +216,236 @@ static const struct dw_mci_drv_data hi6220_data = {
.execute_tuning = dw_mci_hi6220_execute_tuning,
  };
  
+static void dw_mci_hs_set_timing(struct 

Re: [PATCH RFC v2 3/5] samples/bpf: Fix inline asm issues building samples on arm64

[David Miller]

From: Joel Fernandes 
Date: Mon, 7 Aug 2017 18:20:49 -0700

> On Mon, Aug 7, 2017 at 11:28 AM, David Miller  wrote:
>> The amount of hellish hacks we are adding to deal with this is getting
>> way out of control.
> 
> I agree with you that hellish hacks are being added which is why it
> keeps breaking. I think one of the things my series does is to add
> back inclusion of asm headers that were previously removed (that is
> the worst hellish hack in my opinion that existing in mainline). So in
> that respect my patch is an improvement and makes it possible to build
> for arm64 platforms (which is currently broken in mainline).

Yeah that is a problem.

Perhaps another avenue of attack is to separate "type" header files from
stuff that has functiond declarations and inline assembler code.

Re: [PATCH RFC v2 3/5] samples/bpf: Fix inline asm issues building samples on arm64

[David Miller]

From: Joel Fernandes 
Date: Mon, 7 Aug 2017 18:20:49 -0700

> On Mon, Aug 7, 2017 at 11:28 AM, David Miller  wrote:
>> The amount of hellish hacks we are adding to deal with this is getting
>> way out of control.
> 
> I agree with you that hellish hacks are being added which is why it
> keeps breaking. I think one of the things my series does is to add
> back inclusion of asm headers that were previously removed (that is
> the worst hellish hack in my opinion that existing in mainline). So in
> that respect my patch is an improvement and makes it possible to build
> for arm64 platforms (which is currently broken in mainline).

Yeah that is a problem.

Perhaps another avenue of attack is to separate "type" header files from
stuff that has functiond declarations and inline assembler code.

Re: [PATCH v1 2/6] fs: use on-stack-bio if backing device has BDI_CAP_SYNC capability

[Matthew Wilcox]

On Wed, Aug 09, 2017 at 10:51:13AM +0900, Minchan Kim wrote:
> On Tue, Aug 08, 2017 at 06:29:04AM -0700, Matthew Wilcox wrote:
> > On Tue, Aug 08, 2017 at 05:49:59AM -0700, Matthew Wilcox wrote:
> > > + struct bio sbio;
> > > + struct bio_vec sbvec;
> > 
> > ... this needs to be sbvec[nr_pages], of course.
> > 
> > > - bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9),
> > > + if (bdi_cap_synchronous_io(inode_to_bdi(inode))) {
> > > + bio = 
> > > + bio_init(bio, , nr_pages);
> > 
> > ... and this needs to be 'sbvec', not ''.
> 
> I don't get it why we need sbvec[nr_pages].
> On-stack-bio works with per-page.
> May I miss something?

The way I redid it, it will work with an arbitrary number of pages.

Re: [PATCH v1 2/6] fs: use on-stack-bio if backing device has BDI_CAP_SYNC capability

[Matthew Wilcox]

On Wed, Aug 09, 2017 at 10:51:13AM +0900, Minchan Kim wrote:
> On Tue, Aug 08, 2017 at 06:29:04AM -0700, Matthew Wilcox wrote:
> > On Tue, Aug 08, 2017 at 05:49:59AM -0700, Matthew Wilcox wrote:
> > > + struct bio sbio;
> > > + struct bio_vec sbvec;
> > 
> > ... this needs to be sbvec[nr_pages], of course.
> > 
> > > - bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9),
> > > + if (bdi_cap_synchronous_io(inode_to_bdi(inode))) {
> > > + bio = 
> > > + bio_init(bio, , nr_pages);
> > 
> > ... and this needs to be 'sbvec', not ''.
> 
> I don't get it why we need sbvec[nr_pages].
> On-stack-bio works with per-page.
> May I miss something?

The way I redid it, it will work with an arbitrary number of pages.

Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53?

[Willy Tarreau]

On Tue, Aug 08, 2017 at 05:12:03PM -0500, Rob Landley wrote:
> If your rootfs has a size= in /proc/mounts it's tmpfs, ala:
> 
>   rootfs / rootfs rw,size=126564k,nr_inodes=31641 0 0

You're right, I have it and thought about it. Anyway the point is that
it works transparently for me. Apparently for Thomas there's an issue
where his initramfs isn't properly extracted and he ends up with an
empty rootfs.

Willy

Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53?

[Willy Tarreau]

On Tue, Aug 08, 2017 at 05:12:03PM -0500, Rob Landley wrote:
> If your rootfs has a size= in /proc/mounts it's tmpfs, ala:
> 
>   rootfs / rootfs rw,size=126564k,nr_inodes=31641 0 0

You're right, I have it and thought about it. Anyway the point is that
it works transparently for me. Apparently for Thomas there's an issue
where his initramfs isn't properly extracted and he ends up with an
empty rootfs.

Willy

Re: [PATCH 2/2] lib: add test for bitmap_parselist()

[kbuild test robot]

Hi Yury,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.13-rc4 next-20170808]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Yury-Norov/lib-make-bitmap_parselist-thread-safe-and-much-faster/20170809-105307
config: i386-randconfig-x000-201732 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

>> lib/test_bitmap.c:180:17: warning: large integer implicitly truncated to 
>> unsigned type [-Woverflow]
0xfffe, 0x, 0x};
^~
   lib/test_bitmap.c:180:37: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
0xfffe, 0x, 0x};
^~
   lib/test_bitmap.c:181:38: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
static const unsigned long exp2[] = {0x, 
0x};
 ^~
   lib/test_bitmap.c:181:58: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
static const unsigned long exp2[] = {0x, 
0x};
 ^~
   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/bitmap.h:9,
from lib/test_bitmap.c:7:
   lib/test_bitmap.c: In function 'test_bitmap_parselist':
   include/linux/kern_levels.h:4:18: warning: format '%lu' expects argument of 
type 'long unsigned int', but argument 4 has type 'cycles_t {aka long long 
unsigned int}' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
 ^~~~
   include/linux/printk.h:301:9: note: in expansion of macro 'KERN_ERR'
 printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
>> lib/test_bitmap.c:235:4: note: in expansion of macro 'pr_err'
   pr_err("test %d: input is '%s' OK, Time: %lu\n",
   ^~

vim +180 lib/test_bitmap.c

   177  
   178  static const unsigned long exp[] = {1, 2, 0x, 0x, 
0x,
   179  0x, 0x, 0x, 
0x,
 > 180  0xfffe, 0x, 
 > 0x};
   181  static const unsigned long exp2[] = {0x, 
0x};
   182  
   183  static const struct test_bitmap_parselist parselist_tests[] __initconst 
= {
   184  {0, "0",[0], 8, 0},
   185  {0, "1",[1], 8, 0},
   186  {0, "0-15", [2], 32, 0},
   187  {0, "16-31",[3], 32, 0},
   188  {0, "0-31:1/2", [4], 32, 0},
   189  {0, "1-31:1/2", [5], 32, 0},
   190  {0, "0-31:1/4", [6], 32, 0},
   191  {0, "1-31:1/4", [7], 32, 0},
   192  {0, "0-31:4/4", [8], 32, 0},
   193  {0, "1-31:4/4", [9], 32, 0},
   194  {0, "0-31:1/4,32-63:2/4",   [10], 64, 0},
   195  {0, "0-31:3/4,32-63:4/4",   [11], 64, 0},
   196  
   197  {0, "0-31:1/4,32-63:2/4,64-95:3/4,96-127:4/4",  exp2, 128, 0},
   198  
   199  {0, "0-2047:128/256", NULL, 2048, PARSE_TIME},
   200  
   201  {-EINVAL, "-1", NULL, 8, 0},
   202  {-EINVAL, "-0", NULL, 8, 0},
   203  {-EINVAL, "10-1", NULL, 8, 0},
   204  {-EINVAL, "0-31:10/1", NULL, 8, 0},
   205  };
   206  
   207  static void __init test_bitmap_parselist(void)
   208  {
   209  int i;
   210  int err;
   211  cycles_t cycles;
   212  DECLARE_BITMAP(bmap, 2048);
   213  
   214  for (i = 0; i < ARRAY_SIZE(parselist_tests); i++) {
   215  #define ptest parselist_tests[i]
   216  
   217  cycles = get_cycles();
   218  err = bitmap_parselist(ptest.in, bmap, ptest.nbits);
   219  cycles = get_cycles() - cycles;
   220  
   221  if (err != ptest.errno) {
   222  pr_err("test %d: input is %s, errno is %d, 
expected %d\n",
   223

Re: [PATCH 2/2] lib: add test for bitmap_parselist()

[kbuild test robot]

Hi Yury,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.13-rc4 next-20170808]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Yury-Norov/lib-make-bitmap_parselist-thread-safe-and-much-faster/20170809-105307
config: i386-randconfig-x000-201732 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

>> lib/test_bitmap.c:180:17: warning: large integer implicitly truncated to 
>> unsigned type [-Woverflow]
0xfffe, 0x, 0x};
^~
   lib/test_bitmap.c:180:37: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
0xfffe, 0x, 0x};
^~
   lib/test_bitmap.c:181:38: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
static const unsigned long exp2[] = {0x, 
0x};
 ^~
   lib/test_bitmap.c:181:58: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
static const unsigned long exp2[] = {0x, 
0x};
 ^~
   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/bitmap.h:9,
from lib/test_bitmap.c:7:
   lib/test_bitmap.c: In function 'test_bitmap_parselist':
   include/linux/kern_levels.h:4:18: warning: format '%lu' expects argument of 
type 'long unsigned int', but argument 4 has type 'cycles_t {aka long long 
unsigned int}' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
 ^~~~
   include/linux/printk.h:301:9: note: in expansion of macro 'KERN_ERR'
 printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
>> lib/test_bitmap.c:235:4: note: in expansion of macro 'pr_err'
   pr_err("test %d: input is '%s' OK, Time: %lu\n",
   ^~

vim +180 lib/test_bitmap.c

   177  
   178  static const unsigned long exp[] = {1, 2, 0x, 0x, 
0x,
   179  0x, 0x, 0x, 
0x,
 > 180  0xfffe, 0x, 
 > 0x};
   181  static const unsigned long exp2[] = {0x, 
0x};
   182  
   183  static const struct test_bitmap_parselist parselist_tests[] __initconst 
= {
   184  {0, "0",[0], 8, 0},
   185  {0, "1",[1], 8, 0},
   186  {0, "0-15", [2], 32, 0},
   187  {0, "16-31",[3], 32, 0},
   188  {0, "0-31:1/2", [4], 32, 0},
   189  {0, "1-31:1/2", [5], 32, 0},
   190  {0, "0-31:1/4", [6], 32, 0},
   191  {0, "1-31:1/4", [7], 32, 0},
   192  {0, "0-31:4/4", [8], 32, 0},
   193  {0, "1-31:4/4", [9], 32, 0},
   194  {0, "0-31:1/4,32-63:2/4",   [10], 64, 0},
   195  {0, "0-31:3/4,32-63:4/4",   [11], 64, 0},
   196  
   197  {0, "0-31:1/4,32-63:2/4,64-95:3/4,96-127:4/4",  exp2, 128, 0},
   198  
   199  {0, "0-2047:128/256", NULL, 2048, PARSE_TIME},
   200  
   201  {-EINVAL, "-1", NULL, 8, 0},
   202  {-EINVAL, "-0", NULL, 8, 0},
   203  {-EINVAL, "10-1", NULL, 8, 0},
   204  {-EINVAL, "0-31:10/1", NULL, 8, 0},
   205  };
   206  
   207  static void __init test_bitmap_parselist(void)
   208  {
   209  int i;
   210  int err;
   211  cycles_t cycles;
   212  DECLARE_BITMAP(bmap, 2048);
   213  
   214  for (i = 0; i < ARRAY_SIZE(parselist_tests); i++) {
   215  #define ptest parselist_tests[i]
   216  
   217  cycles = get_cycles();
   218  err = bitmap_parselist(ptest.in, bmap, ptest.nbits);
   219  cycles = get_cycles() - cycles;
   220  
   221  if (err != ptest.errno) {
   222  pr_err("test %d: input is %s, errno is %d, 
expected %d\n",
   223

[PATCH v9 1/2] mmc: dw_mmc: move controller reset before driver init

[Li Wei]

This commit modifies dw_mci_probe(), it moves reset assertion before
drv_data->init(host)

Some driver needs to access controller registers in its .init() ops. So,
in order to make such access safe, we should do controller reset before
.init() being called.

Signed-off-by: Wei Li 
Signed-off-by: Guodong Xu 
Signed-off-by: Chen Jun 
---
 drivers/mmc/host/dw_mmc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a9dfb26972f2..f2fa928e1a12 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3067,6 +3067,12 @@ int dw_mci_probe(struct dw_mci *host)
goto err_clk_ciu;
}
 
+   if (!IS_ERR(host->pdata->rstc)) {
+   reset_control_assert(host->pdata->rstc);
+   usleep_range(10, 50);
+   reset_control_deassert(host->pdata->rstc);
+   }
+
if (drv_data && drv_data->init) {
ret = drv_data->init(host);
if (ret) {
@@ -3076,12 +3082,6 @@ int dw_mci_probe(struct dw_mci *host)
}
}
 
-   if (!IS_ERR(host->pdata->rstc)) {
-   reset_control_assert(host->pdata->rstc);
-   usleep_range(10, 50);
-   reset_control_deassert(host->pdata->rstc);
-   }
-
setup_timer(>cmd11_timer,
dw_mci_cmd11_timer, (unsigned long)host);
 
-- 
2.11.0

[PATCH v9 1/2] mmc: dw_mmc: move controller reset before driver init

[Li Wei]

This commit modifies dw_mci_probe(), it moves reset assertion before
drv_data->init(host)

Some driver needs to access controller registers in its .init() ops. So,
in order to make such access safe, we should do controller reset before
.init() being called.

Signed-off-by: Wei Li 
Signed-off-by: Guodong Xu 
Signed-off-by: Chen Jun 
---
 drivers/mmc/host/dw_mmc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a9dfb26972f2..f2fa928e1a12 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3067,6 +3067,12 @@ int dw_mci_probe(struct dw_mci *host)
goto err_clk_ciu;
}
 
+   if (!IS_ERR(host->pdata->rstc)) {
+   reset_control_assert(host->pdata->rstc);
+   usleep_range(10, 50);
+   reset_control_deassert(host->pdata->rstc);
+   }
+
if (drv_data && drv_data->init) {
ret = drv_data->init(host);
if (ret) {
@@ -3076,12 +3082,6 @@ int dw_mci_probe(struct dw_mci *host)
}
}
 
-   if (!IS_ERR(host->pdata->rstc)) {
-   reset_control_assert(host->pdata->rstc);
-   usleep_range(10, 50);
-   reset_control_deassert(host->pdata->rstc);
-   }
-
setup_timer(>cmd11_timer,
dw_mci_cmd11_timer, (unsigned long)host);
 
-- 
2.11.0

[PATCH v9 2/2] mmc: dw_mmc-k3: add sd support for hi3660

[Li Wei]

Add sd card support for hi3660 soc

Signed-off-by: Li Wei 
Signed-off-by: Chen Jun 

--
Major changes in v3:
 - solve review comments from Heiner Kallweit.
   *use the GENMASK and FIELD_PREP macros replace the bit shift operation.
   *use usleep_range() replace udelay() and mdelay().

Major changes in v4:
 - solve review comments from Jaehoon Chung.
   *move common register for dwmmc controller to dwmmc header file.
   *modify definitions type of some register variables.
   *get rid of the magic numbers.

Major changes in v5:
 - further improve coding style.

Major changes in v6:
 - solve review comments for Jaehoon Chung.
   *modify dw_mci_hi3660_set_ios() to static.
   *fix the comment style.

Major changes in v7:
 - solve review comments for John Stultz.
   *remove reset code in dw_mmc-k3.c,use reset in core mmc.

Major changes in v8:
 - modify patch v7 name and dependency order.

Major changes in v9:
 - solve review comments for Ulf Hansson.
   *use mmc_regulator_set_vqmmc() instead of regulator_set_voltage().
---
 drivers/mmc/host/dw_mmc-k3.c | 301 +++
 drivers/mmc/host/dw_mmc.h|   2 +
 2 files changed, 303 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
index e38fb0020bb1..f6910bed55ef 100644
--- a/drivers/mmc/host/dw_mmc-k3.c
+++ b/drivers/mmc/host/dw_mmc-k3.c
@@ -8,6 +8,8 @@
  * (at your option) any later version.
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -28,7 +30,38 @@
 #define AO_SCTRL_SEL18 BIT(10)
 #define AO_SCTRL_CTRL3 0x40C
 
+#define DWMMC_SDIO_ID 2
+
+#define SOC_SCTRL_SCPERCTRL5(0x314)
+#define SDCARD_IO_SEL18 BIT(2)
+
+#define SDCARD_RD_THRESHOLD  (512)
+
+#define GENCLK_DIV (7)
+
+#define GPIO_CLK_ENABLE   BIT(16)
+#define GPIO_CLK_DIV_MASK GENMASK(11, 8)
+#define GPIO_USE_SAMPLE_DLY_MASK  GENMASK(13, 13)
+#define UHS_REG_EXT_SAMPLE_PHASE_MASK GENMASK(20, 16)
+#define UHS_REG_EXT_SAMPLE_DRVPHASE_MASK  GENMASK(25, 21)
+#define UHS_REG_EXT_SAMPLE_DLY_MASK   GENMASK(30, 26)
+
+#define TIMING_MODE 3
+#define TIMING_CFG_NUM 10
+
+#define PULL_DOWN BIT(1)
+#define PULL_UP   BIT(0)
+
+#define NUM_PHASES (40)
+
+#define ENABLE_SHIFT_MIN_SMPL (4)
+#define ENABLE_SHIFT_MAX_SMPL (12)
+#define USE_DLY_MIN_SMPL (11)
+#define USE_DLY_MAX_SMPL (14)
+
 struct k3_priv {
+   int ctrl_id;
+   u32 cur_speed;
struct regmap   *reg;
 };
 
@@ -38,6 +71,41 @@ static unsigned long dw_mci_hi6220_caps[] = {
0
 };
 
+struct hs_timing {
+   u32 drv_phase;
+   u32 smpl_dly;
+   u32 smpl_phase_max;
+   u32 smpl_phase_min;
+};
+
+struct hs_timing hs_timing_cfg[TIMING_MODE][TIMING_CFG_NUM] = {
+   { /* reserved */ },
+   { /* SD */
+   {7, 0, 15, 15,},  /* 0: LEGACY 400k */
+   {6, 0,  4,  4,},  /* 1: MMC_HS */
+   {6, 0,  3,  3,},  /* 2: SD_HS */
+   {6, 0, 15, 15,},  /* 3: SDR12 */
+   {6, 0,  2,  2,},  /* 4: SDR25 */
+   {4, 0, 11,  0,},  /* 5: SDR50 */
+   {6, 4, 15,  0,},  /* 6: SDR104 */
+   {0},  /* 7: DDR50 */
+   {0},  /* 8: DDR52 */
+   {0},  /* 9: HS200 */
+   },
+   { /* SDIO */
+   {7, 0, 15, 15,},  /* 0: LEGACY 400k */
+   {0},  /* 1: MMC_HS */
+   {6, 0, 15, 15,},  /* 2: SD_HS */
+   {6, 0, 15, 15,},  /* 3: SDR12 */
+   {6, 0,  0,  0,},  /* 4: SDR25 */
+   {4, 0, 12,  0,},  /* 5: SDR50 */
+   {5, 4, 15,  0,},  /* 6: SDR104 */
+   {0},  /* 7: DDR50 */
+   {0},  /* 8: DDR52 */
+   {0},  /* 9: HS200 */
+   }
+};
+
 static void dw_mci_k3_set_ios(struct dw_mci *host, struct mmc_ios *ios)
 {
int ret;
@@ -66,6 +134,10 @@ static int dw_mci_hi6220_parse_dt(struct dw_mci *host)
if (IS_ERR(priv->reg))
priv->reg = NULL;
 
+   priv->ctrl_id = of_alias_get_id(host->dev->of_node, "mshc");
+   if (priv->ctrl_id < 0)
+   priv->ctrl_id = 0;
+
host->priv = priv;
return 0;
 }
@@ -144,7 +216,236 @@ static const struct dw_mci_drv_data hi6220_data = {
.execute_tuning = dw_mci_hi6220_execute_tuning,
 };
 
+static void dw_mci_hs_set_timing(struct dw_mci *host, int timing,
+int smpl_phase)
+{
+   u32 drv_phase;
+   u32 smpl_dly;
+   u32 use_smpl_dly = 0;
+   u32 enable_shift = 0;
+   u32 reg_value;
+   int ctrl_id;
+   struct k3_priv *priv;
+
+   priv = host->priv;
+   ctrl_id = priv->ctrl_id;
+
+   drv_phase = hs_timing_cfg[ctrl_id][timing].drv_phase;
+   smpl_dly   = hs_timing_cfg[ctrl_id][timing].smpl_dly;
+   

[PATCH v9 2/2] mmc: dw_mmc-k3: add sd support for hi3660

[Li Wei]

Add sd card support for hi3660 soc

Signed-off-by: Li Wei 
Signed-off-by: Chen Jun 

--
Major changes in v3:
 - solve review comments from Heiner Kallweit.
   *use the GENMASK and FIELD_PREP macros replace the bit shift operation.
   *use usleep_range() replace udelay() and mdelay().

Major changes in v4:
 - solve review comments from Jaehoon Chung.
   *move common register for dwmmc controller to dwmmc header file.
   *modify definitions type of some register variables.
   *get rid of the magic numbers.

Major changes in v5:
 - further improve coding style.

Major changes in v6:
 - solve review comments for Jaehoon Chung.
   *modify dw_mci_hi3660_set_ios() to static.
   *fix the comment style.

Major changes in v7:
 - solve review comments for John Stultz.
   *remove reset code in dw_mmc-k3.c,use reset in core mmc.

Major changes in v8:
 - modify patch v7 name and dependency order.

Major changes in v9:
 - solve review comments for Ulf Hansson.
   *use mmc_regulator_set_vqmmc() instead of regulator_set_voltage().
---
 drivers/mmc/host/dw_mmc-k3.c | 301 +++
 drivers/mmc/host/dw_mmc.h|   2 +
 2 files changed, 303 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
index e38fb0020bb1..f6910bed55ef 100644
--- a/drivers/mmc/host/dw_mmc-k3.c
+++ b/drivers/mmc/host/dw_mmc-k3.c
@@ -8,6 +8,8 @@
  * (at your option) any later version.
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -28,7 +30,38 @@
 #define AO_SCTRL_SEL18 BIT(10)
 #define AO_SCTRL_CTRL3 0x40C
 
+#define DWMMC_SDIO_ID 2
+
+#define SOC_SCTRL_SCPERCTRL5(0x314)
+#define SDCARD_IO_SEL18 BIT(2)
+
+#define SDCARD_RD_THRESHOLD  (512)
+
+#define GENCLK_DIV (7)
+
+#define GPIO_CLK_ENABLE   BIT(16)
+#define GPIO_CLK_DIV_MASK GENMASK(11, 8)
+#define GPIO_USE_SAMPLE_DLY_MASK  GENMASK(13, 13)
+#define UHS_REG_EXT_SAMPLE_PHASE_MASK GENMASK(20, 16)
+#define UHS_REG_EXT_SAMPLE_DRVPHASE_MASK  GENMASK(25, 21)
+#define UHS_REG_EXT_SAMPLE_DLY_MASK   GENMASK(30, 26)
+
+#define TIMING_MODE 3
+#define TIMING_CFG_NUM 10
+
+#define PULL_DOWN BIT(1)
+#define PULL_UP   BIT(0)
+
+#define NUM_PHASES (40)
+
+#define ENABLE_SHIFT_MIN_SMPL (4)
+#define ENABLE_SHIFT_MAX_SMPL (12)
+#define USE_DLY_MIN_SMPL (11)
+#define USE_DLY_MAX_SMPL (14)
+
 struct k3_priv {
+   int ctrl_id;
+   u32 cur_speed;
struct regmap   *reg;
 };
 
@@ -38,6 +71,41 @@ static unsigned long dw_mci_hi6220_caps[] = {
0
 };
 
+struct hs_timing {
+   u32 drv_phase;
+   u32 smpl_dly;
+   u32 smpl_phase_max;
+   u32 smpl_phase_min;
+};
+
+struct hs_timing hs_timing_cfg[TIMING_MODE][TIMING_CFG_NUM] = {
+   { /* reserved */ },
+   { /* SD */
+   {7, 0, 15, 15,},  /* 0: LEGACY 400k */
+   {6, 0,  4,  4,},  /* 1: MMC_HS */
+   {6, 0,  3,  3,},  /* 2: SD_HS */
+   {6, 0, 15, 15,},  /* 3: SDR12 */
+   {6, 0,  2,  2,},  /* 4: SDR25 */
+   {4, 0, 11,  0,},  /* 5: SDR50 */
+   {6, 4, 15,  0,},  /* 6: SDR104 */
+   {0},  /* 7: DDR50 */
+   {0},  /* 8: DDR52 */
+   {0},  /* 9: HS200 */
+   },
+   { /* SDIO */
+   {7, 0, 15, 15,},  /* 0: LEGACY 400k */
+   {0},  /* 1: MMC_HS */
+   {6, 0, 15, 15,},  /* 2: SD_HS */
+   {6, 0, 15, 15,},  /* 3: SDR12 */
+   {6, 0,  0,  0,},  /* 4: SDR25 */
+   {4, 0, 12,  0,},  /* 5: SDR50 */
+   {5, 4, 15,  0,},  /* 6: SDR104 */
+   {0},  /* 7: DDR50 */
+   {0},  /* 8: DDR52 */
+   {0},  /* 9: HS200 */
+   }
+};
+
 static void dw_mci_k3_set_ios(struct dw_mci *host, struct mmc_ios *ios)
 {
int ret;
@@ -66,6 +134,10 @@ static int dw_mci_hi6220_parse_dt(struct dw_mci *host)
if (IS_ERR(priv->reg))
priv->reg = NULL;
 
+   priv->ctrl_id = of_alias_get_id(host->dev->of_node, "mshc");
+   if (priv->ctrl_id < 0)
+   priv->ctrl_id = 0;
+
host->priv = priv;
return 0;
 }
@@ -144,7 +216,236 @@ static const struct dw_mci_drv_data hi6220_data = {
.execute_tuning = dw_mci_hi6220_execute_tuning,
 };
 
+static void dw_mci_hs_set_timing(struct dw_mci *host, int timing,
+int smpl_phase)
+{
+   u32 drv_phase;
+   u32 smpl_dly;
+   u32 use_smpl_dly = 0;
+   u32 enable_shift = 0;
+   u32 reg_value;
+   int ctrl_id;
+   struct k3_priv *priv;
+
+   priv = host->priv;
+   ctrl_id = priv->ctrl_id;
+
+   drv_phase = hs_timing_cfg[ctrl_id][timing].drv_phase;
+   smpl_dly   = hs_timing_cfg[ctrl_id][timing].smpl_dly;
+   if (smpl_phase == -1)
+   

Re: [PATCH v9 2/4] PCI: Disable PCIe Relaxed Ordering if unsupported

[Bjorn Helgaas]

On Tue, Aug 08, 2017 at 09:22:39PM -0500, Bjorn Helgaas wrote:
> On Sat, Aug 05, 2017 at 03:15:11PM +0800, Ding Tianhong wrote:
> > When bit4 is set in the PCIe Device Control register, it indicates
> > whether the device is permitted to use relaxed ordering.
> > On some platforms using relaxed ordering can have performance issues or
> > due to erratum can cause data-corruption. In such cases devices must avoid
> > using relaxed ordering.
> > 
> > This patch checks if there is any node in the hierarchy that indicates that
> > using relaxed ordering is not safe. 
...

> > +EXPORT_SYMBOL(pcie_relaxed_ordering_supported);
> 
> This is misnamed.  This doesn't tell us anything about whether the
> device *supports* relaxed ordering.  It only tells us whether the
> device is *permitted* to use it.
> 
> When a device initiates a transaction, the hardware should set the RO
> bit in the TLP with logic something like this:
> 
>   RO =  &&
> &&
>
> 
> The issue you're fixing is that some Completers don't handle RO
> correctly.  The determining factor is not the Requester, but the
> Completer (for this series, a Root Port).  So I think this should be
> something like:
> 
>   int pcie_relaxed_ordering_broken(struct pci_dev *completer)
>   {
> if (!completer)
>   return 0;
> 
> return completer->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING;
>   }
> 
> and the caller should do something like this:
> 
>  if (pcie_relaxed_ordering_broken(pci_find_pcie_root_port(pdev)))
>adapter->flags |= ROOT_NO_RELAXED_ORDERING;
> 
> That way it's obvious where the issue is, and it's obvious that the
> answer might be different for peer-to-peer transactions than it is for
> transactions to the root port, i.e., to coherent memory.

After looking at the driver, I wonder if it would be simpler like
this:

  int pcie_relaxed_ordering_enabled(struct pci_dev *dev)
  {
u16 ctl;

pcie_capability_read_word(dev, PCI_EXP_DEVCTL, );
return ctl & PCI_EXP_DEVCTL_RELAX_EN;
  }
  EXPORT_SYMBOL(pcie_relaxed_ordering_enabled);

  static void pci_configure_relaxed_ordering(struct pci_dev *dev)
  {
struct pci_dev *root;

if (dev->is_virtfn)
  return;  /* PCI_EXP_DEVCTL_RELAX_EN is RsvdP in VFs */

if (!pcie_relaxed_ordering_enabled(dev))
  return;

/*
 * For now, we only deal with Relaxed Ordering issues with Root
 * Ports.  Peer-to-peer DMA is another can of worms.
 */
root = pci_find_pcie_root_port(dev);
if (!root)
  return;

if (root->relaxed_ordering_broken)
  pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
 PCI_EXP_DEVCTL_RELAX_EN);
  }

This doesn't check every intervening switch, but I don't think we know
about any issues except with root ports.

And the driver could do:

  if (!pcie_relaxed_ordering_enabled(pdev))
adapter->flags |= ROOT_NO_RELAXED_ORDERING;

The driver code wouldn't show anything about coherent memory vs.
peer-to-peer, but we really don't have a clue about how to handle that
yet anyway.

I guess this is back to exactly what you proposed, except that I
changed the name of pcie_relaxed_ordering_supported() to
pcie_relaxed_ordering_enabled(), which I think is slightly more
specific from the device's point of view.

Bjorn

Re: [PATCH v9 2/4] PCI: Disable PCIe Relaxed Ordering if unsupported

[Bjorn Helgaas]

On Tue, Aug 08, 2017 at 09:22:39PM -0500, Bjorn Helgaas wrote:
> On Sat, Aug 05, 2017 at 03:15:11PM +0800, Ding Tianhong wrote:
> > When bit4 is set in the PCIe Device Control register, it indicates
> > whether the device is permitted to use relaxed ordering.
> > On some platforms using relaxed ordering can have performance issues or
> > due to erratum can cause data-corruption. In such cases devices must avoid
> > using relaxed ordering.
> > 
> > This patch checks if there is any node in the hierarchy that indicates that
> > using relaxed ordering is not safe. 
...

> > +EXPORT_SYMBOL(pcie_relaxed_ordering_supported);
> 
> This is misnamed.  This doesn't tell us anything about whether the
> device *supports* relaxed ordering.  It only tells us whether the
> device is *permitted* to use it.
> 
> When a device initiates a transaction, the hardware should set the RO
> bit in the TLP with logic something like this:
> 
>   RO =  &&
> &&
>
> 
> The issue you're fixing is that some Completers don't handle RO
> correctly.  The determining factor is not the Requester, but the
> Completer (for this series, a Root Port).  So I think this should be
> something like:
> 
>   int pcie_relaxed_ordering_broken(struct pci_dev *completer)
>   {
> if (!completer)
>   return 0;
> 
> return completer->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING;
>   }
> 
> and the caller should do something like this:
> 
>  if (pcie_relaxed_ordering_broken(pci_find_pcie_root_port(pdev)))
>adapter->flags |= ROOT_NO_RELAXED_ORDERING;
> 
> That way it's obvious where the issue is, and it's obvious that the
> answer might be different for peer-to-peer transactions than it is for
> transactions to the root port, i.e., to coherent memory.

After looking at the driver, I wonder if it would be simpler like
this:

  int pcie_relaxed_ordering_enabled(struct pci_dev *dev)
  {
u16 ctl;

pcie_capability_read_word(dev, PCI_EXP_DEVCTL, );
return ctl & PCI_EXP_DEVCTL_RELAX_EN;
  }
  EXPORT_SYMBOL(pcie_relaxed_ordering_enabled);

  static void pci_configure_relaxed_ordering(struct pci_dev *dev)
  {
struct pci_dev *root;

if (dev->is_virtfn)
  return;  /* PCI_EXP_DEVCTL_RELAX_EN is RsvdP in VFs */

if (!pcie_relaxed_ordering_enabled(dev))
  return;

/*
 * For now, we only deal with Relaxed Ordering issues with Root
 * Ports.  Peer-to-peer DMA is another can of worms.
 */
root = pci_find_pcie_root_port(dev);
if (!root)
  return;

if (root->relaxed_ordering_broken)
  pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
 PCI_EXP_DEVCTL_RELAX_EN);
  }

This doesn't check every intervening switch, but I don't think we know
about any issues except with root ports.

And the driver could do:

  if (!pcie_relaxed_ordering_enabled(pdev))
adapter->flags |= ROOT_NO_RELAXED_ORDERING;

The driver code wouldn't show anything about coherent memory vs.
peer-to-peer, but we really don't have a clue about how to handle that
yet anyway.

I guess this is back to exactly what you proposed, except that I
changed the name of pcie_relaxed_ordering_supported() to
pcie_relaxed_ordering_enabled(), which I think is slightly more
specific from the device's point of view.

Bjorn

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

[Ganapatrao Kulkarni]

On Wed, Aug 9, 2017 at 7:12 AM, Leizhen (ThunderTown)
 wrote:
>
>
> On 2017/8/8 20:03, Ganapatrao Kulkarni wrote:
>> On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown)
>>  wrote:
>>>
>>>
>>> On 2017/7/26 19:08, Joerg Roedel wrote:
 Hi Robin.

 On Fri, Jul 21, 2017 at 12:41:57PM +0100, Robin Murphy wrote:
> Hi all,
>
> In the wake of the ARM SMMU optimisation efforts, it seems that certain
> workloads (e.g. storage I/O with large scatterlists) probably remain quite
> heavily influenced by IOVA allocation performance. Separately, Ard also
> reported massive performance drops for a graphical desktop on AMD Seattle
> when enabling SMMUs via IORT, which we traced to dma_32bit_pfn in the DMA
> ops domain getting initialised differently for ACPI vs. DT, and exposing
> the overhead of the rbtree slow path. Whilst we could go around trying to
> close up all the little gaps that lead to hitting the slowest case, it
> seems a much better idea to simply make said slowest case a lot less slow.

 Do you have some numbers here? How big was the impact before these
 patches and how is it with the patches?
>>> Here are some numbers:
>>>
>>> (before)$ iperf -s
>>> 
>>> Server listening on TCP port 5001
>>> TCP window size: 85.3 KByte (default)
>>> 
>>> [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35898
>>> [ ID] Interval   Transfer Bandwidth
>>> [  4]  0.0-10.2 sec  7.88 MBytes  6.48 Mbits/sec
>>> [  5] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35900
>>> [  5]  0.0-10.3 sec  7.88 MBytes  6.43 Mbits/sec
>>> [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35902
>>> [  4]  0.0-10.3 sec  7.88 MBytes  6.43 Mbits/sec
>>>
>>> (after)$ iperf -s
>>> 
>>> Server listening on TCP port 5001
>>> TCP window size: 85.3 KByte (default)
>>> 
>>> [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36330
>>> [ ID] Interval   Transfer Bandwidth
>>> [  4]  0.0-10.0 sec  1.09 GBytes   933 Mbits/sec
>>> [  5] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36332
>>> [  5]  0.0-10.0 sec  1.10 GBytes   939 Mbits/sec
>>> [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36334
>>> [  4]  0.0-10.0 sec  1.10 GBytes   938 Mbits/sec
>>>
>>
>> Is this testing done on Host or on Guest/VM?
> Host

As per your log, iperf throughput is improved to 938 Mbits/sec
from  6.43 Mbits/sec.
IMO, this seems to be unrealistic, some thing wrong with the testing?

>
>>


   Joerg


 .

>>>
>>> --
>>> Thanks!
>>> BestRegards
>>>
>>>
>>> ___
>>> linux-arm-kernel mailing list
>>> linux-arm-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>> thanks
>> Ganapat
>>
>> .
>>
>
> --
> Thanks!
> BestRegards
>

thanks
Ganapat

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

[Ganapatrao Kulkarni]

On Wed, Aug 9, 2017 at 7:12 AM, Leizhen (ThunderTown)
 wrote:
>
>
> On 2017/8/8 20:03, Ganapatrao Kulkarni wrote:
>> On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown)
>>  wrote:
>>>
>>>
>>> On 2017/7/26 19:08, Joerg Roedel wrote:
 Hi Robin.

 On Fri, Jul 21, 2017 at 12:41:57PM +0100, Robin Murphy wrote:
> Hi all,
>
> In the wake of the ARM SMMU optimisation efforts, it seems that certain
> workloads (e.g. storage I/O with large scatterlists) probably remain quite
> heavily influenced by IOVA allocation performance. Separately, Ard also
> reported massive performance drops for a graphical desktop on AMD Seattle
> when enabling SMMUs via IORT, which we traced to dma_32bit_pfn in the DMA
> ops domain getting initialised differently for ACPI vs. DT, and exposing
> the overhead of the rbtree slow path. Whilst we could go around trying to
> close up all the little gaps that lead to hitting the slowest case, it
> seems a much better idea to simply make said slowest case a lot less slow.

 Do you have some numbers here? How big was the impact before these
 patches and how is it with the patches?
>>> Here are some numbers:
>>>
>>> (before)$ iperf -s
>>> 
>>> Server listening on TCP port 5001
>>> TCP window size: 85.3 KByte (default)
>>> 
>>> [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35898
>>> [ ID] Interval   Transfer Bandwidth
>>> [  4]  0.0-10.2 sec  7.88 MBytes  6.48 Mbits/sec
>>> [  5] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35900
>>> [  5]  0.0-10.3 sec  7.88 MBytes  6.43 Mbits/sec
>>> [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35902
>>> [  4]  0.0-10.3 sec  7.88 MBytes  6.43 Mbits/sec
>>>
>>> (after)$ iperf -s
>>> 
>>> Server listening on TCP port 5001
>>> TCP window size: 85.3 KByte (default)
>>> 
>>> [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36330
>>> [ ID] Interval   Transfer Bandwidth
>>> [  4]  0.0-10.0 sec  1.09 GBytes   933 Mbits/sec
>>> [  5] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36332
>>> [  5]  0.0-10.0 sec  1.10 GBytes   939 Mbits/sec
>>> [  4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36334
>>> [  4]  0.0-10.0 sec  1.10 GBytes   938 Mbits/sec
>>>
>>
>> Is this testing done on Host or on Guest/VM?
> Host

As per your log, iperf throughput is improved to 938 Mbits/sec
from  6.43 Mbits/sec.
IMO, this seems to be unrealistic, some thing wrong with the testing?

>
>>


   Joerg


 .

>>>
>>> --
>>> Thanks!
>>> BestRegards
>>>
>>>
>>> ___
>>> linux-arm-kernel mailing list
>>> linux-arm-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>> thanks
>> Ganapat
>>
>> .
>>
>
> --
> Thanks!
> BestRegards
>

thanks
Ganapat

[PATCH] modpost: simplify sec_name()

[Masahiro Yamada]

There is code duplication between sec_name() and sech_name().
Simplify sec_name() by re-using sech_name().  Also, move them up
to remove the forward declaration of sec_name().

Signed-off-by: Masahiro Yamada 
---

 scripts/mod/modpost.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 48397feb08fb..b920d186ad4a 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -261,7 +261,17 @@ static enum export export_no(const char *s)
return export_unknown;
 }
 
-static const char *sec_name(struct elf_info *elf, int secindex);
+static const char *sech_name(struct elf_info *elf, Elf_Shdr *sechdr)
+{
+   return (void *)elf->hdr +
+   elf->sechdrs[elf->secindex_strings].sh_offset +
+   sechdr->sh_name;
+}
+
+static const char *sec_name(struct elf_info *elf, int secindex)
+{
+   return sech_name(elf, >sechdrs[secindex]);
+}
 
 #define strstarts(str, prefix) (strncmp(str, prefix, strlen(prefix)) == 0)
 
@@ -775,21 +785,6 @@ static const char *sym_name(struct elf_info *elf, Elf_Sym 
*sym)
return "(unknown)";
 }
 
-static const char *sec_name(struct elf_info *elf, int secindex)
-{
-   Elf_Shdr *sechdrs = elf->sechdrs;
-   return (void *)elf->hdr +
-   elf->sechdrs[elf->secindex_strings].sh_offset +
-   sechdrs[secindex].sh_name;
-}
-
-static const char *sech_name(struct elf_info *elf, Elf_Shdr *sechdr)
-{
-   return (void *)elf->hdr +
-   elf->sechdrs[elf->secindex_strings].sh_offset +
-   sechdr->sh_name;
-}
-
 /* The pattern is an array of simple patterns.
  * "foo" will match an exact string equal to "foo"
  * "*foo" will match a string that ends with "foo"
-- 
2.7.4

[PATCH] modpost: simplify sec_name()

[Masahiro Yamada]

There is code duplication between sec_name() and sech_name().
Simplify sec_name() by re-using sech_name().  Also, move them up
to remove the forward declaration of sec_name().

Signed-off-by: Masahiro Yamada 
---

 scripts/mod/modpost.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 48397feb08fb..b920d186ad4a 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -261,7 +261,17 @@ static enum export export_no(const char *s)
return export_unknown;
 }
 
-static const char *sec_name(struct elf_info *elf, int secindex);
+static const char *sech_name(struct elf_info *elf, Elf_Shdr *sechdr)
+{
+   return (void *)elf->hdr +
+   elf->sechdrs[elf->secindex_strings].sh_offset +
+   sechdr->sh_name;
+}
+
+static const char *sec_name(struct elf_info *elf, int secindex)
+{
+   return sech_name(elf, >sechdrs[secindex]);
+}
 
 #define strstarts(str, prefix) (strncmp(str, prefix, strlen(prefix)) == 0)
 
@@ -775,21 +785,6 @@ static const char *sym_name(struct elf_info *elf, Elf_Sym 
*sym)
return "(unknown)";
 }
 
-static const char *sec_name(struct elf_info *elf, int secindex)
-{
-   Elf_Shdr *sechdrs = elf->sechdrs;
-   return (void *)elf->hdr +
-   elf->sechdrs[elf->secindex_strings].sh_offset +
-   sechdrs[secindex].sh_name;
-}
-
-static const char *sech_name(struct elf_info *elf, Elf_Shdr *sechdr)
-{
-   return (void *)elf->hdr +
-   elf->sechdrs[elf->secindex_strings].sh_offset +
-   sechdr->sh_name;
-}
-
 /* The pattern is an array of simple patterns.
  * "foo" will match an exact string equal to "foo"
  * "*foo" will match a string that ends with "foo"
-- 
2.7.4

linux-next: build warning after merge of the md tree

[Stephen Rothwell]

Hi Shaohua,

After merging the md tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

drivers/md/raid5-cache.c: In function 'r5c_journal_mode_show':
drivers/md/raid5-cache.c:2535:2: warning: ignoring return value of 
'mddev_lock', declared with attribute warn_unused_result [-Wunused-result]
  mddev_lock(mddev);
  ^

Introduced by commit

  7f7abe0ec5bb ("md/r5cache: call mddev_lock/unlock() in r5c_journal_mode_show")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the md tree

[Stephen Rothwell]

Hi Shaohua,

After merging the md tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

drivers/md/raid5-cache.c: In function 'r5c_journal_mode_show':
drivers/md/raid5-cache.c:2535:2: warning: ignoring return value of 
'mddev_lock', declared with attribute warn_unused_result [-Wunused-result]
  mddev_lock(mddev);
  ^

Introduced by commit

  7f7abe0ec5bb ("md/r5cache: call mddev_lock/unlock() in r5c_journal_mode_show")

-- 
Cheers,
Stephen Rothwell