Re: [PATCH][next] can: etas_es58x: Fix potential null pointer dereference on pointer cf

[Colin Ian King]

On 15/04/2021 10:03, Marc Kleine-Budde wrote:
> On 15.04.2021 09:55:35, Colin King wrote:
>> From: Colin Ian King 
>>
>> The pointer cf is being null checked earlier in the code, however the
>> update of the rx_bytes statistics is dereferencing cf without null
>> checking cf.  Fix this by moving the statement into the following code
>> block that has a null cf check.
>>
>> Addresses-Coverity: ("Dereference after null check")
>> Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN 
>> USB interfaces")
>> Signed-off-by: Colin Ian King 
> 
> A somewhat different fix is already in net-next/master
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=e2b1e4b532abdd39bfb7313146153815e370d60c

+1 on that

> 
> Marc
> 

Re: [PATCH][next] can: etas_es58x: Fix potential null pointer dereference on pointer cf

[Marc Kleine-Budde]

On 15.04.2021 09:55:35, Colin King wrote:
> From: Colin Ian King 
> 
> The pointer cf is being null checked earlier in the code, however the
> update of the rx_bytes statistics is dereferencing cf without null
> checking cf.  Fix this by moving the statement into the following code
> block that has a null cf check.
> 
> Addresses-Coverity: ("Dereference after null check")
> Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN 
> USB interfaces")
> Signed-off-by: Colin Ian King 

A somewhat different fix is already in net-next/master

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=e2b1e4b532abdd39bfb7313146153815e370d60c

Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |


signature.asc
Description: PGP signature

[PATCH][next] can: etas_es58x: Fix potential null pointer dereference on pointer cf

[Colin King]

From: Colin Ian King 

The pointer cf is being null checked earlier in the code, however the
update of the rx_bytes statistics is dereferencing cf without null
checking cf.  Fix this by moving the statement into the following code
block that has a null cf check.

Addresses-Coverity: ("Dereference after null check")
Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB 
interfaces")
Signed-off-by: Colin Ian King 
---
 drivers/net/can/usb/etas_es58x/es58x_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.c 
b/drivers/net/can/usb/etas_es58x/es58x_core.c
index 7222b3b6ca46..5198e1d6b6ad 100644
--- a/drivers/net/can/usb/etas_es58x/es58x_core.c
+++ b/drivers/net/can/usb/etas_es58x/es58x_core.c
@@ -856,9 +856,10 @@ int es58x_rx_err_msg(struct net_device *netdev, enum 
es58x_err error,
 * consistency.
 */
netdev->stats.rx_packets++;
-   netdev->stats.rx_bytes += cf->can_dlc;
 
if (cf) {
+   netdev->stats.rx_bytes += cf->can_dlc;
+
if (cf->data[1])
cf->can_id |= CAN_ERR_CRTL;
if (cf->data[2] || cf->data[3]) {
-- 
2.30.2

Re: [PATCH -next] memory: fsl-corenet-cf: Remove redundant dev_err call in ccf_probe()

[Krzysztof Kozlowski]

On Wed, 31 Mar 2021 17:32:44 +0800, Qiheng Lin wrote:
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.

Applied, thanks!

[1/1] memory: fsl-corenet-cf: Remove redundant dev_err call in ccf_probe()
  commit: b11a188aef6d19fe3ca505831d9c627ef683476f

Best regards,
-- 
Krzysztof Kozlowski 

[PATCH -next] memory: fsl-corenet-cf: Remove redundant dev_err call in ccf_probe()

[Qiheng Lin]

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Reported-by: Hulk Robot 
Signed-off-by: Qiheng Lin 
---
 drivers/memory/fsl-corenet-cf.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet-cf.c
index 0309bd5a1800..e15c962d4540 100644
--- a/drivers/memory/fsl-corenet-cf.c
+++ b/drivers/memory/fsl-corenet-cf.c
@@ -192,10 +192,8 @@ static int ccf_probe(struct platform_device *pdev)
}
 
ccf->regs = devm_ioremap_resource(>dev, r);
-   if (IS_ERR(ccf->regs)) {
-   dev_err(>dev, "%s: can't map mem resource\n", __func__);
+   if (IS_ERR(ccf->regs))
return PTR_ERR(ccf->regs);
-   }
 
ccf->dev = >dev;
ccf->info = match->data;

CF.- HELLO I HAVE A FINANCIAL PROPOSAL FOR YOU

[Matthew ADE]

[PATCH 4.4 074/112] memory: fsl-corenet-cf: Fix handling of platform_get_irq() error

[Greg Kroah-Hartman]

From: Krzysztof Kozlowski 

[ Upstream commit dd85345abca60a8916617e8d75c0f9ce334336dd ]

platform_get_irq() returns -ERRNO on error.  In such case comparison
to 0 would pass the check.

Fixes: 54afbec0d57f ("memory: Freescale CoreNet Coherency Fabric error 
reporting driver")
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20200827073315.29351-1-k...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/memory/fsl-corenet-cf.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet-cf.c
index 662d050243bec..2fbf8d09af36b 100644
--- a/drivers/memory/fsl-corenet-cf.c
+++ b/drivers/memory/fsl-corenet-cf.c
@@ -215,10 +215,8 @@ static int ccf_probe(struct platform_device *pdev)
dev_set_drvdata(>dev, ccf);
 
irq = platform_get_irq(pdev, 0);
-   if (!irq) {
-   dev_err(>dev, "%s: no irq\n", __func__);
-   return -ENXIO;
-   }
+   if (irq < 0)
+   return irq;
 
ret = devm_request_irq(>dev, irq, ccf_irq, 0, pdev->name, ccf);
if (ret) {
-- 
2.25.1

[PATCH 4.14 127/191] memory: fsl-corenet-cf: Fix handling of platform_get_irq() error

[Greg Kroah-Hartman]

From: Krzysztof Kozlowski 

[ Upstream commit dd85345abca60a8916617e8d75c0f9ce334336dd ]

platform_get_irq() returns -ERRNO on error.  In such case comparison
to 0 would pass the check.

Fixes: 54afbec0d57f ("memory: Freescale CoreNet Coherency Fabric error 
reporting driver")
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20200827073315.29351-1-k...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/memory/fsl-corenet-cf.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet-cf.c
index 662d050243bec..2fbf8d09af36b 100644
--- a/drivers/memory/fsl-corenet-cf.c
+++ b/drivers/memory/fsl-corenet-cf.c
@@ -215,10 +215,8 @@ static int ccf_probe(struct platform_device *pdev)
dev_set_drvdata(>dev, ccf);
 
irq = platform_get_irq(pdev, 0);
-   if (!irq) {
-   dev_err(>dev, "%s: no irq\n", __func__);
-   return -ENXIO;
-   }
+   if (irq < 0)
+   return irq;
 
ret = devm_request_irq(>dev, irq, ccf_irq, 0, pdev->name, ccf);
if (ret) {
-- 
2.25.1

[PATCH 5.8 490/633] memory: fsl-corenet-cf: Fix handling of platform_get_irq() error

[Greg Kroah-Hartman]

From: Krzysztof Kozlowski 

[ Upstream commit dd85345abca60a8916617e8d75c0f9ce334336dd ]

platform_get_irq() returns -ERRNO on error.  In such case comparison
to 0 would pass the check.

Fixes: 54afbec0d57f ("memory: Freescale CoreNet Coherency Fabric error 
reporting driver")
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20200827073315.29351-1-k...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/memory/fsl-corenet-cf.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet-cf.c
index 0b0ed72016da8..0309bd5a18008 100644
--- a/drivers/memory/fsl-corenet-cf.c
+++ b/drivers/memory/fsl-corenet-cf.c
@@ -211,10 +211,8 @@ static int ccf_probe(struct platform_device *pdev)
dev_set_drvdata(>dev, ccf);
 
irq = platform_get_irq(pdev, 0);
-   if (!irq) {
-   dev_err(>dev, "%s: no irq\n", __func__);
-   return -ENXIO;
-   }
+   if (irq < 0)
+   return irq;
 
ret = devm_request_irq(>dev, irq, ccf_irq, 0, pdev->name, ccf);
if (ret) {
-- 
2.25.1

[PATCH 5.9 596/757] memory: fsl-corenet-cf: Fix handling of platform_get_irq() error

[Greg Kroah-Hartman]

From: Krzysztof Kozlowski 

[ Upstream commit dd85345abca60a8916617e8d75c0f9ce334336dd ]

platform_get_irq() returns -ERRNO on error.  In such case comparison
to 0 would pass the check.

Fixes: 54afbec0d57f ("memory: Freescale CoreNet Coherency Fabric error 
reporting driver")
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20200827073315.29351-1-k...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/memory/fsl-corenet-cf.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet-cf.c
index 0b0ed72016da8..0309bd5a18008 100644
--- a/drivers/memory/fsl-corenet-cf.c
+++ b/drivers/memory/fsl-corenet-cf.c
@@ -211,10 +211,8 @@ static int ccf_probe(struct platform_device *pdev)
dev_set_drvdata(>dev, ccf);
 
irq = platform_get_irq(pdev, 0);
-   if (!irq) {
-   dev_err(>dev, "%s: no irq\n", __func__);
-   return -ENXIO;
-   }
+   if (irq < 0)
+   return irq;
 
ret = devm_request_irq(>dev, irq, ccf_irq, 0, pdev->name, ccf);
if (ret) {
-- 
2.25.1

[PATCH 5.4 303/408] memory: fsl-corenet-cf: Fix handling of platform_get_irq() error

[Greg Kroah-Hartman]

From: Krzysztof Kozlowski 

[ Upstream commit dd85345abca60a8916617e8d75c0f9ce334336dd ]

platform_get_irq() returns -ERRNO on error.  In such case comparison
to 0 would pass the check.

Fixes: 54afbec0d57f ("memory: Freescale CoreNet Coherency Fabric error 
reporting driver")
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20200827073315.29351-1-k...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/memory/fsl-corenet-cf.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet-cf.c
index 0b0ed72016da8..0309bd5a18008 100644
--- a/drivers/memory/fsl-corenet-cf.c
+++ b/drivers/memory/fsl-corenet-cf.c
@@ -211,10 +211,8 @@ static int ccf_probe(struct platform_device *pdev)
dev_set_drvdata(>dev, ccf);
 
irq = platform_get_irq(pdev, 0);
-   if (!irq) {
-   dev_err(>dev, "%s: no irq\n", __func__);
-   return -ENXIO;
-   }
+   if (irq < 0)
+   return irq;
 
ret = devm_request_irq(>dev, irq, ccf_irq, 0, pdev->name, ccf);
if (ret) {
-- 
2.25.1

[PATCH 4.19 195/264] memory: fsl-corenet-cf: Fix handling of platform_get_irq() error

[Greg Kroah-Hartman]

From: Krzysztof Kozlowski 

[ Upstream commit dd85345abca60a8916617e8d75c0f9ce334336dd ]

platform_get_irq() returns -ERRNO on error.  In such case comparison
to 0 would pass the check.

Fixes: 54afbec0d57f ("memory: Freescale CoreNet Coherency Fabric error 
reporting driver")
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20200827073315.29351-1-k...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/memory/fsl-corenet-cf.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet-cf.c
index 662d050243bec..2fbf8d09af36b 100644
--- a/drivers/memory/fsl-corenet-cf.c
+++ b/drivers/memory/fsl-corenet-cf.c
@@ -215,10 +215,8 @@ static int ccf_probe(struct platform_device *pdev)
dev_set_drvdata(>dev, ccf);
 
irq = platform_get_irq(pdev, 0);
-   if (!irq) {
-   dev_err(>dev, "%s: no irq\n", __func__);
-   return -ENXIO;
-   }
+   if (irq < 0)
+   return irq;
 
ret = devm_request_irq(>dev, irq, ccf_irq, 0, pdev->name, ccf);
if (ret) {
-- 
2.25.1

[PATCH 4.9 088/139] memory: fsl-corenet-cf: Fix handling of platform_get_irq() error

[Greg Kroah-Hartman]

From: Krzysztof Kozlowski 

[ Upstream commit dd85345abca60a8916617e8d75c0f9ce334336dd ]

platform_get_irq() returns -ERRNO on error.  In such case comparison
to 0 would pass the check.

Fixes: 54afbec0d57f ("memory: Freescale CoreNet Coherency Fabric error 
reporting driver")
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20200827073315.29351-1-k...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/memory/fsl-corenet-cf.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet-cf.c
index 662d050243bec..2fbf8d09af36b 100644
--- a/drivers/memory/fsl-corenet-cf.c
+++ b/drivers/memory/fsl-corenet-cf.c
@@ -215,10 +215,8 @@ static int ccf_probe(struct platform_device *pdev)
dev_set_drvdata(>dev, ccf);
 
irq = platform_get_irq(pdev, 0);
-   if (!irq) {
-   dev_err(>dev, "%s: no irq\n", __func__);
-   return -ENXIO;
-   }
+   if (irq < 0)
+   return irq;
 
ret = devm_request_irq(>dev, irq, ccf_irq, 0, pdev->name, ccf);
if (ret) {
-- 
2.25.1

Re: [PATCH] drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy

[Alex Dewar]

Hmm, I applied this already:
commit 33f290811d4c1a09c4e92f5bf0458525835dbcba
Author: Alex Dewar 
Date:   Wed Sep 9 20:02:08 2020 +0100

 drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy

 kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
 this pattern.

 Issue identified with Coccinelle.

 Signed-off-by: Alex Dewar 
 Acked-by: Neil Armstrong 
 Signed-off-by: Neil Armstrong 
 Link: 
https://patchwork.freedesktop.org/patch/msgid/20200909190213.156302-1-alex.dewa...@gmail.com

Neil

Sorry! My bad. Thanks for applying :)

Alex

Re: [PATCH] drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy

[Neil Armstrong]

On 20/09/2020 10:24, Daniel Vetter wrote:
> On Sat, Sep 19, 2020 at 9:31 PM Alex Dewar  wrote:
>>
>> On 2020-09-11 13:57, Neil Armstrong wrote:
>>> On 09/09/2020 21:02, Alex Dewar wrote:
>>>> kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
>>>> this pattern.
>> Friendly ping?
>>>>
>>>> Issue identified with Coccinelle.
>>>>
>>>> Signed-off-by: Alex Dewar 
>>>> ---
>>>>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
>>>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
>>>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>>> index 52f5c5a2ed64..7e9a62ad56e8 100644
>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>>> @@ -1049,12 +1049,10 @@ static void debugfs_create_files(void *data)
>>>>  };
>>>>  int i;
>>>>
>>>> -dsi->debugfs_vpg = kmalloc(sizeof(debugfs), GFP_KERNEL);
>>>> +dsi->debugfs_vpg = kmemdup(debugfs, sizeof(debugfs), GFP_KERNEL);
>>>>  if (!dsi->debugfs_vpg)
>>>>  return;
>>>>
>>>> -memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs));
>>>> -
>>>>  for (i = 0; i < ARRAY_SIZE(debugfs); i++)
>>>>  debugfs_create_file(dsi->debugfs_vpg[i].name, 0644,
>>>>  dsi->debugfs, >debugfs_vpg[i],
>>>>
>>> Acked-by: Neil Armstrong 
> 
> Neil has commit rights, so I was assuming he'd push this to drm-misc-next.
> -Daniel
> 

Hmm, I applied this already:
commit 33f290811d4c1a09c4e92f5bf0458525835dbcba
Author: Alex Dewar 
Date:   Wed Sep 9 20:02:08 2020 +0100

drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy

kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
this pattern.

Issue identified with Coccinelle.

Signed-off-by: Alex Dewar 
Acked-by: Neil Armstrong 
Signed-off-by: Neil Armstrong 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20200909190213.156302-1-alex.dewa...@gmail.com

Neil

Re: [PATCH] drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy

[Neil Armstrong]

On 20/09/2020 10:24, Daniel Vetter wrote:
> On Sat, Sep 19, 2020 at 9:31 PM Alex Dewar  wrote:
>>
>> On 2020-09-11 13:57, Neil Armstrong wrote:
>>> On 09/09/2020 21:02, Alex Dewar wrote:
 kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
 this pattern.
>> Friendly ping?

 Issue identified with Coccinelle.

 Signed-off-by: Alex Dewar 
 ---
   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
   1 file changed, 1 insertion(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
 b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 index 52f5c5a2ed64..7e9a62ad56e8 100644
 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 @@ -1049,12 +1049,10 @@ static void debugfs_create_files(void *data)
  };
  int i;

 -dsi->debugfs_vpg = kmalloc(sizeof(debugfs), GFP_KERNEL);
 +dsi->debugfs_vpg = kmemdup(debugfs, sizeof(debugfs), GFP_KERNEL);
  if (!dsi->debugfs_vpg)
  return;

 -memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs));
 -
  for (i = 0; i < ARRAY_SIZE(debugfs); i++)
  debugfs_create_file(dsi->debugfs_vpg[i].name, 0644,
  dsi->debugfs, >debugfs_vpg[i],

>>> Acked-by: Neil Armstrong 
> 
> Neil has commit rights, so I was assuming he'd push this to drm-misc-next.
> -Daniel
> 

Applying now,
Neil

Re: [PATCH] drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy

[Daniel Vetter]

On Sat, Sep 19, 2020 at 9:31 PM Alex Dewar  wrote:
>
> On 2020-09-11 13:57, Neil Armstrong wrote:
> > On 09/09/2020 21:02, Alex Dewar wrote:
> >> kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
> >> this pattern.
> Friendly ping?
> >>
> >> Issue identified with Coccinelle.
> >>
> >> Signed-off-by: Alex Dewar 
> >> ---
> >>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
> >>   1 file changed, 1 insertion(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> >> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> index 52f5c5a2ed64..7e9a62ad56e8 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> @@ -1049,12 +1049,10 @@ static void debugfs_create_files(void *data)
> >>  };
> >>  int i;
> >>
> >> -dsi->debugfs_vpg = kmalloc(sizeof(debugfs), GFP_KERNEL);
> >> +dsi->debugfs_vpg = kmemdup(debugfs, sizeof(debugfs), GFP_KERNEL);
> >>  if (!dsi->debugfs_vpg)
> >>  return;
> >>
> >> -memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs));
> >> -
> >>  for (i = 0; i < ARRAY_SIZE(debugfs); i++)
> >>  debugfs_create_file(dsi->debugfs_vpg[i].name, 0644,
> >>  dsi->debugfs, >debugfs_vpg[i],
> >>
> > Acked-by: Neil Armstrong 

Neil has commit rights, so I was assuming he'd push this to drm-misc-next.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy

[Alex Dewar]

On 2020-09-11 13:57, Neil Armstrong wrote:

On 09/09/2020 21:02, Alex Dewar wrote:

kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
this pattern.

Friendly ping?


Issue identified with Coccinelle.

Signed-off-by: Alex Dewar 
---
  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 52f5c5a2ed64..7e9a62ad56e8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -1049,12 +1049,10 @@ static void debugfs_create_files(void *data)
};
int i;
  
-	dsi->debugfs_vpg = kmalloc(sizeof(debugfs), GFP_KERNEL);

+   dsi->debugfs_vpg = kmemdup(debugfs, sizeof(debugfs), GFP_KERNEL);
if (!dsi->debugfs_vpg)
return;
  
-	memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs));

-
for (i = 0; i < ARRAY_SIZE(debugfs); i++)
debugfs_create_file(dsi->debugfs_vpg[i].name, 0644,
dsi->debugfs, >debugfs_vpg[i],


Acked-by: Neil Armstrong 

Thanks,
Neil

Re: [PATCH] drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy

[Neil Armstrong]

On 09/09/2020 21:02, Alex Dewar wrote:
> kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
> this pattern.
> 
> Issue identified with Coccinelle.
> 
> Signed-off-by: Alex Dewar 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 52f5c5a2ed64..7e9a62ad56e8 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -1049,12 +1049,10 @@ static void debugfs_create_files(void *data)
>   };
>   int i;
>  
> - dsi->debugfs_vpg = kmalloc(sizeof(debugfs), GFP_KERNEL);
> + dsi->debugfs_vpg = kmemdup(debugfs, sizeof(debugfs), GFP_KERNEL);
>   if (!dsi->debugfs_vpg)
>   return;
>  
> - memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs));
> -
>   for (i = 0; i < ARRAY_SIZE(debugfs); i++)
>   debugfs_create_file(dsi->debugfs_vpg[i].name, 0644,
>   dsi->debugfs, >debugfs_vpg[i],
> 

Acked-by: Neil Armstrong 

Thanks,
Neil

[PATCH] drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy

[Alex Dewar]

kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
this pattern.

Issue identified with Coccinelle.

Signed-off-by: Alex Dewar 
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 52f5c5a2ed64..7e9a62ad56e8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -1049,12 +1049,10 @@ static void debugfs_create_files(void *data)
};
int i;
 
-   dsi->debugfs_vpg = kmalloc(sizeof(debugfs), GFP_KERNEL);
+   dsi->debugfs_vpg = kmemdup(debugfs, sizeof(debugfs), GFP_KERNEL);
if (!dsi->debugfs_vpg)
return;
 
-   memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs));
-
for (i = 0; i < ARRAY_SIZE(debugfs); i++)
debugfs_create_file(dsi->debugfs_vpg[i].name, 0644,
dsi->debugfs, >debugfs_vpg[i],
-- 
2.28.0

Re: [PATCH] memory: fsl-corenet-cf: Fix handling of platform_get_irq() error

[Krzysztof Kozlowski]

On Thu, Aug 27, 2020 at 09:33:15AM +0200, Krzysztof Kozlowski wrote:
> platform_get_irq() returns -ERRNO on error.  In such case comparison
> to 0 would pass the check.
> 
> Fixes: 54afbec0d57f ("memory: Freescale CoreNet Coherency Fabric error 
> reporting driver")
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/memory/fsl-corenet-cf.c | 6 ++

Applied.

Best regards,
Krzysztof

[PATCH] memory: fsl-corenet-cf: Fix handling of platform_get_irq() error

[Krzysztof Kozlowski]

platform_get_irq() returns -ERRNO on error.  In such case comparison
to 0 would pass the check.

Fixes: 54afbec0d57f ("memory: Freescale CoreNet Coherency Fabric error 
reporting driver")
Signed-off-by: Krzysztof Kozlowski 
---
 drivers/memory/fsl-corenet-cf.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet-cf.c
index 0b0ed72016da..0309bd5a1800 100644
--- a/drivers/memory/fsl-corenet-cf.c
+++ b/drivers/memory/fsl-corenet-cf.c
@@ -211,10 +211,8 @@ static int ccf_probe(struct platform_device *pdev)
dev_set_drvdata(>dev, ccf);
 
irq = platform_get_irq(pdev, 0);
-   if (!irq) {
-   dev_err(>dev, "%s: no irq\n", __func__);
-   return -ENXIO;
-   }
+   if (irq < 0)
+   return irq;
 
ret = devm_request_irq(>dev, irq, ccf_irq, 0, pdev->name, ccf);
if (ret) {
-- 
2.17.1

Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

[Michael .]

Have just had confirmation that the mmc_ricoh_mmc change works and
both PCMCIA slots now work as intended on Panasonic Toughbook CF-29 Mk
4 and 5.

Thank you to all who have made suggestions for this, your dedication
to Linux is amazing and your help with this is appreciated.

Stay safe.
Michael.

On 28/07/2020, Michael .  wrote:
> I have just compiled and uploaded a kernel to test for this issue,
> members of the Toughbook community have been provided with the link,
> though a forum discussion, to download the kernel and test it.
> Hopefully we will get positive results and can confirm the
> MMC_RICOH_MMC flag is the culprit.
> Regards.
> Stay safe.
> Michael.
>
> On 27/02/2020, bluerocksadd...@willitsonline.com
>  wrote:
>> Somewhere in these messages is a cluein that SD reader was involved.
>>
>> MK 4 and 5 have SD whilst MK 1, 2 and three do not.
>>
>>
>>
>> On 2020-02-25 22:10, Michael . wrote:
>>>> Someone with access to real hardware could
>>>> easily experiment with changing that magic value and seeing if it
>>>> changes which function is disabled.
>>>
>>> One of our members has offered to supply a machine to a dev that can
>>> use it to test any theory.
>>>
>>> It is nearly beyond the scope of the majority of us to do much more
>>> than just testing. We appreciate all the effort the devs put in and
>>> are willing to help in anyway we can but we aren't kernel devs.
>>>
>>> I, personally, use Debian. Others use Debian based distros such as MX
>>> and Mint. We have been able to test many different distros such as
>>> those listed in other comments but don't have the skills or expertise
>>> to do much more. It is our hope that this discussion and subsequent
>>> effort may enable others who prefer distros other than Debian based
>>> distros can use a CF-29 (and possibly earlier) Toughbook with the
>>> distro of their choice without having to rebuild a kernel so they can
>>> use hardware that worked back in 2010. To do this the fix needs to be
>>> at the kernel dev level not a local enthusiast level because while I
>>> can rebuild a Debian kernel I can't rebuild a Fedora or Arch or
>>> Slackware kernel.
>>>
>>> I did a search about this issue before I made initial contact late
>>> last year and the issue was discovered on more than Toughbooks and
>>> posted about on various sites not long after distros moved from
>>> 2.6.32. It seems back then people just got new machines that didn't
>>> have a 2nd slot so the search for an answer stopped. Us Toughbook
>>> users are a loyal group we use our machines because they are exactly
>>> what we need and they take alot of "punishment" taht other machines
>>> simply cannot handle. Our machines are used rather than recycled or
>>> worse still just left to sit in waste management facilities in a
>>> country that the western world dumps its rubbish in, we are Linux and
>>> Toughbook enthusiasts and hope to be able to keep our machines running
>>> for many years to come with all their native capabilities working as
>>> they were designed to but using a modern Linux instead of Windows XP
>>> or Windows 7. (that wasn't a pep talk, its just an explanation of why
>>> we are passionate about this).
>>>
>>> Let us know what you need us to do, we will let you know if we are
>>> capable of it and give you any feedback you ask for. Over the weekend
>>> I will try to rebuild a Debian kernel with the relevant option
>>> disabled, provide it to my peers for testing and report back here what
>>> the outcome is.
>>>
>>> Thank you all for all your time and effort, it is truly appreciated.
>>> Cheers.
>>> Michael.
>>>
>>> On 26/02/2020, Philip Langdale  wrote:
>>>> On Tue, 25 Feb 2020 23:51:05 -0500
>>>> Arvind Sankar  wrote:
>>>>
>>>>> On Tue, Feb 25, 2020 at 09:12:48PM -0600, Trevor Jacobs wrote:
>>>>> > That's correct, I tested a bunch of the old distros including
>>>>> > slackware, and 2.6.32 is where the problem began.
>>>>> >
>>>>> > Also, the Panasonic Toughbook CF-29s effected that we tested are
>>>>> > the later marks, MK4 and MK5 for certain. The MK2 CF-29 worked just
>>>>> > fine because it has different hardware supporting the PCMCIA slots.
>>>>> > I have not tested a MK3 but suspect it would work ok as it also
>>>>> > uses the older hard

Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

[Michael .]

I have just compiled and uploaded a kernel to test for this issue,
members of the Toughbook community have been provided with the link,
though a forum discussion, to download the kernel and test it.
Hopefully we will get positive results and can confirm the
MMC_RICOH_MMC flag is the culprit.
Regards.
Stay safe.
Michael.

On 27/02/2020, bluerocksadd...@willitsonline.com
 wrote:
> Somewhere in these messages is a cluein that SD reader was involved.
>
> MK 4 and 5 have SD whilst MK 1, 2 and three do not.
>
>
>
> On 2020-02-25 22:10, Michael . wrote:
>>> Someone with access to real hardware could
>>> easily experiment with changing that magic value and seeing if it
>>> changes which function is disabled.
>>
>> One of our members has offered to supply a machine to a dev that can
>> use it to test any theory.
>>
>> It is nearly beyond the scope of the majority of us to do much more
>> than just testing. We appreciate all the effort the devs put in and
>> are willing to help in anyway we can but we aren't kernel devs.
>>
>> I, personally, use Debian. Others use Debian based distros such as MX
>> and Mint. We have been able to test many different distros such as
>> those listed in other comments but don't have the skills or expertise
>> to do much more. It is our hope that this discussion and subsequent
>> effort may enable others who prefer distros other than Debian based
>> distros can use a CF-29 (and possibly earlier) Toughbook with the
>> distro of their choice without having to rebuild a kernel so they can
>> use hardware that worked back in 2010. To do this the fix needs to be
>> at the kernel dev level not a local enthusiast level because while I
>> can rebuild a Debian kernel I can't rebuild a Fedora or Arch or
>> Slackware kernel.
>>
>> I did a search about this issue before I made initial contact late
>> last year and the issue was discovered on more than Toughbooks and
>> posted about on various sites not long after distros moved from
>> 2.6.32. It seems back then people just got new machines that didn't
>> have a 2nd slot so the search for an answer stopped. Us Toughbook
>> users are a loyal group we use our machines because they are exactly
>> what we need and they take alot of "punishment" taht other machines
>> simply cannot handle. Our machines are used rather than recycled or
>> worse still just left to sit in waste management facilities in a
>> country that the western world dumps its rubbish in, we are Linux and
>> Toughbook enthusiasts and hope to be able to keep our machines running
>> for many years to come with all their native capabilities working as
>> they were designed to but using a modern Linux instead of Windows XP
>> or Windows 7. (that wasn't a pep talk, its just an explanation of why
>> we are passionate about this).
>>
>> Let us know what you need us to do, we will let you know if we are
>> capable of it and give you any feedback you ask for. Over the weekend
>> I will try to rebuild a Debian kernel with the relevant option
>> disabled, provide it to my peers for testing and report back here what
>> the outcome is.
>>
>> Thank you all for all your time and effort, it is truly appreciated.
>> Cheers.
>> Michael.
>>
>> On 26/02/2020, Philip Langdale  wrote:
>>> On Tue, 25 Feb 2020 23:51:05 -0500
>>> Arvind Sankar  wrote:
>>>
>>>> On Tue, Feb 25, 2020 at 09:12:48PM -0600, Trevor Jacobs wrote:
>>>> > That's correct, I tested a bunch of the old distros including
>>>> > slackware, and 2.6.32 is where the problem began.
>>>> >
>>>> > Also, the Panasonic Toughbook CF-29s effected that we tested are
>>>> > the later marks, MK4 and MK5 for certain. The MK2 CF-29 worked just
>>>> > fine because it has different hardware supporting the PCMCIA slots.
>>>> > I have not tested a MK3 but suspect it would work ok as it also
>>>> > uses the older hardware.
>>>> >
>>>> > Thanks for your help guys!
>>>> > Trevor
>>>> >
>>>>
>>>> Right, the distros probably all enabled MMC_RICOH_MMC earlier than
>>>> upstream. Can you test a custom kernel based off your distro kernel
>>>> but just disabling that config option? That's probably the easiest
>>>> fix
>>>> currently, even though not ideal. Perhaps there should be a command
>>>> line option to disable specific pci quirks to make this easier.
>>>>
>>>> An ideal fix is I feel hard, given this q

Re: [PATCH] fsi: master-ast-cf: fix spelling mistake "firwmare" -> "firmware"

[Andrew Jeffery]

On Wed, 3 Jun 2020, at 21:35, Colin King wrote:
> From: Colin Ian King 
> 
> There is a spelling mistake in a dev_err error message. Fix it.
> 
> Signed-off-by: Colin Ian King 

Reviewed-by: Andrew Jeffery 

[PATCH] fsi: master-ast-cf: fix spelling mistake "firwmare" -> "firmware"

[Colin King]

From: Colin Ian King 

There is a spelling mistake in a dev_err error message. Fix it.

Signed-off-by: Colin Ian King 
---
 drivers/fsi/fsi-master-ast-cf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
index 04d10ea8d343..85d9be38b32b 100644
--- a/drivers/fsi/fsi-master-ast-cf.c
+++ b/drivers/fsi/fsi-master-ast-cf.c
@@ -838,7 +838,7 @@ static int load_copro_firmware(struct fsi_master_acf 
*master)
rc = request_firmware(, FW_FILE_NAME, master->dev);
if (rc) {
dev_err(
-   master->dev, "Error %d to load firwmare '%s' !\n",
+   master->dev, "Error %d to load firmware '%s' !\n",
rc, FW_FILE_NAME);
return rc;
}
-- 
2.25.1

Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

[Michael .]

Thanks Domunik I'll get onto this and report back the results.

On 22/10/2019, Dominik Brodowski  wrote:
> On Tue, Oct 22, 2019 at 05:17:12AM +1100, Michael . wrote:
>> Thank you Dominik for looking at this for us and passing it on.
>>
>> Good morning Bjorn, thank you also for looking into this for us and
>> thank you for CCing us into this as non of us are on the mailing list.
>> One question how do we apply this patch or is this for Dominik to try?
>
> That's for you and/or other users of this hardware; I cannot test this
> myself, sorry. As to how to apply the patch: you'd need to apply the patch
> for the linux kernel sources, and then build a custom kernel. Some hints on
> that (details depend on the distribtion):
>
>   https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
>   https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
>   https://wiki.archlinux.org/index.php/Kernels/Arch_Build_System
>   https://kernelnewbies.org/KernelBuild
>
> Best,
>   Dominik
>

Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

[Dominik Brodowski]

On Tue, Oct 22, 2019 at 05:17:12AM +1100, Michael . wrote:
> Thank you Dominik for looking at this for us and passing it on.
> 
> Good morning Bjorn, thank you also for looking into this for us and
> thank you for CCing us into this as non of us are on the mailing list.
> One question how do we apply this patch or is this for Dominik to try?

That's for you and/or other users of this hardware; I cannot test this
myself, sorry. As to how to apply the patch: you'd need to apply the patch
for the linux kernel sources, and then build a custom kernel. Some hints on
that (details depend on the distribtion):

https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
https://wiki.archlinux.org/index.php/Kernels/Arch_Build_System
https://kernelnewbies.org/KernelBuild

Best,
Dominik

Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

[Michael .]

Thank you Dominik for looking at this for us and passing it on.

Good morning Bjorn, thank you also for looking into this for us and
thank you for CCing us into this as non of us are on the mailing list.
One question how do we apply this patch or is this for Dominik to try?

Cheers.
Michael

On 22/10/2019, Bjorn Helgaas  wrote:
> On Sun, Oct 20, 2019 at 11:08:00AM +0200, Dominik Brodowski wrote:
>> On the basis of the additional information (thanks), there might be a
>> more specific path to investigate: It is that the PCI code does not
>> enumerate the second cardbus bridge PCI function in the more recent 4.19
>> kernel compared to the anvient (and working) 2.6 kernel.
>>
>> Namely, only one CardBus bridge is recognized
>>
>> ...
>> 06:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
>> 06:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host
>> Adapter (rev 11)
>> 06:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG
>> [Calexico2] Network Connection (rev 05)
>> ...
>>
>> instead of the two which really should be present:
>>
>> ...
>> 06:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
>> 06:01.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
>> 06:01.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host
>> Adapter (rev 11)
>> 06:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG
>> [Calexico2] Network Connection (rev 05)
>> ...
>>
>> To the PCI folks: any idea on what may cause the second cardbus bridge
>> PCI
>> device function to be missed? Are there any command line options the
>> users
>> who reported this issue[*] may try?
>
> Thanks for the report.  Could you try disabling
> ricoh_mmc_fixup_rl5c476(), e.g., with the patch below (this is based
> on v5.4-rc1, but you can use v4.9 if that's easier for you)?  This
> isn't a fix; it's just something that looks like it might be related.
>
>> [*] For more information, see this thread:
>>  
>> https://lore.kernel.org/lkml/cafjuqni+knsb9wvqoahcvfyxsiqoggwom7z1aqdbebnzp_-...@mail.gmail.com/
>
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 320255e5e8f8..7a1e1a242506 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3036,38 +3036,6 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HINT, 0x0020,
> quirk_hotplug_bridge);
>   * #1, and this will confuse the PCI core.
>   */
>  #ifdef CONFIG_MMC_RICOH_MMC
> -static void ricoh_mmc_fixup_rl5c476(struct pci_dev *dev)
> -{
> - u8 write_enable;
> - u8 write_target;
> - u8 disable;
> -
> - /*
> -  * Disable via CardBus interface
> -  *
> -  * This must be done via function #0
> -  */
> - if (PCI_FUNC(dev->devfn))
> - return;
> -
> - pci_read_config_byte(dev, 0xB7, );
> - if (disable & 0x02)
> - return;
> -
> - pci_read_config_byte(dev, 0x8E, _enable);
> - pci_write_config_byte(dev, 0x8E, 0xAA);
> - pci_read_config_byte(dev, 0x8D, _target);
> - pci_write_config_byte(dev, 0x8D, 0xB7);
> - pci_write_config_byte(dev, 0xB7, disable | 0x02);
> - pci_write_config_byte(dev, 0x8E, write_enable);
> - pci_write_config_byte(dev, 0x8D, write_target);
> -
> - pci_notice(dev, "proprietary Ricoh MMC controller disabled (via CardBus
> function)\n");
> - pci_notice(dev, "MMC cards are now supported by standard SDHCI
> controller\n");
> -}
> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_RL5C476,
> ricoh_mmc_fixup_rl5c476);
> -DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH,
> PCI_DEVICE_ID_RICOH_RL5C476, ricoh_mmc_fixup_rl5c476);
> -
>  static void ricoh_mmc_fixup_r5c832(struct pci_dev *dev)
>  {
>   u8 write_enable;
>

Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

[Bjorn Helgaas]

On Sun, Oct 20, 2019 at 11:08:00AM +0200, Dominik Brodowski wrote:
> On the basis of the additional information (thanks), there might be a
> more specific path to investigate: It is that the PCI code does not
> enumerate the second cardbus bridge PCI function in the more recent 4.19
> kernel compared to the anvient (and working) 2.6 kernel.
> 
> Namely, only one CardBus bridge is recognized
> 
> ...
> 06:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
> 06:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
> Adapter (rev 11)
> 06:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG 
> [Calexico2] Network Connection (rev 05)
> ...
> 
> instead of the two which really should be present:
> 
> ...
> 06:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
> 06:01.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
> 06:01.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
> Adapter (rev 11)
> 06:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG 
> [Calexico2] Network Connection (rev 05)
> ...
> 
> To the PCI folks: any idea on what may cause the second cardbus bridge PCI
> device function to be missed? Are there any command line options the users
> who reported this issue[*] may try?

Thanks for the report.  Could you try disabling
ricoh_mmc_fixup_rl5c476(), e.g., with the patch below (this is based
on v5.4-rc1, but you can use v4.9 if that's easier for you)?  This
isn't a fix; it's just something that looks like it might be related.

> [*] For more information, see this thread:
>   
> https://lore.kernel.org/lkml/cafjuqni+knsb9wvqoahcvfyxsiqoggwom7z1aqdbebnzp_-...@mail.gmail.com/


diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 320255e5e8f8..7a1e1a242506 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3036,38 +3036,6 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HINT, 0x0020, 
quirk_hotplug_bridge);
  * #1, and this will confuse the PCI core.
  */
 #ifdef CONFIG_MMC_RICOH_MMC
-static void ricoh_mmc_fixup_rl5c476(struct pci_dev *dev)
-{
-   u8 write_enable;
-   u8 write_target;
-   u8 disable;
-
-   /*
-* Disable via CardBus interface
-*
-* This must be done via function #0
-*/
-   if (PCI_FUNC(dev->devfn))
-   return;
-
-   pci_read_config_byte(dev, 0xB7, );
-   if (disable & 0x02)
-   return;
-
-   pci_read_config_byte(dev, 0x8E, _enable);
-   pci_write_config_byte(dev, 0x8E, 0xAA);
-   pci_read_config_byte(dev, 0x8D, _target);
-   pci_write_config_byte(dev, 0x8D, 0xB7);
-   pci_write_config_byte(dev, 0xB7, disable | 0x02);
-   pci_write_config_byte(dev, 0x8E, write_enable);
-   pci_write_config_byte(dev, 0x8D, write_target);
-
-   pci_notice(dev, "proprietary Ricoh MMC controller disabled (via CardBus 
function)\n");
-   pci_notice(dev, "MMC cards are now supported by standard SDHCI 
controller\n");
-}
-DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_RL5C476, 
ricoh_mmc_fixup_rl5c476);
-DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, 
PCI_DEVICE_ID_RICOH_RL5C476, ricoh_mmc_fixup_rl5c476);
-
 static void ricoh_mmc_fixup_r5c832(struct pci_dev *dev)
 {
u8 write_enable;

PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

[Dominik Brodowski]

On the basis of the additional information (thanks), there might be a
more specific path to investigate: It is that the PCI code does not
enumerate the second cardbus bridge PCI function in the more recent 4.19
kernel compared to the anvient (and working) 2.6 kernel.

Namely, only one CardBus bridge is recognized

...
06:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
06:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
Adapter (rev 11)
06:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG [Calexico2] 
Network Connection (rev 05)
...

instead of the two which really should be present:

...
06:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
06:01.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
06:01.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
Adapter (rev 11)
06:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG [Calexico2] 
Network Connection (rev 05)
...

To the PCI folks: any idea on what may cause the second cardbus bridge PCI
device function to be missed? Are there any command line options the users
who reported this issue[*] may try?

As this isn't really a PCMCIA (16bit) issue, but a PCI enumeration issue,
this issue is outside my area of expertise.

Thanks,
Dominik

[*] For more information, see this thread:

https://lore.kernel.org/lkml/cafjuqni+knsb9wvqoahcvfyxsiqoggwom7z1aqdbebnzp_-...@mail.gmail.com/

Re: PCMCIA not working on Panasonic Toughbook CF-29

[Michael .]

Thank you for your prompt reply Dominik, I have asked everyone in the
discussion on Notebook review to gather the information required and
either post it there so I can reply or post it here in the list if it
is from someone in the CC list.

Also thank you for replying to us all and not just on-list, none of us
are subscribed to teh list so if a reply is only on-list none of us
will receive it.

Cheers.
Michael.

On 15/10/2019, Dominik Brodowski  wrote:
> On Tue, Oct 15, 2019 at 05:04:28PM +1100, Michael . wrote:
>> Good afternoon kernel developers
>> Please accept my apology for contacting you directly about this. A
>> small group of friends, some of whom are CCed here, have come together
>> to try and find a solution to a problem that originated with the
>> demise of kernel 2.6:32. First some background to the issue. We are
>> all users of Panasonic Toughbook CF-29 models (ranging from Mark 1
>> through to Mark 5). These Toughbooks have 2 PCMCIA card slots which
>> are used by a variety of people for different purposes. On the CF-29
>> Mark 1 through to Mark 3 these slots work without problem. On the
>> CF-29 Mark 4 and Mark 5 the last known kernel the top slot worked with
>> was 2.6:32. This has been confirmed all all major distros by most of
>> the small group of friends I mentioned earlier.
>>
>> Thinking it was just a kernel config issue I did some comparisons
>> between Debian 6 (Squeeze), Debian 7 (Wheezy), Ubuntu 10.04, and
>> Ubuntu 10.10. On all machines both slots functioned as they should
>> with Debian 6 and Ubuntu 10.04 but the top slot stopped working on
>> Mark 4 and Mark 5 machines on the next release with the next kernel. I
>> also tested Ubuntu 10.04 and 10.10 with the 2.6:32 and 2.6:35 kernel
>> and both slots worked with the 2.6:32 kernel but not the 2.6:35
>> kernel.With my comparisons I merged the config from 2.6:32 into the
>> current kernel for Debian 4.19 and rebuilt the kernel, no matter what
>> configuration changes I made the top slot still doesn't function on
>> Mark 4 and Mark 5 machines.
>>
>> This issue, and its apparent start, has been confirmed on all major
>> distro family groups. So this brings me, actually the small group of
>> dedicated Linux users who own Panasonic Toughbook CF-29s, to contact
>> you to ask for help in resolving this issue. I have some questions,
>> and I realise the 2.6:32 kernel is long gone now but I'm hoping this
>> is not a lost cause, what changes would have occurred between 2.6:32
>> and 2.6:33 that would have stopped the hardware working on Mark 4 and
>> Mark 5 CF-29 Toughbooks but not Mark 1 through to Mark 3? Would it be
>> possible to correct the problem so that the hardware on our machines
>> works as it should. While we are not kernel devs or even programmers
>> we are enthusiasts who love Linux and our machines and we are hoping
>> that together with you and the kernel dev group we can fix this issue
>> together.
>>
>> I have attached various tar.gz files with ls* outputs so you can see
>> the information we have so far. Thank you for taking the time to read
>> this.
>
> Is this with 16-bit PCMCIA cards, or with 32-bit CardBus cards? Either
> case,
> please provide the output of
>
>   dmesg
>
>   lspci -vvv
>
> and
>
>   lspcmcia -v -v
>
> (ideally all for a working and non-working configuration).
>
> Thanks,
>   Dominik
>

Re: PCMCIA not working on Panasonic Toughbook CF-29

[Dominik Brodowski]

On Tue, Oct 15, 2019 at 05:04:28PM +1100, Michael . wrote:
> Good afternoon kernel developers
> Please accept my apology for contacting you directly about this. A
> small group of friends, some of whom are CCed here, have come together
> to try and find a solution to a problem that originated with the
> demise of kernel 2.6:32. First some background to the issue. We are
> all users of Panasonic Toughbook CF-29 models (ranging from Mark 1
> through to Mark 5). These Toughbooks have 2 PCMCIA card slots which
> are used by a variety of people for different purposes. On the CF-29
> Mark 1 through to Mark 3 these slots work without problem. On the
> CF-29 Mark 4 and Mark 5 the last known kernel the top slot worked with
> was 2.6:32. This has been confirmed all all major distros by most of
> the small group of friends I mentioned earlier.
> 
> Thinking it was just a kernel config issue I did some comparisons
> between Debian 6 (Squeeze), Debian 7 (Wheezy), Ubuntu 10.04, and
> Ubuntu 10.10. On all machines both slots functioned as they should
> with Debian 6 and Ubuntu 10.04 but the top slot stopped working on
> Mark 4 and Mark 5 machines on the next release with the next kernel. I
> also tested Ubuntu 10.04 and 10.10 with the 2.6:32 and 2.6:35 kernel
> and both slots worked with the 2.6:32 kernel but not the 2.6:35
> kernel.With my comparisons I merged the config from 2.6:32 into the
> current kernel for Debian 4.19 and rebuilt the kernel, no matter what
> configuration changes I made the top slot still doesn't function on
> Mark 4 and Mark 5 machines.
> 
> This issue, and its apparent start, has been confirmed on all major
> distro family groups. So this brings me, actually the small group of
> dedicated Linux users who own Panasonic Toughbook CF-29s, to contact
> you to ask for help in resolving this issue. I have some questions,
> and I realise the 2.6:32 kernel is long gone now but I'm hoping this
> is not a lost cause, what changes would have occurred between 2.6:32
> and 2.6:33 that would have stopped the hardware working on Mark 4 and
> Mark 5 CF-29 Toughbooks but not Mark 1 through to Mark 3? Would it be
> possible to correct the problem so that the hardware on our machines
> works as it should. While we are not kernel devs or even programmers
> we are enthusiasts who love Linux and our machines and we are hoping
> that together with you and the kernel dev group we can fix this issue
> together.
> 
> I have attached various tar.gz files with ls* outputs so you can see
> the information we have so far. Thank you for taking the time to read
> this.

Is this with 16-bit PCMCIA cards, or with 32-bit CardBus cards? Either case,
please provide the output of

dmesg

lspci -vvv

and

lspcmcia -v -v

(ideally all for a working and non-working configuration).

Thanks,
Dominik

[PATCH] memory/fsl-corenet-cf: Use devm_platform_ioremap_resource() in ccf_probe()

[Markus Elfring]

From: Markus Elfring 
Date: Wed, 18 Sep 2019 13:14:46 +0200

Simplify this function implementation by using a known wrapper function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/memory/fsl-corenet-cf.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet-cf.c
index 0b0ed72016da..f2fdc3c82ff7 100644
--- a/drivers/memory/fsl-corenet-cf.c
+++ b/drivers/memory/fsl-corenet-cf.c
@@ -172,7 +172,6 @@ static irqreturn_t ccf_irq(int irq, void *dev_id)
 static int ccf_probe(struct platform_device *pdev)
 {
struct ccf_private *ccf;
-   struct resource *r;
const struct of_device_id *match;
u32 errinten;
int ret, irq;
@@ -185,13 +184,7 @@ static int ccf_probe(struct platform_device *pdev)
if (!ccf)
return -ENOMEM;

-   r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!r) {
-   dev_err(>dev, "%s: no mem resource\n", __func__);
-   return -ENXIO;
-   }
-
-   ccf->regs = devm_ioremap_resource(>dev, r);
+   ccf->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(ccf->regs)) {
dev_err(>dev, "%s: can't map mem resource\n", __func__);
return PTR_ERR(ccf->regs);
--
2.23.0

[PATCH 08/22] ARM: omap1: move CF chipselect setup to board file

[Arnd Bergmann]

There is only one board that uses the omap_cf driver, so
moving the chipselect configuration there does not lead
to code duplication but avoids the use of mach/tc.h
in drivers.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/mach-omap1/board-osk.c | 38 -
 drivers/pcmcia/Kconfig  |  3 ++-
 drivers/pcmcia/omap_cf.c| 38 ++---
 3 files changed, 42 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 99ebe4503787..38d73da5d13d 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -149,14 +149,14 @@ static struct resource osk5912_cf_resources[] = {
[0] = {
.flags  = IORESOURCE_IRQ,
},
+   [1] = {
+   .flags = IORESOURCE_MEM,
+   },
 };
 
 static struct platform_device osk5912_cf_device = {
.name   = "omap_cf",
.id = -1,
-   .dev = {
-   .platform_data  = (void *) 2 /* CS2 */,
-   },
.num_resources  = ARRAY_SIZE(osk5912_cf_resources),
.resource   = osk5912_cf_resources,
 };
@@ -267,13 +267,41 @@ static void __init osk_init_smc91x(void)
omap_writel(l, EMIFS_CCS(1));
 }
 
-static void __init osk_init_cf(void)
+static void __init osk_init_cf(int seg)
 {
+   struct resource *res = _cf_resources[1];
+
omap_cfg_reg(M7_1610_GPIO62);
if ((gpio_request(62, "cf_irq")) < 0) {
printk("Error requesting gpio 62 for CF irq\n");
return;
}
+
+   switch (seg) {
+   /* NOTE: CS0 could be configured too ... */
+   case 1:
+   res->start = OMAP_CS1_PHYS;
+   break;
+   case 2:
+   res->start = OMAP_CS2_PHYS;
+   break;
+   case 3:
+   res->start = omap_cs3_phys();
+   break;
+   }
+
+   res->end = res->start + SZ_8K - 1;
+   osk5912_cf_device.dev.platform_data = (void *)(uintptr_t)seg;
+
+   /* NOTE:  better EMIFS setup might support more cards; but the
+* TRM only shows how to affect regular flash signals, not their
+* CF/PCMCIA variants...
+*/
+   pr_debug("%s: cs%d, previous ccs %08x acs %08x\n", __func__,
+   seg, omap_readl(EMIFS_CCS(seg)), omap_readl(EMIFS_ACS(seg)));
+   omap_writel(0x0004a1b3, EMIFS_CCS(seg));/* synch mode 4 etc */
+   omap_writel(0x, EMIFS_ACS(seg));/* OE hold/setup */
+
/* the CF I/O IRQ is really active-low */
irq_set_irq_type(gpio_to_irq(62), IRQ_TYPE_EDGE_FALLING);
 }
@@ -577,7 +605,7 @@ static void __init osk_init(void)
u32 l;
 
osk_init_smc91x();
-   osk_init_cf();
+   osk_init_cf(2); /* CS2 */
 
/* Workaround for wrong CS3 (NOR flash) timing
 * There are some U-Boot versions out there which configure
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index e004d8da03dc..ca6e2ac2a92f 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -250,7 +250,8 @@ config PCMCIA_VRC4173
 
 config OMAP_CF
tristate "OMAP CompactFlash Controller"
-   depends on PCMCIA && ARCH_OMAP16XX
+   depends on PCMCIA
+   depends on ARCH_OMAP16XX || (ARM && COMPILE_TEST)
help
  Say Y here to support the CompactFlash controller on OMAP.
  Note that this doesn't support "True IDE" mode.
diff --git a/drivers/pcmcia/omap_cf.c b/drivers/pcmcia/omap_cf.c
index 0a04eb04f3a2..98df6473034d 100644
--- a/drivers/pcmcia/omap_cf.c
+++ b/drivers/pcmcia/omap_cf.c
@@ -16,13 +16,12 @@
 
 #include 
 
-#include 
 #include 
 #include 
 
-#include 
-#include 
-
+#include 
+#include 
+#include 
 
 /* NOTE:  don't expect this to support many I/O cards.  The 16xx chips have
  * hard-wired timings to support Compact Flash memory cards; they won't work
@@ -205,6 +204,7 @@ static int __init omap_cf_probe(struct platform_device 
*pdev)
struct omap_cf_socket   *cf;
int irq;
int status;
+   struct resource *res;
 
seg = (int) pdev->dev.platform_data;
if (seg == 0 || seg > 3)
@@ -215,6 +215,8 @@ static int __init omap_cf_probe(struct platform_device 
*pdev)
if (irq < 0)
        return -EINVAL;
 
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
cf = kzalloc(sizeof *cf, GFP_KERNEL);
if (!cf)
return -ENOMEM;
@@ -230,24 +232,7 @@ static int __init omap_cf_probe(struct platform_device 
*pdev)
goto fail0;
cf->irq = irq;
cf->socket.pci_irq = irq;
-
-   switch (seg) {
-   /* NOTE: CS0 could be configured too ... */
-   case 1:
-   cf->phys_cf = OMAP_CS1_PHYS;
-   break;
-     

[PATCH] fsi: cf-fsi-fw: Use the correct style for SPDX License Identifier

[Nishad Kamdar]

This patch corrects the SPDX License Identifier style
in header file related to Drivers for FRU Support Interface.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)

Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46

Suggested-by: Joe Perches 
Signed-off-by: Nishad Kamdar 
---
 drivers/fsi/cf-fsi-fw.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/fsi/cf-fsi-fw.h b/drivers/fsi/cf-fsi-fw.h
index 712df0461911..1118eaf7ee39 100644
--- a/drivers/fsi/cf-fsi-fw.h
+++ b/drivers/fsi/cf-fsi-fw.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0+
+/* SPDX-License-Identifier: GPL-2.0+ */
 #ifndef __CF_FSI_FW_H
 #define __CF_FSI_FW_H
 
-- 
2.17.1

[PATCH 4.19 083/142] fsi: master-ast-cf: select GENERIC_ALLOCATOR

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 64999fa7aa2c076ec6d05aee481f11f5296ceb8c ]

In randconfig builds without CONFIG_GENERIC_ALLOCATOR, this driver
fails to link:

ERROR: "gen_pool_alloc_algo" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "gen_pool_fixed_alloc" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "of_gen_pool_get" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "gen_pool_free" [drivers/fsi/fsi-master-ast-cf.ko] undefined!

Select the dependency as all other users do.

Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
ColdFire")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Sasha Levin 
---
 drivers/fsi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
index af3a20dd5aa4..99c99a5d57fe 100644
--- a/drivers/fsi/Kconfig
+++ b/drivers/fsi/Kconfig
@@ -46,6 +46,7 @@ config FSI_MASTER_AST_CF
tristate "FSI master based on Aspeed ColdFire coprocessor"
depends on GPIOLIB
depends on GPIO_ASPEED
+   select GENERIC_ALLOCATOR
---help---
This option enables a FSI master using the AST2400 and AST2500 GPIO
lines driven by the internal ColdFire coprocessor. This requires
-- 
2.19.1

[PATCH AUTOSEL 4.19 066/123] fsi: master-ast-cf: select GENERIC_ALLOCATOR

[Sasha Levin]

From: Arnd Bergmann 

[ Upstream commit 64999fa7aa2c076ec6d05aee481f11f5296ceb8c ]

In randconfig builds without CONFIG_GENERIC_ALLOCATOR, this driver
fails to link:

ERROR: "gen_pool_alloc_algo" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "gen_pool_fixed_alloc" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "of_gen_pool_get" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "gen_pool_free" [drivers/fsi/fsi-master-ast-cf.ko] undefined!

Select the dependency as all other users do.

Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
ColdFire")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Sasha Levin 
---
 drivers/fsi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
index af3a20dd5aa4..99c99a5d57fe 100644
--- a/drivers/fsi/Kconfig
+++ b/drivers/fsi/Kconfig
@@ -46,6 +46,7 @@ config FSI_MASTER_AST_CF
tristate "FSI master based on Aspeed ColdFire coprocessor"
depends on GPIOLIB
depends on GPIO_ASPEED
+   select GENERIC_ALLOCATOR
---help---
This option enables a FSI master using the AST2400 and AST2500 GPIO
lines driven by the internal ColdFire coprocessor. This requires
-- 
2.17.1

[PATCH AUTOSEL 4.19 066/123] fsi: master-ast-cf: select GENERIC_ALLOCATOR

[Sasha Levin]

From: Arnd Bergmann 

[ Upstream commit 64999fa7aa2c076ec6d05aee481f11f5296ceb8c ]

In randconfig builds without CONFIG_GENERIC_ALLOCATOR, this driver
fails to link:

ERROR: "gen_pool_alloc_algo" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "gen_pool_fixed_alloc" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "of_gen_pool_get" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "gen_pool_free" [drivers/fsi/fsi-master-ast-cf.ko] undefined!

Select the dependency as all other users do.

Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
ColdFire")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Sasha Levin 
---
 drivers/fsi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
index af3a20dd5aa4..99c99a5d57fe 100644
--- a/drivers/fsi/Kconfig
+++ b/drivers/fsi/Kconfig
@@ -46,6 +46,7 @@ config FSI_MASTER_AST_CF
tristate "FSI master based on Aspeed ColdFire coprocessor"
depends on GPIOLIB
depends on GPIO_ASPEED
+   select GENERIC_ALLOCATOR
---help---
This option enables a FSI master using the AST2400 and AST2500 GPIO
lines driven by the internal ColdFire coprocessor. This requires
-- 
2.17.1

[PATCH] fsi: master-ast-cf: fix spelling mistake: "firwmare" -> "firmware"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in dev_err error message

Signed-off-by: Colin Ian King 
---
 drivers/fsi/fsi-master-ast-cf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
index 04d10ea8d343..85d9be38b32b 100644
--- a/drivers/fsi/fsi-master-ast-cf.c
+++ b/drivers/fsi/fsi-master-ast-cf.c
@@ -838,7 +838,7 @@ static int load_copro_firmware(struct fsi_master_acf 
*master)
rc = request_firmware(, FW_FILE_NAME, master->dev);
if (rc) {
dev_err(
-   master->dev, "Error %d to load firwmare '%s' !\n",
+   master->dev, "Error %d to load firmware '%s' !\n",
rc, FW_FILE_NAME);
return rc;
}
-- 
2.17.1

[PATCH] fsi: master-ast-cf: fix spelling mistake: "firwmare" -> "firmware"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in dev_err error message

Signed-off-by: Colin Ian King 
---
 drivers/fsi/fsi-master-ast-cf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
index 04d10ea8d343..85d9be38b32b 100644
--- a/drivers/fsi/fsi-master-ast-cf.c
+++ b/drivers/fsi/fsi-master-ast-cf.c
@@ -838,7 +838,7 @@ static int load_copro_firmware(struct fsi_master_acf 
*master)
rc = request_firmware(, FW_FILE_NAME, master->dev);
if (rc) {
dev_err(
-   master->dev, "Error %d to load firwmare '%s' !\n",
+   master->dev, "Error %d to load firmware '%s' !\n",
rc, FW_FILE_NAME);
return rc;
}
-- 
2.17.1

Re: [PATCH] fsi: master-ast-cf: Fix memory leak

[Gustavo A. R. Silva]

On 07/25/2018 06:45 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2018-07-25 at 08:38 -0500, Gustavo A. R. Silva wrote:
>> In case memory resources for *fw* were allocated, release them
>> before return.
>>
>> Addresses-Coverity-ID: 1472044 ("Resource leak")
>> Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
>> ColdFire")
>> Signed-off-by: Gustavo A. R. Silva 
> 
> Thanks Gustavo !
> 

Glad to help. :)

> I'll apply before I send my next pull request to Greg !
> 

Thanks
--
Gustavo

Re: [PATCH] fsi: master-ast-cf: Fix memory leak

[Gustavo A. R. Silva]

On 07/25/2018 06:45 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2018-07-25 at 08:38 -0500, Gustavo A. R. Silva wrote:
>> In case memory resources for *fw* were allocated, release them
>> before return.
>>
>> Addresses-Coverity-ID: 1472044 ("Resource leak")
>> Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
>> ColdFire")
>> Signed-off-by: Gustavo A. R. Silva 
> 
> Thanks Gustavo !
> 

Glad to help. :)

> I'll apply before I send my next pull request to Greg !
> 

Thanks
--
Gustavo

Re: [PATCH] fsi: master-ast-cf: Fix memory leak

[Benjamin Herrenschmidt]

On Wed, 2018-07-25 at 08:38 -0500, Gustavo A. R. Silva wrote:
> In case memory resources for *fw* were allocated, release them
> before return.
> 
> Addresses-Coverity-ID: 1472044 ("Resource leak")
> Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
> ColdFire")
> Signed-off-by: Gustavo A. R. Silva 

Thanks Gustavo !

I'll apply before I send my next pull request to Greg !

Cheers,
Ben.

> ---
>  drivers/fsi/fsi-master-ast-cf.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
> index c4a3557..e39a4630 100644
> --- a/drivers/fsi/fsi-master-ast-cf.c
> +++ b/drivers/fsi/fsi-master-ast-cf.c
> @@ -861,7 +861,8 @@ static int load_copro_firmware(struct fsi_master_acf 
> *master)
>   if (sig != wanted_sig) {
>   dev_err(master->dev, "Failed to locate image sig %04x in FW 
> blob\n",
>   wanted_sig);
> - return -ENODEV;
> + rc = -ENODEV;
> + goto release_fw;
>   }
>   if (size > master->cf_mem_size) {
>   dev_err(master->dev, "FW size (%zd) bigger than memory reserve 
> (%zd)\n",
> @@ -870,8 +871,9 @@ static int load_copro_firmware(struct fsi_master_acf 
> *master)
>   } else {
>   memcpy_toio(master->cf_mem, data, size);
>   }
> - release_firmware(fw);
>  
> +release_fw:
> + release_firmware(fw);
>   return rc;
>  }
>  

Re: [PATCH] fsi: master-ast-cf: Fix memory leak

[Benjamin Herrenschmidt]

On Wed, 2018-07-25 at 08:38 -0500, Gustavo A. R. Silva wrote:
> In case memory resources for *fw* were allocated, release them
> before return.
> 
> Addresses-Coverity-ID: 1472044 ("Resource leak")
> Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
> ColdFire")
> Signed-off-by: Gustavo A. R. Silva 

Thanks Gustavo !

I'll apply before I send my next pull request to Greg !

Cheers,
Ben.

> ---
>  drivers/fsi/fsi-master-ast-cf.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
> index c4a3557..e39a4630 100644
> --- a/drivers/fsi/fsi-master-ast-cf.c
> +++ b/drivers/fsi/fsi-master-ast-cf.c
> @@ -861,7 +861,8 @@ static int load_copro_firmware(struct fsi_master_acf 
> *master)
>   if (sig != wanted_sig) {
>   dev_err(master->dev, "Failed to locate image sig %04x in FW 
> blob\n",
>   wanted_sig);
> - return -ENODEV;
> + rc = -ENODEV;
> + goto release_fw;
>   }
>   if (size > master->cf_mem_size) {
>   dev_err(master->dev, "FW size (%zd) bigger than memory reserve 
> (%zd)\n",
> @@ -870,8 +871,9 @@ static int load_copro_firmware(struct fsi_master_acf 
> *master)
>   } else {
>   memcpy_toio(master->cf_mem, data, size);
>   }
> - release_firmware(fw);
>  
> +release_fw:
> + release_firmware(fw);
>   return rc;
>  }
>  

[PATCH] fsi: master-ast-cf: Fix memory leak

[Gustavo A. R. Silva]

In case memory resources for *fw* were allocated, release them
before return.

Addresses-Coverity-ID: 1472044 ("Resource leak")
Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
ColdFire")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/fsi/fsi-master-ast-cf.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
index c4a3557..e39a4630 100644
--- a/drivers/fsi/fsi-master-ast-cf.c
+++ b/drivers/fsi/fsi-master-ast-cf.c
@@ -861,7 +861,8 @@ static int load_copro_firmware(struct fsi_master_acf 
*master)
if (sig != wanted_sig) {
dev_err(master->dev, "Failed to locate image sig %04x in FW 
blob\n",
wanted_sig);
-   return -ENODEV;
+   rc = -ENODEV;
+   goto release_fw;
}
if (size > master->cf_mem_size) {
dev_err(master->dev, "FW size (%zd) bigger than memory reserve 
(%zd)\n",
@@ -870,8 +871,9 @@ static int load_copro_firmware(struct fsi_master_acf 
*master)
} else {
memcpy_toio(master->cf_mem, data, size);
}
-   release_firmware(fw);
 
+release_fw:
+   release_firmware(fw);
return rc;
 }
 
-- 
2.7.4

[PATCH] fsi: master-ast-cf: Fix memory leak

[Gustavo A. R. Silva]

In case memory resources for *fw* were allocated, release them
before return.

Addresses-Coverity-ID: 1472044 ("Resource leak")
Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
ColdFire")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/fsi/fsi-master-ast-cf.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
index c4a3557..e39a4630 100644
--- a/drivers/fsi/fsi-master-ast-cf.c
+++ b/drivers/fsi/fsi-master-ast-cf.c
@@ -861,7 +861,8 @@ static int load_copro_firmware(struct fsi_master_acf 
*master)
if (sig != wanted_sig) {
dev_err(master->dev, "Failed to locate image sig %04x in FW 
blob\n",
wanted_sig);
-   return -ENODEV;
+   rc = -ENODEV;
+   goto release_fw;
}
if (size > master->cf_mem_size) {
dev_err(master->dev, "FW size (%zd) bigger than memory reserve 
(%zd)\n",
@@ -870,8 +871,9 @@ static int load_copro_firmware(struct fsi_master_acf 
*master)
} else {
memcpy_toio(master->cf_mem, data, size);
}
-   release_firmware(fw);
 
+release_fw:
+   release_firmware(fw);
return rc;
 }
 
-- 
2.7.4

Re: [PATCH] fsi: master-ast-cf: use correct format string for size_t

[Benjamin Herrenschmidt]

On Tue, 2018-07-24 at 11:34 +0200, Arnd Bergmann wrote:
> On 32-bit targets, size_t is often 'unsigned int', so printing it as %lu
> causes a warning:
> 
> drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_read':
> drivers/fsi/fsi-master-ast-cf.c:609:23: error: format '%u' expects argument 
> of type 'unsigned int', but argument 6 has type 'size_t' {aka 'long unsigned 
> int'} [-Werror=format=]
>   dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
> drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_write':
> drivers/fsi/fsi-master-ast-cf.c:634:23: error: format '%u' expects argument 
> of type 'unsigned int', but argument 6 has type 'size_t' {aka 'long unsigned 
> int'} [-Werror=format=]
> 
> The correct format string is %zu.

Thanks Arnd, but I've already pushed such a fix in the fsi tree today
:)

Cheers,
Ben.

> Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
> ColdFire")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/fsi/fsi-master-ast-cf.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
> index 57afaae0b691..d1bbdf8b8343 100644
> --- a/drivers/fsi/fsi-master-ast-cf.c
> +++ b/drivers/fsi/fsi-master-ast-cf.c
> @@ -606,7 +606,7 @@ static int fsi_master_acf_read(struct fsi_master 
> *_master, int link,
>   return -ENODEV;
>  
>   mutex_lock(>lock);
> - dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
> + dev_dbg(master->dev, "read id %d addr %x size %zu\n", id, addr, size);
>   build_ar_command(master, , id, addr, size, NULL);
>   rc = fsi_master_acf_xfer(master, id, , size, val);
>   last_address_update(master, id, rc == 0, addr);
> @@ -631,7 +631,7 @@ static int fsi_master_acf_write(struct fsi_master 
> *_master, int link,
>  
>   mutex_lock(>lock);
>   build_ar_command(master, , id, addr, size, val);
> - dev_dbg(master->dev, "write id %d addr %x size %ud raw_data: %08x\n",
> + dev_dbg(master->dev, "write id %d addr %x size %zu raw_data: %08x\n",
>   id, addr, size, *(uint32_t *)val);
>   rc = fsi_master_acf_xfer(master, id, , 0, NULL);
>   last_address_update(master, id, rc == 0, addr);

Re: [PATCH] fsi: master-ast-cf: use correct format string for size_t

[Benjamin Herrenschmidt]

On Tue, 2018-07-24 at 11:34 +0200, Arnd Bergmann wrote:
> On 32-bit targets, size_t is often 'unsigned int', so printing it as %lu
> causes a warning:
> 
> drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_read':
> drivers/fsi/fsi-master-ast-cf.c:609:23: error: format '%u' expects argument 
> of type 'unsigned int', but argument 6 has type 'size_t' {aka 'long unsigned 
> int'} [-Werror=format=]
>   dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
> drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_write':
> drivers/fsi/fsi-master-ast-cf.c:634:23: error: format '%u' expects argument 
> of type 'unsigned int', but argument 6 has type 'size_t' {aka 'long unsigned 
> int'} [-Werror=format=]
> 
> The correct format string is %zu.

Thanks Arnd, but I've already pushed such a fix in the fsi tree today
:)

Cheers,
Ben.

> Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
> ColdFire")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/fsi/fsi-master-ast-cf.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
> index 57afaae0b691..d1bbdf8b8343 100644
> --- a/drivers/fsi/fsi-master-ast-cf.c
> +++ b/drivers/fsi/fsi-master-ast-cf.c
> @@ -606,7 +606,7 @@ static int fsi_master_acf_read(struct fsi_master 
> *_master, int link,
>   return -ENODEV;
>  
>   mutex_lock(>lock);
> - dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
> + dev_dbg(master->dev, "read id %d addr %x size %zu\n", id, addr, size);
>   build_ar_command(master, , id, addr, size, NULL);
>   rc = fsi_master_acf_xfer(master, id, , size, val);
>   last_address_update(master, id, rc == 0, addr);
> @@ -631,7 +631,7 @@ static int fsi_master_acf_write(struct fsi_master 
> *_master, int link,
>  
>   mutex_lock(>lock);
>   build_ar_command(master, , id, addr, size, val);
> - dev_dbg(master->dev, "write id %d addr %x size %ud raw_data: %08x\n",
> + dev_dbg(master->dev, "write id %d addr %x size %zu raw_data: %08x\n",
>   id, addr, size, *(uint32_t *)val);
>   rc = fsi_master_acf_xfer(master, id, , 0, NULL);
>   last_address_update(master, id, rc == 0, addr);

[PATCH] fsi: master-ast-cf: use correct format string for size_t

[Arnd Bergmann]

On 32-bit targets, size_t is often 'unsigned int', so printing it as %lu
causes a warning:

drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_read':
drivers/fsi/fsi-master-ast-cf.c:609:23: error: format '%u' expects argument of 
type 'unsigned int', but argument 6 has type 'size_t' {aka 'long unsigned int'} 
[-Werror=format=]
  dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_write':
drivers/fsi/fsi-master-ast-cf.c:634:23: error: format '%u' expects argument of 
type 'unsigned int', but argument 6 has type 'size_t' {aka 'long unsigned int'} 
[-Werror=format=]

The correct format string is %zu.

Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
ColdFire")
Signed-off-by: Arnd Bergmann 
---
 drivers/fsi/fsi-master-ast-cf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
index 57afaae0b691..d1bbdf8b8343 100644
--- a/drivers/fsi/fsi-master-ast-cf.c
+++ b/drivers/fsi/fsi-master-ast-cf.c
@@ -606,7 +606,7 @@ static int fsi_master_acf_read(struct fsi_master *_master, 
int link,
return -ENODEV;
 
mutex_lock(>lock);
-   dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
+   dev_dbg(master->dev, "read id %d addr %x size %zu\n", id, addr, size);
build_ar_command(master, , id, addr, size, NULL);
rc = fsi_master_acf_xfer(master, id, , size, val);
last_address_update(master, id, rc == 0, addr);
@@ -631,7 +631,7 @@ static int fsi_master_acf_write(struct fsi_master *_master, 
int link,
 
mutex_lock(>lock);
build_ar_command(master, , id, addr, size, val);
-   dev_dbg(master->dev, "write id %d addr %x size %ud raw_data: %08x\n",
+   dev_dbg(master->dev, "write id %d addr %x size %zu raw_data: %08x\n",
id, addr, size, *(uint32_t *)val);
rc = fsi_master_acf_xfer(master, id, , 0, NULL);
last_address_update(master, id, rc == 0, addr);
-- 
2.18.0

[PATCH] fsi: master-ast-cf: use correct format string for size_t

[Arnd Bergmann]

On 32-bit targets, size_t is often 'unsigned int', so printing it as %lu
causes a warning:

drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_read':
drivers/fsi/fsi-master-ast-cf.c:609:23: error: format '%u' expects argument of 
type 'unsigned int', but argument 6 has type 'size_t' {aka 'long unsigned int'} 
[-Werror=format=]
  dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_write':
drivers/fsi/fsi-master-ast-cf.c:634:23: error: format '%u' expects argument of 
type 'unsigned int', but argument 6 has type 'size_t' {aka 'long unsigned int'} 
[-Werror=format=]

The correct format string is %zu.

Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
ColdFire")
Signed-off-by: Arnd Bergmann 
---
 drivers/fsi/fsi-master-ast-cf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
index 57afaae0b691..d1bbdf8b8343 100644
--- a/drivers/fsi/fsi-master-ast-cf.c
+++ b/drivers/fsi/fsi-master-ast-cf.c
@@ -606,7 +606,7 @@ static int fsi_master_acf_read(struct fsi_master *_master, 
int link,
return -ENODEV;
 
mutex_lock(>lock);
-   dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
+   dev_dbg(master->dev, "read id %d addr %x size %zu\n", id, addr, size);
build_ar_command(master, , id, addr, size, NULL);
rc = fsi_master_acf_xfer(master, id, , size, val);
last_address_update(master, id, rc == 0, addr);
@@ -631,7 +631,7 @@ static int fsi_master_acf_write(struct fsi_master *_master, 
int link,
 
mutex_lock(>lock);
build_ar_command(master, , id, addr, size, val);
-   dev_dbg(master->dev, "write id %d addr %x size %ud raw_data: %08x\n",
+   dev_dbg(master->dev, "write id %d addr %x size %zu raw_data: %08x\n",
id, addr, size, *(uint32_t *)val);
rc = fsi_master_acf_xfer(master, id, , 0, NULL);
last_address_update(master, id, rc == 0, addr);
-- 
2.18.0

[PATCH 4.14 08/44] ALSA: hda/realtek - Add Panasonic CF-SZ6 headset jack quirk

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: YOKOTA Hiroshi 

commit 0fca97a29b83e3f315c14ed2372cfd0f9ee0a006 upstream.

This adds some required quirk when uses headset or headphone on
Panasonic CF-SZ6.

Signed-off-by: YOKOTA Hiroshi 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/hda/patch_realtek.c |1 +
 1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6402,6 +6402,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x10cf, 0x1629, "Lifebook U7x7", 
ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC),
SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", 
ALC269_FIXUP_LIFEBOOK_EXTMIC),
SND_PCI_QUIRK(0x10ec, 0x10f2, "Intel Reference board", 
ALC700_FIXUP_INTEL_REFERENCE),
+   SND_PCI_QUIRK(0x10f7, 0x8338, "Panasonic CF-SZ6", 
ALC269_FIXUP_HEADSET_MODE),
SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)", 
ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x144d, 0xc740, "Samsung Ativ book 8 (NP870Z5G)", 
ALC269_FIXUP_ATIV_BOOK_8),
SND_PCI_QUIRK(0x1458, 0xfa53, "Gigabyte BXBT-2807", 
ALC283_FIXUP_HEADSET_MIC),

[PATCH 4.14 08/44] ALSA: hda/realtek - Add Panasonic CF-SZ6 headset jack quirk

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: YOKOTA Hiroshi 

commit 0fca97a29b83e3f315c14ed2372cfd0f9ee0a006 upstream.

This adds some required quirk when uses headset or headphone on
Panasonic CF-SZ6.

Signed-off-by: YOKOTA Hiroshi 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/hda/patch_realtek.c |1 +
 1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6402,6 +6402,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x10cf, 0x1629, "Lifebook U7x7", 
ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC),
SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", 
ALC269_FIXUP_LIFEBOOK_EXTMIC),
SND_PCI_QUIRK(0x10ec, 0x10f2, "Intel Reference board", 
ALC700_FIXUP_INTEL_REFERENCE),
+   SND_PCI_QUIRK(0x10f7, 0x8338, "Panasonic CF-SZ6", 
ALC269_FIXUP_HEADSET_MODE),
SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)", 
ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x144d, 0xc740, "Samsung Ativ book 8 (NP870Z5G)", 
ALC269_FIXUP_ATIV_BOOK_8),
SND_PCI_QUIRK(0x1458, 0xfa53, "Gigabyte BXBT-2807", 
ALC283_FIXUP_HEADSET_MIC),

[PATCH 4.17 15/63] ALSA: hda/realtek - Add Panasonic CF-SZ6 headset jack quirk

[Greg Kroah-Hartman]

4.17-stable review patch.  If anyone has any objections, please let me know.

--

From: YOKOTA Hiroshi 

commit 0fca97a29b83e3f315c14ed2372cfd0f9ee0a006 upstream.

This adds some required quirk when uses headset or headphone on
Panasonic CF-SZ6.

Signed-off-by: YOKOTA Hiroshi 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/hda/patch_realtek.c |1 +
 1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6543,6 +6543,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x10cf, 0x1629, "Lifebook U7x7", 
ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC),
SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", 
ALC269_FIXUP_LIFEBOOK_EXTMIC),
SND_PCI_QUIRK(0x10ec, 0x10f2, "Intel Reference board", 
ALC700_FIXUP_INTEL_REFERENCE),
+   SND_PCI_QUIRK(0x10f7, 0x8338, "Panasonic CF-SZ6", 
ALC269_FIXUP_HEADSET_MODE),
SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)", 
ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x144d, 0xc740, "Samsung Ativ book 8 (NP870Z5G)", 
ALC269_FIXUP_ATIV_BOOK_8),
SND_PCI_QUIRK(0x1458, 0xfa53, "Gigabyte BXBT-2807", 
ALC283_FIXUP_HEADSET_MIC),

[PATCH 4.17 15/63] ALSA: hda/realtek - Add Panasonic CF-SZ6 headset jack quirk

[Greg Kroah-Hartman]

4.17-stable review patch.  If anyone has any objections, please let me know.

--

From: YOKOTA Hiroshi 

commit 0fca97a29b83e3f315c14ed2372cfd0f9ee0a006 upstream.

This adds some required quirk when uses headset or headphone on
Panasonic CF-SZ6.

Signed-off-by: YOKOTA Hiroshi 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/hda/patch_realtek.c |1 +
 1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6543,6 +6543,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x10cf, 0x1629, "Lifebook U7x7", 
ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC),
SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", 
ALC269_FIXUP_LIFEBOOK_EXTMIC),
SND_PCI_QUIRK(0x10ec, 0x10f2, "Intel Reference board", 
ALC700_FIXUP_INTEL_REFERENCE),
+   SND_PCI_QUIRK(0x10f7, 0x8338, "Panasonic CF-SZ6", 
ALC269_FIXUP_HEADSET_MODE),
SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)", 
ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x144d, 0xc740, "Samsung Ativ book 8 (NP870Z5G)", 
ALC269_FIXUP_ATIV_BOOK_8),
SND_PCI_QUIRK(0x1458, 0xfa53, "Gigabyte BXBT-2807", 
ALC283_FIXUP_HEADSET_MIC),

Re: [PATCH v3 1/5] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Benjamin Herrenschmidt]

On Mon, 2018-07-16 at 09:33 -0600, Rob Herring wrote:
> On Thu, Jul 12, 2018 at 01:48:43PM +1000, Benjamin Herrenschmidt wrote:
> > This isn't per-se a real device, it's a pseudo-device that
> > represents the use of the Aspeed built-in ColdFire to
> > implement the FSI protocol by bitbanging the GPIOs instead
> > of doing it from the ARM core.
> > 
> > Thus it's a drop-in replacement for the existing
> > fsi-master-gpio pseudo-device for use on systems based
> > on the Aspeed chips. It has most of the same properties,
> > plus some more needed to operate the coprocessor.
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> >  .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
> >  1 file changed, 36 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
> > b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > new file mode 100644
> > index ..431bf8a423ce
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > @@ -0,0 +1,36 @@
> > +Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
> > +----
> > +
> > +Required properties:
> > + - compatible =
> > +   "aspeed,ast2400-cf-fsi-master" for an AST2400 based system
> > +   or
> > +   "aspeed,ast2500-cf-fsi-master" for an AST2500 based system
> > +
> > + - clock-gpios = ;: GPIO for FSI clock
> > + - data-gpios = ; : GPIO for FSI data signal
> > + - enable-gpios = ;   : GPIO for enable signal
> > + - trans-gpios = ;: GPIO for voltage translator 
> > enable
> > + - mux-gpios = ;  : GPIO for pin multiplexing with other
> > +  functions (eg, external FSI 
> > masters)
> > + - memory-region = ;  : Reference to the reserved 
> > memory for
> > +  the ColdFire. Must be 2M aligned 
> > on
> > +     AST2400 and 1M aligned on AST2500
> > + - aspeed,sram = ;: Reference to the SRAM node.
> > + - aspeed,cvic = ;: Reference to the CVIC node.
> > +
> > +Examples:
> > +
> > +fsi-master {
> > +compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
> > +
> > +   clock-gpios = < 0>;
> > +data-gpios = < 1>;
> > +enable-gpios = < 2>;
> > +trans-gpios = < 3>;
> > +mux-gpios = < 4>;
> > +
> > +   memory-region = <_memory>;
> > +   sram = <>;
> > +   cvic = <>;
> 
> Need to update the example. With that

Ah right, thanks. The next spin will have that fixed and will go into
the fsi tree.

> Reviewed-by: Rob Herring 

Re: [PATCH v3 1/5] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Benjamin Herrenschmidt]

On Mon, 2018-07-16 at 09:33 -0600, Rob Herring wrote:
> On Thu, Jul 12, 2018 at 01:48:43PM +1000, Benjamin Herrenschmidt wrote:
> > This isn't per-se a real device, it's a pseudo-device that
> > represents the use of the Aspeed built-in ColdFire to
> > implement the FSI protocol by bitbanging the GPIOs instead
> > of doing it from the ARM core.
> > 
> > Thus it's a drop-in replacement for the existing
> > fsi-master-gpio pseudo-device for use on systems based
> > on the Aspeed chips. It has most of the same properties,
> > plus some more needed to operate the coprocessor.
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> >  .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
> >  1 file changed, 36 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
> > b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > new file mode 100644
> > index ..431bf8a423ce
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > @@ -0,0 +1,36 @@
> > +Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
> > +----
> > +
> > +Required properties:
> > + - compatible =
> > +   "aspeed,ast2400-cf-fsi-master" for an AST2400 based system
> > +   or
> > +   "aspeed,ast2500-cf-fsi-master" for an AST2500 based system
> > +
> > + - clock-gpios = ;: GPIO for FSI clock
> > + - data-gpios = ; : GPIO for FSI data signal
> > + - enable-gpios = ;   : GPIO for enable signal
> > + - trans-gpios = ;: GPIO for voltage translator 
> > enable
> > + - mux-gpios = ;  : GPIO for pin multiplexing with other
> > +  functions (eg, external FSI 
> > masters)
> > + - memory-region = ;  : Reference to the reserved 
> > memory for
> > +  the ColdFire. Must be 2M aligned 
> > on
> > +     AST2400 and 1M aligned on AST2500
> > + - aspeed,sram = ;: Reference to the SRAM node.
> > + - aspeed,cvic = ;: Reference to the CVIC node.
> > +
> > +Examples:
> > +
> > +fsi-master {
> > +compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
> > +
> > +   clock-gpios = < 0>;
> > +data-gpios = < 1>;
> > +enable-gpios = < 2>;
> > +trans-gpios = < 3>;
> > +mux-gpios = < 4>;
> > +
> > +   memory-region = <_memory>;
> > +   sram = <>;
> > +   cvic = <>;
> 
> Need to update the example. With that

Ah right, thanks. The next spin will have that fixed and will go into
the fsi tree.

> Reviewed-by: Rob Herring 

Re: [PATCH v3 1/5] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Rob Herring]

On Thu, Jul 12, 2018 at 01:48:43PM +1000, Benjamin Herrenschmidt wrote:
> This isn't per-se a real device, it's a pseudo-device that
> represents the use of the Aspeed built-in ColdFire to
> implement the FSI protocol by bitbanging the GPIOs instead
> of doing it from the ARM core.
> 
> Thus it's a drop-in replacement for the existing
> fsi-master-gpio pseudo-device for use on systems based
> on the Aspeed chips. It has most of the same properties,
> plus some more needed to operate the coprocessor.
> 
> Signed-off-by: Benjamin Herrenschmidt 
> ---
>  .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
>  1 file changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> 
> diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
> b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> new file mode 100644
> index ..431bf8a423ce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> @@ -0,0 +1,36 @@
> +Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
> +----
> +
> +Required properties:
> + - compatible =
> + "aspeed,ast2400-cf-fsi-master" for an AST2400 based system
> +   or
> + "aspeed,ast2500-cf-fsi-master" for an AST2500 based system
> +
> + - clock-gpios = ;  : GPIO for FSI clock
> + - data-gpios = ;   : GPIO for FSI data signal
> + - enable-gpios = ; : GPIO for enable signal
> + - trans-gpios = ;  : GPIO for voltage translator enable
> + - mux-gpios = ;: GPIO for pin multiplexing with other
> +  functions (eg, external FSI 
> masters)
> + - memory-region = ;: Reference to the reserved 
> memory for
> +  the ColdFire. Must be 2M aligned on
> +   AST2400 and 1M aligned on AST2500
> + - aspeed,sram = ;  : Reference to the SRAM node.
> + - aspeed,cvic = ;  : Reference to the CVIC node.
> +
> +Examples:
> +
> +fsi-master {
> +compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
> +
> + clock-gpios = < 0>;
> +data-gpios = < 1>;
> +enable-gpios = < 2>;
> +trans-gpios = < 3>;
> +mux-gpios = < 4>;
> +
> + memory-region = <_memory>;
> + sram = <>;
> + cvic = <>;

Need to update the example. With that,

Reviewed-by: Rob Herring 

Re: [PATCH v3 1/5] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Rob Herring]

On Thu, Jul 12, 2018 at 01:48:43PM +1000, Benjamin Herrenschmidt wrote:
> This isn't per-se a real device, it's a pseudo-device that
> represents the use of the Aspeed built-in ColdFire to
> implement the FSI protocol by bitbanging the GPIOs instead
> of doing it from the ARM core.
> 
> Thus it's a drop-in replacement for the existing
> fsi-master-gpio pseudo-device for use on systems based
> on the Aspeed chips. It has most of the same properties,
> plus some more needed to operate the coprocessor.
> 
> Signed-off-by: Benjamin Herrenschmidt 
> ---
>  .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
>  1 file changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> 
> diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
> b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> new file mode 100644
> index ..431bf8a423ce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> @@ -0,0 +1,36 @@
> +Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
> +----
> +
> +Required properties:
> + - compatible =
> + "aspeed,ast2400-cf-fsi-master" for an AST2400 based system
> +   or
> + "aspeed,ast2500-cf-fsi-master" for an AST2500 based system
> +
> + - clock-gpios = ;  : GPIO for FSI clock
> + - data-gpios = ;   : GPIO for FSI data signal
> + - enable-gpios = ; : GPIO for enable signal
> + - trans-gpios = ;  : GPIO for voltage translator enable
> + - mux-gpios = ;: GPIO for pin multiplexing with other
> +  functions (eg, external FSI 
> masters)
> + - memory-region = ;: Reference to the reserved 
> memory for
> +  the ColdFire. Must be 2M aligned on
> +   AST2400 and 1M aligned on AST2500
> + - aspeed,sram = ;  : Reference to the SRAM node.
> + - aspeed,cvic = ;  : Reference to the CVIC node.
> +
> +Examples:
> +
> +fsi-master {
> +compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
> +
> + clock-gpios = < 0>;
> +data-gpios = < 1>;
> +enable-gpios = < 2>;
> +trans-gpios = < 3>;
> +mux-gpios = < 4>;
> +
> + memory-region = <_memory>;
> + sram = <>;
> + cvic = <>;

Need to update the example. With that,

Reviewed-by: Rob Herring 

Re: [PATCH v3 3/5] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire

[Benjamin Herrenschmidt]

On Thu, 2018-07-12 at 17:53 +1000, Joel Stanley wrote:
> On 12 July 2018 at 13:48, Benjamin Herrenschmidt
>  wrote:
> > The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
> > is currently unused on OpenPower systems.
> > 
> > This adds an alternative to the fsi-master-gpio driver that
> > uses that coprocessor instead of bit banging from the ARM
> > core itself. The end result is about 4 times faster.
> > 
> > The firmware for the coprocessor and its source code can be
> > found at https://github.com/ozbenh/cf-fsi and is system specific.
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> >  drivers/fsi/Kconfig      |9 +
> >  drivers/fsi/Makefile |1 +
> >  drivers/fsi/cf-fsi-fw.h  |  157 +++
> >  drivers/fsi/fsi-master-ast-cf.c  | 1438 ++
> >  include/trace/events/fsi_master_ast_cf.h |  150 +++
> >  5 files changed, 1755 insertions(+)
> >  create mode 100644 drivers/fsi/cf-fsi-fw.h
> >  create mode 100644 drivers/fsi/fsi-master-ast-cf.c
> >  create mode 100644 include/trace/events/fsi_master_ast_cf.h
> > 
> > diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
> > index 322cec393cf2..e0220d1e1357 100644
> > --- a/drivers/fsi/Kconfig
> > +++ b/drivers/fsi/Kconfig
> > @@ -27,6 +27,15 @@ config FSI_MASTER_HUB
> > allow chaining of FSI links to an arbitrary depth.  This allows for
> > a high target device fanout.
> > 
> > +config FSI_MASTER_AST_CF
> > +   tristate "FSI master based on Aspeed ColdFire coprocessor"
> > +   depends on GPIOLIB
> > +   depends on GPIO_ASPEED
> > +   ---help---
> > +   This option enables a FSI master using the AST2400 and AST2500 GPIO
> > +   lines driven by the internal ColdFire coprocessor. This requires
> > +   the corresponding machine specific ColdFire firmware to be 
> > available.
> 
> The "machine specific" part isn't true anymore, is it?

Right, I'll fixup the changelog before pushing if that's the last spin.

> I gave this a spin on a palmetto and it appeared to work fine for me.
> 
> Tested-by: Joel Stanley 

Thanks !

Cheers,
Ben
.

Re: [PATCH v3 3/5] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire

[Benjamin Herrenschmidt]

On Thu, 2018-07-12 at 17:53 +1000, Joel Stanley wrote:
> On 12 July 2018 at 13:48, Benjamin Herrenschmidt
>  wrote:
> > The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
> > is currently unused on OpenPower systems.
> > 
> > This adds an alternative to the fsi-master-gpio driver that
> > uses that coprocessor instead of bit banging from the ARM
> > core itself. The end result is about 4 times faster.
> > 
> > The firmware for the coprocessor and its source code can be
> > found at https://github.com/ozbenh/cf-fsi and is system specific.
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> >  drivers/fsi/Kconfig      |9 +
> >  drivers/fsi/Makefile |1 +
> >  drivers/fsi/cf-fsi-fw.h  |  157 +++
> >  drivers/fsi/fsi-master-ast-cf.c  | 1438 ++
> >  include/trace/events/fsi_master_ast_cf.h |  150 +++
> >  5 files changed, 1755 insertions(+)
> >  create mode 100644 drivers/fsi/cf-fsi-fw.h
> >  create mode 100644 drivers/fsi/fsi-master-ast-cf.c
> >  create mode 100644 include/trace/events/fsi_master_ast_cf.h
> > 
> > diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
> > index 322cec393cf2..e0220d1e1357 100644
> > --- a/drivers/fsi/Kconfig
> > +++ b/drivers/fsi/Kconfig
> > @@ -27,6 +27,15 @@ config FSI_MASTER_HUB
> > allow chaining of FSI links to an arbitrary depth.  This allows for
> > a high target device fanout.
> > 
> > +config FSI_MASTER_AST_CF
> > +   tristate "FSI master based on Aspeed ColdFire coprocessor"
> > +   depends on GPIOLIB
> > +   depends on GPIO_ASPEED
> > +   ---help---
> > +   This option enables a FSI master using the AST2400 and AST2500 GPIO
> > +   lines driven by the internal ColdFire coprocessor. This requires
> > +   the corresponding machine specific ColdFire firmware to be 
> > available.
> 
> The "machine specific" part isn't true anymore, is it?

Right, I'll fixup the changelog before pushing if that's the last spin.

> I gave this a spin on a palmetto and it appeared to work fine for me.
> 
> Tested-by: Joel Stanley 

Thanks !

Cheers,
Ben
.

Re: [PATCH v3 3/5] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire

[Joel Stanley]

On 12 July 2018 at 13:48, Benjamin Herrenschmidt
 wrote:
> The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
> is currently unused on OpenPower systems.
>
> This adds an alternative to the fsi-master-gpio driver that
> uses that coprocessor instead of bit banging from the ARM
> core itself. The end result is about 4 times faster.
>
> The firmware for the coprocessor and its source code can be
> found at https://github.com/ozbenh/cf-fsi and is system specific.
>
> Signed-off-by: Benjamin Herrenschmidt 
> ---
>  drivers/fsi/Kconfig  |9 +
>  drivers/fsi/Makefile     |1 +
>  drivers/fsi/cf-fsi-fw.h  |  157 +++
>  drivers/fsi/fsi-master-ast-cf.c  | 1438 ++
>  include/trace/events/fsi_master_ast_cf.h |  150 +++
>  5 files changed, 1755 insertions(+)
>  create mode 100644 drivers/fsi/cf-fsi-fw.h
>  create mode 100644 drivers/fsi/fsi-master-ast-cf.c
>  create mode 100644 include/trace/events/fsi_master_ast_cf.h
>
> diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
> index 322cec393cf2..e0220d1e1357 100644
> --- a/drivers/fsi/Kconfig
> +++ b/drivers/fsi/Kconfig
> @@ -27,6 +27,15 @@ config FSI_MASTER_HUB
> allow chaining of FSI links to an arbitrary depth.  This allows for
> a high target device fanout.
>
> +config FSI_MASTER_AST_CF
> +   tristate "FSI master based on Aspeed ColdFire coprocessor"
> +   depends on GPIOLIB
> +   depends on GPIO_ASPEED
> +   ---help---
> +   This option enables a FSI master using the AST2400 and AST2500 GPIO
> +   lines driven by the internal ColdFire coprocessor. This requires
> +   the corresponding machine specific ColdFire firmware to be available.

The "machine specific" part isn't true anymore, is it?

I gave this a spin on a palmetto and it appeared to work fine for me.

Tested-by: Joel Stanley 

Re: [PATCH v3 3/5] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire

[Joel Stanley]

On 12 July 2018 at 13:48, Benjamin Herrenschmidt
 wrote:
> The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
> is currently unused on OpenPower systems.
>
> This adds an alternative to the fsi-master-gpio driver that
> uses that coprocessor instead of bit banging from the ARM
> core itself. The end result is about 4 times faster.
>
> The firmware for the coprocessor and its source code can be
> found at https://github.com/ozbenh/cf-fsi and is system specific.
>
> Signed-off-by: Benjamin Herrenschmidt 
> ---
>  drivers/fsi/Kconfig  |9 +
>  drivers/fsi/Makefile     |1 +
>  drivers/fsi/cf-fsi-fw.h  |  157 +++
>  drivers/fsi/fsi-master-ast-cf.c  | 1438 ++
>  include/trace/events/fsi_master_ast_cf.h |  150 +++
>  5 files changed, 1755 insertions(+)
>  create mode 100644 drivers/fsi/cf-fsi-fw.h
>  create mode 100644 drivers/fsi/fsi-master-ast-cf.c
>  create mode 100644 include/trace/events/fsi_master_ast_cf.h
>
> diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
> index 322cec393cf2..e0220d1e1357 100644
> --- a/drivers/fsi/Kconfig
> +++ b/drivers/fsi/Kconfig
> @@ -27,6 +27,15 @@ config FSI_MASTER_HUB
> allow chaining of FSI links to an arbitrary depth.  This allows for
> a high target device fanout.
>
> +config FSI_MASTER_AST_CF
> +   tristate "FSI master based on Aspeed ColdFire coprocessor"
> +   depends on GPIOLIB
> +   depends on GPIO_ASPEED
> +   ---help---
> +   This option enables a FSI master using the AST2400 and AST2500 GPIO
> +   lines driven by the internal ColdFire coprocessor. This requires
> +   the corresponding machine specific ColdFire firmware to be available.

The "machine specific" part isn't true anymore, is it?

I gave this a spin on a palmetto and it appeared to work fine for me.

Tested-by: Joel Stanley 

[PATCH v3 1/5] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Benjamin Herrenschmidt]

This isn't per-se a real device, it's a pseudo-device that
represents the use of the Aspeed built-in ColdFire to
implement the FSI protocol by bitbanging the GPIOs instead
of doing it from the ARM core.

Thus it's a drop-in replacement for the existing
fsi-master-gpio pseudo-device for use on systems based
on the Aspeed chips. It has most of the same properties,
plus some more needed to operate the coprocessor.

Signed-off-by: Benjamin Herrenschmidt 
---
 .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt

diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
new file mode 100644
index ..431bf8a423ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
@@ -0,0 +1,36 @@
+Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
+
+
+Required properties:
+ - compatible =
+   "aspeed,ast2400-cf-fsi-master" for an AST2400 based system
+   or
+   "aspeed,ast2500-cf-fsi-master" for an AST2500 based system
+
+ - clock-gpios = ;: GPIO for FSI clock
+ - data-gpios = ; : GPIO for FSI data signal
+ - enable-gpios = ;   : GPIO for enable signal
+ - trans-gpios = ;: GPIO for voltage translator enable
+ - mux-gpios = ;  : GPIO for pin multiplexing with other
+  functions (eg, external FSI masters)
+ - memory-region = ;  : Reference to the reserved memory for
+  the ColdFire. Must be 2M aligned on
+ AST2400 and 1M aligned on AST2500
+ - aspeed,sram = ;: Reference to the SRAM node.
+ - aspeed,cvic = ;: Reference to the CVIC node.
+
+Examples:
+
+fsi-master {
+compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
+
+   clock-gpios = < 0>;
+data-gpios = < 1>;
+enable-gpios = < 2>;
+trans-gpios = < 3>;
+mux-gpios = < 4>;
+
+   memory-region = <_memory>;
+   sram = <>;
+   cvic = <>;
+}
-- 
2.17.1

[PATCH v3 3/5] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire

[Benjamin Herrenschmidt]

The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
is currently unused on OpenPower systems.

This adds an alternative to the fsi-master-gpio driver that
uses that coprocessor instead of bit banging from the ARM
core itself. The end result is about 4 times faster.

The firmware for the coprocessor and its source code can be
found at https://github.com/ozbenh/cf-fsi and is system specific.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/fsi/Kconfig  |9 +
 drivers/fsi/Makefile |1 +
 drivers/fsi/cf-fsi-fw.h  |  157 +++
 drivers/fsi/fsi-master-ast-cf.c  | 1438 ++
 include/trace/events/fsi_master_ast_cf.h |  150 +++
 5 files changed, 1755 insertions(+)
 create mode 100644 drivers/fsi/cf-fsi-fw.h
 create mode 100644 drivers/fsi/fsi-master-ast-cf.c
 create mode 100644 include/trace/events/fsi_master_ast_cf.h

diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
index 322cec393cf2..e0220d1e1357 100644
--- a/drivers/fsi/Kconfig
+++ b/drivers/fsi/Kconfig
@@ -27,6 +27,15 @@ config FSI_MASTER_HUB
allow chaining of FSI links to an arbitrary depth.  This allows for
a high target device fanout.
 
+config FSI_MASTER_AST_CF
+   tristate "FSI master based on Aspeed ColdFire coprocessor"
+   depends on GPIOLIB
+   depends on GPIO_ASPEED
+   ---help---
+   This option enables a FSI master using the AST2400 and AST2500 GPIO
+   lines driven by the internal ColdFire coprocessor. This requires
+   the corresponding machine specific ColdFire firmware to be available.
+
 config FSI_SCOM
tristate "SCOM FSI client device driver"
---help---
diff --git a/drivers/fsi/Makefile b/drivers/fsi/Makefile
index 75fdc6d8cfc4..62687ec86d2e 100644
--- a/drivers/fsi/Makefile
+++ b/drivers/fsi/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_FSI) += fsi-core.o
 obj-$(CONFIG_FSI_MASTER_HUB) += fsi-master-hub.o
 obj-$(CONFIG_FSI_MASTER_GPIO) += fsi-master-gpio.o
+obj-$(CONFIG_FSI_MASTER_AST_CF) += fsi-master-ast-cf.o
 obj-$(CONFIG_FSI_SCOM) += fsi-scom.o
 obj-$(CONFIG_FSI_SBEFIFO) += fsi-sbefifo.o
 obj-$(CONFIG_FSI_OCC) += fsi-occ.o
diff --git a/drivers/fsi/cf-fsi-fw.h b/drivers/fsi/cf-fsi-fw.h
new file mode 100644
index ..712df0461911
--- /dev/null
+++ b/drivers/fsi/cf-fsi-fw.h
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0+
+#ifndef __CF_FSI_FW_H
+#define __CF_FSI_FW_H
+
+/*
+ * uCode file layout
+ *
+ * ...03ff : m68k exception vectors
+ * 0400...04ff : Header info & boot config block
+ * 0500... : Code & stack
+ */
+
+/*
+ * Header info & boot config area
+ *
+ * The Header info is built into the ucode and provide version and
+ * platform information.
+ *
+ * the Boot config needs to be adjusted by the ARM prior to starting
+ * the ucode if the Command/Status area isn't at 0x32 in CF space
+ * (ie. beginning of SRAM).
+ */
+
+#define HDR_OFFSET 0x400
+
+/* Info: Signature & version */
+#define HDR_SYS_SIG0x00/* 2 bytes system signature */
+#define  SYS_SIG_SHARED0x5348
+#define  SYS_SIG_SPLIT 0x5350
+#define HDR_FW_VERS0x02/* 2 bytes Major.Minor */
+#define HDR_API_VERS   0x04/* 2 bytes Major.Minor */
+#define  API_VERSION_MAJ   2   /* Current version */
+#define  API_VERSION_MIN   1
+#define HDR_FW_OPTIONS 0x08/* 4 bytes option flags */
+#define  FW_OPTION_TRACE_EN0x0001  /* FW tracing enabled */
+#define FW_OPTION_CONT_CLOCK   0x0002  /* Continuous clocking 
supported */
+#define HDR_FW_SIZE0x10/* 4 bytes size for combo image */
+
+/* Boot Config: Address of Command/Status area */
+#define HDR_CMD_STAT_AREA  0x80/* 4 bytes CF address */
+#define HDR_FW_CONTROL 0x84/* 4 bytes control flags */
+#define FW_CONTROL_CONT_CLOCK  0x0002  /* Continuous clocking 
enabled */
+#define FW_CONTROL_DUMMY_RD0x0004  /* Extra dummy read 
(AST2400) */
+#define FW_CONTROL_USE_STOP0x0008  /* Use STOP 
instructions */
+#define HDR_CLOCK_GPIO_VADDR   0x90/* 2 bytes offset from GPIO base */
+#define HDR_CLOCK_GPIO_DADDR   0x92/* 2 bytes offset from GPIO base */
+#define HDR_DATA_GPIO_VADDR0x94/* 2 bytes offset from GPIO base */
+#define HDR_DATA_GPIO_DADDR0x96/* 2 bytes offset from GPIO base */
+#define HDR_TRANS_GPIO_VADDR   0x98/* 2 bytes offset from GPIO base */
+#define HDR_TRANS_GPIO_DADDR   0x9a/* 2 bytes offset from GPIO base */
+#define HDR_CLOCK_GPIO_BIT 0x9c/* 1 byte bit number */
+#define HDR_DATA_GPIO_BIT  0x9d/* 1 byte bit number */
+#define HDR_TRANS_GPIO_BIT 0x9e/* 1 byte bit number */
+
+/*
+ *  Command/Status area layout: Main part
+ */
+
+/* Command/Status register:
+ *
+ * +---+
+ * | STAT | RLEN | CLEN | C

[PATCH v3 1/5] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Benjamin Herrenschmidt]

This isn't per-se a real device, it's a pseudo-device that
represents the use of the Aspeed built-in ColdFire to
implement the FSI protocol by bitbanging the GPIOs instead
of doing it from the ARM core.

Thus it's a drop-in replacement for the existing
fsi-master-gpio pseudo-device for use on systems based
on the Aspeed chips. It has most of the same properties,
plus some more needed to operate the coprocessor.

Signed-off-by: Benjamin Herrenschmidt 
---
 .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt

diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
new file mode 100644
index ..431bf8a423ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
@@ -0,0 +1,36 @@
+Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
+
+
+Required properties:
+ - compatible =
+   "aspeed,ast2400-cf-fsi-master" for an AST2400 based system
+   or
+   "aspeed,ast2500-cf-fsi-master" for an AST2500 based system
+
+ - clock-gpios = ;: GPIO for FSI clock
+ - data-gpios = ; : GPIO for FSI data signal
+ - enable-gpios = ;   : GPIO for enable signal
+ - trans-gpios = ;: GPIO for voltage translator enable
+ - mux-gpios = ;  : GPIO for pin multiplexing with other
+  functions (eg, external FSI masters)
+ - memory-region = ;  : Reference to the reserved memory for
+  the ColdFire. Must be 2M aligned on
+ AST2400 and 1M aligned on AST2500
+ - aspeed,sram = ;: Reference to the SRAM node.
+ - aspeed,cvic = ;: Reference to the CVIC node.
+
+Examples:
+
+fsi-master {
+compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
+
+   clock-gpios = < 0>;
+data-gpios = < 1>;
+enable-gpios = < 2>;
+trans-gpios = < 3>;
+mux-gpios = < 4>;
+
+   memory-region = <_memory>;
+   sram = <>;
+   cvic = <>;
+}
-- 
2.17.1

[PATCH v3 3/5] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire

[Benjamin Herrenschmidt]

The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
is currently unused on OpenPower systems.

This adds an alternative to the fsi-master-gpio driver that
uses that coprocessor instead of bit banging from the ARM
core itself. The end result is about 4 times faster.

The firmware for the coprocessor and its source code can be
found at https://github.com/ozbenh/cf-fsi and is system specific.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/fsi/Kconfig  |9 +
 drivers/fsi/Makefile |1 +
 drivers/fsi/cf-fsi-fw.h  |  157 +++
 drivers/fsi/fsi-master-ast-cf.c  | 1438 ++
 include/trace/events/fsi_master_ast_cf.h |  150 +++
 5 files changed, 1755 insertions(+)
 create mode 100644 drivers/fsi/cf-fsi-fw.h
 create mode 100644 drivers/fsi/fsi-master-ast-cf.c
 create mode 100644 include/trace/events/fsi_master_ast_cf.h

diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
index 322cec393cf2..e0220d1e1357 100644
--- a/drivers/fsi/Kconfig
+++ b/drivers/fsi/Kconfig
@@ -27,6 +27,15 @@ config FSI_MASTER_HUB
allow chaining of FSI links to an arbitrary depth.  This allows for
a high target device fanout.
 
+config FSI_MASTER_AST_CF
+   tristate "FSI master based on Aspeed ColdFire coprocessor"
+   depends on GPIOLIB
+   depends on GPIO_ASPEED
+   ---help---
+   This option enables a FSI master using the AST2400 and AST2500 GPIO
+   lines driven by the internal ColdFire coprocessor. This requires
+   the corresponding machine specific ColdFire firmware to be available.
+
 config FSI_SCOM
tristate "SCOM FSI client device driver"
---help---
diff --git a/drivers/fsi/Makefile b/drivers/fsi/Makefile
index 75fdc6d8cfc4..62687ec86d2e 100644
--- a/drivers/fsi/Makefile
+++ b/drivers/fsi/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_FSI) += fsi-core.o
 obj-$(CONFIG_FSI_MASTER_HUB) += fsi-master-hub.o
 obj-$(CONFIG_FSI_MASTER_GPIO) += fsi-master-gpio.o
+obj-$(CONFIG_FSI_MASTER_AST_CF) += fsi-master-ast-cf.o
 obj-$(CONFIG_FSI_SCOM) += fsi-scom.o
 obj-$(CONFIG_FSI_SBEFIFO) += fsi-sbefifo.o
 obj-$(CONFIG_FSI_OCC) += fsi-occ.o
diff --git a/drivers/fsi/cf-fsi-fw.h b/drivers/fsi/cf-fsi-fw.h
new file mode 100644
index ..712df0461911
--- /dev/null
+++ b/drivers/fsi/cf-fsi-fw.h
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0+
+#ifndef __CF_FSI_FW_H
+#define __CF_FSI_FW_H
+
+/*
+ * uCode file layout
+ *
+ * ...03ff : m68k exception vectors
+ * 0400...04ff : Header info & boot config block
+ * 0500... : Code & stack
+ */
+
+/*
+ * Header info & boot config area
+ *
+ * The Header info is built into the ucode and provide version and
+ * platform information.
+ *
+ * the Boot config needs to be adjusted by the ARM prior to starting
+ * the ucode if the Command/Status area isn't at 0x32 in CF space
+ * (ie. beginning of SRAM).
+ */
+
+#define HDR_OFFSET 0x400
+
+/* Info: Signature & version */
+#define HDR_SYS_SIG0x00/* 2 bytes system signature */
+#define  SYS_SIG_SHARED0x5348
+#define  SYS_SIG_SPLIT 0x5350
+#define HDR_FW_VERS0x02/* 2 bytes Major.Minor */
+#define HDR_API_VERS   0x04/* 2 bytes Major.Minor */
+#define  API_VERSION_MAJ   2   /* Current version */
+#define  API_VERSION_MIN   1
+#define HDR_FW_OPTIONS 0x08/* 4 bytes option flags */
+#define  FW_OPTION_TRACE_EN0x0001  /* FW tracing enabled */
+#define FW_OPTION_CONT_CLOCK   0x0002  /* Continuous clocking 
supported */
+#define HDR_FW_SIZE0x10/* 4 bytes size for combo image */
+
+/* Boot Config: Address of Command/Status area */
+#define HDR_CMD_STAT_AREA  0x80/* 4 bytes CF address */
+#define HDR_FW_CONTROL 0x84/* 4 bytes control flags */
+#define FW_CONTROL_CONT_CLOCK  0x0002  /* Continuous clocking 
enabled */
+#define FW_CONTROL_DUMMY_RD0x0004  /* Extra dummy read 
(AST2400) */
+#define FW_CONTROL_USE_STOP0x0008  /* Use STOP 
instructions */
+#define HDR_CLOCK_GPIO_VADDR   0x90/* 2 bytes offset from GPIO base */
+#define HDR_CLOCK_GPIO_DADDR   0x92/* 2 bytes offset from GPIO base */
+#define HDR_DATA_GPIO_VADDR0x94/* 2 bytes offset from GPIO base */
+#define HDR_DATA_GPIO_DADDR0x96/* 2 bytes offset from GPIO base */
+#define HDR_TRANS_GPIO_VADDR   0x98/* 2 bytes offset from GPIO base */
+#define HDR_TRANS_GPIO_DADDR   0x9a/* 2 bytes offset from GPIO base */
+#define HDR_CLOCK_GPIO_BIT 0x9c/* 1 byte bit number */
+#define HDR_DATA_GPIO_BIT  0x9d/* 1 byte bit number */
+#define HDR_TRANS_GPIO_BIT 0x9e/* 1 byte bit number */
+
+/*
+ *  Command/Status area layout: Main part
+ */
+
+/* Command/Status register:
+ *
+ * +---+
+ * | STAT | RLEN | CLEN | C

Re: [PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Benjamin Herrenschmidt]

On Thu, 2018-07-05 at 10:08 -0600, Rob Herring wrote:
> 
> > It's not really a SOC block from a vendor, it's a pseudo-device in a
> > way. The current one that doesn't use the coldfire offload is just
> > compatible "fsi-master-gpio".
> > 
> > I can add a vendor but what should it be ? aspeed because it runs on
> > the aspeed SoCs only ? ibm because we wrote it and FSI is an IBM
> > protocol ?
> 
> I would say aspeed as it is tied to their chip.
> 
> > 
> > - doesn't make sense here though.
> 
> But you do already have  in the compatible, but in a slightly
> different form and position. And "cf" is the block.
>
> So I'd propose: aspeed,ast2500-cf-fsi-master

Ok, I'll do that.

> > 
> > > > +
> > > > + - clock-gpios = ;: GPIO for FSI clock
> > > > + - data-gpios = ; : GPIO for FSI data signal
> > > > + - enable-gpios = ;   : GPIO for enable signal
> > > > + - trans-gpios = ;: GPIO for voltage 
> > > > translator enable
> > > > + - mux-gpios = ;  : GPIO for pin multiplexing with 
> > > > other
> > > 
> > > So the gpio info is pased to the CF? Otherwise, what's the point of
> > > having these in DT?
> > 
> > In the original version you are looking at, they are not passed to the
> > CF per-se but the driver does use aspeed GPIO specific APIs to
> > configure them to be owned by the CF, so we need the references.
> 
> Okay.
> 
> > However, I've just reworked the ucode with a few tricks to avoid losing
> > singificant performance, so that we can indeed pass them to the CF,
> > thus avoiding the need for a per-system image, so the above are here to
> > stay.
> > 
> > > > +  functions (eg, external FSI 
> > > > masters)
> > > > + - memory-region = ;  : Reference to the reserved 
> > > > memory for
> > > > +  the ColdFire. Must be 2M 
> > > > aligned on
> > > > + AST2400 and 1M aligned on AST2500
> > > > + - sram = ;   : Reference to the SRAM 
> > > > node.
> > > > + - cvic = ;   : Reference to the CVIC 
> > > > node.
> > > 
> > > Vendor prefixes.
> > 
> > On what ? Why would an "sram" pointer have a vendor prefix ? Or a
> > memory region pointer ?
> 
> memory-region is a standard property. sram and cvic are not, so should
> have vendor prefixes. However, perhaps we should add a common "sram"
> property to sram/sram.txt.

Hrm... originally vendor prefix on properties were for things that
didn't have a binding afaik. IE a way for an f-code driver to stash
things in the DT that were vendor specific and retrieve them from the
OS driver for example.

Here with well defined bindings it's rather bloaty don't you think ? I
don't strongly object to doing it, it's just a bit ... odd.

Cheers,
Ben.

Re: [PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Benjamin Herrenschmidt]

On Thu, 2018-07-05 at 10:08 -0600, Rob Herring wrote:
> 
> > It's not really a SOC block from a vendor, it's a pseudo-device in a
> > way. The current one that doesn't use the coldfire offload is just
> > compatible "fsi-master-gpio".
> > 
> > I can add a vendor but what should it be ? aspeed because it runs on
> > the aspeed SoCs only ? ibm because we wrote it and FSI is an IBM
> > protocol ?
> 
> I would say aspeed as it is tied to their chip.
> 
> > 
> > - doesn't make sense here though.
> 
> But you do already have  in the compatible, but in a slightly
> different form and position. And "cf" is the block.
>
> So I'd propose: aspeed,ast2500-cf-fsi-master

Ok, I'll do that.

> > 
> > > > +
> > > > + - clock-gpios = ;: GPIO for FSI clock
> > > > + - data-gpios = ; : GPIO for FSI data signal
> > > > + - enable-gpios = ;   : GPIO for enable signal
> > > > + - trans-gpios = ;: GPIO for voltage 
> > > > translator enable
> > > > + - mux-gpios = ;  : GPIO for pin multiplexing with 
> > > > other
> > > 
> > > So the gpio info is pased to the CF? Otherwise, what's the point of
> > > having these in DT?
> > 
> > In the original version you are looking at, they are not passed to the
> > CF per-se but the driver does use aspeed GPIO specific APIs to
> > configure them to be owned by the CF, so we need the references.
> 
> Okay.
> 
> > However, I've just reworked the ucode with a few tricks to avoid losing
> > singificant performance, so that we can indeed pass them to the CF,
> > thus avoiding the need for a per-system image, so the above are here to
> > stay.
> > 
> > > > +  functions (eg, external FSI 
> > > > masters)
> > > > + - memory-region = ;  : Reference to the reserved 
> > > > memory for
> > > > +  the ColdFire. Must be 2M 
> > > > aligned on
> > > > + AST2400 and 1M aligned on AST2500
> > > > + - sram = ;   : Reference to the SRAM 
> > > > node.
> > > > + - cvic = ;   : Reference to the CVIC 
> > > > node.
> > > 
> > > Vendor prefixes.
> > 
> > On what ? Why would an "sram" pointer have a vendor prefix ? Or a
> > memory region pointer ?
> 
> memory-region is a standard property. sram and cvic are not, so should
> have vendor prefixes. However, perhaps we should add a common "sram"
> property to sram/sram.txt.

Hrm... originally vendor prefix on properties were for things that
didn't have a binding afaik. IE a way for an f-code driver to stash
things in the DT that were vendor specific and retrieve them from the
OS driver for example.

Here with well defined bindings it's rather bloaty don't you think ? I
don't strongly object to doing it, it's just a bit ... odd.

Cheers,
Ben.

Re: [PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Rob Herring]

On Tue, Jul 3, 2018 at 7:16 PM Benjamin Herrenschmidt
 wrote:
>
> On Tue, 2018-07-03 at 16:30 -0600, Rob Herring wrote:
> > On Wed, Jun 27, 2018 at 09:26:02AM +1000, Benjamin Herrenschmidt wrote:
> > > This isn't per-se a real device, it's a pseudo-device that
> > > represents the use of the Aspeed built-in ColdFire to
> > > implement the FSI protocol by bitbanging the GPIOs instead
> > > of doing it from the ARM core.
> > >
> > > Thus it's a drop-in replacement for the existing
> > > fsi-master-gpio pseudo-device for use on systems for which
> > > a corresponding firmware file exists. It has most of the
> > > same properties, plus some more needed to operate the
> > > coprocessor.
> > >
> > > Signed-off-by: Benjamin Herrenschmidt 
> > > ---
> > >  .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
> > >  1 file changed, 36 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
> > > b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > > new file mode 100644
> > > index ..50913ae685cc
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > > @@ -0,0 +1,36 @@
> > > +Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
> > > +----
> > > +
> > > +Required properties:
> > > + - compatible =
> > > + "fsi-master-ast-2400-cf" for an AST2400 based system
> > > +   or
> > > + "fsi-master-ast-2500-cf" for an AST2500 based system
> >
> > ,-
>
> It's not really a SOC block from a vendor, it's a pseudo-device in a
> way. The current one that doesn't use the coldfire offload is just
> compatible "fsi-master-gpio".
>
> I can add a vendor but what should it be ? aspeed because it runs on
> the aspeed SoCs only ? ibm because we wrote it and FSI is an IBM
> protocol ?

I would say aspeed as it is tied to their chip.

>
> - doesn't make sense here though.

But you do already have  in the compatible, but in a slightly
different form and position. And "cf" is the block.

So I'd propose: aspeed,ast2500-cf-fsi-master

>
> > > +
> > > + - clock-gpios = ;: GPIO for FSI clock
> > > + - data-gpios = ; : GPIO for FSI data signal
> > > + - enable-gpios = ;   : GPIO for enable signal
> > > + - trans-gpios = ;: GPIO for voltage translator 
> > > enable
> > > + - mux-gpios = ;  : GPIO for pin multiplexing with other
> >
> > So the gpio info is pased to the CF? Otherwise, what's the point of
> > having these in DT?
>
> In the original version you are looking at, they are not passed to the
> CF per-se but the driver does use aspeed GPIO specific APIs to
> configure them to be owned by the CF, so we need the references.

Okay.

> However, I've just reworked the ucode with a few tricks to avoid losing
> singificant performance, so that we can indeed pass them to the CF,
> thus avoiding the need for a per-system image, so the above are here to
> stay.
>
> > > +  functions (eg, external FSI 
> > > masters)
> > > + - memory-region = ;  : Reference to the reserved 
> > > memory for
> > > +  the ColdFire. Must be 2M 
> > > aligned on
> > > + AST2400 and 1M aligned on AST2500
> > > + - sram = ;   : Reference to the SRAM node.
> > > + - cvic = ;   : Reference to the CVIC node.
> >
> > Vendor prefixes.
>
> On what ? Why would an "sram" pointer have a vendor prefix ? Or a
> memory region pointer ?

memory-region is a standard property. sram and cvic are not, so should
have vendor prefixes. However, perhaps we should add a common "sram"
property to sram/sram.txt.

Rob

Re: [PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Rob Herring]

On Tue, Jul 3, 2018 at 7:16 PM Benjamin Herrenschmidt
 wrote:
>
> On Tue, 2018-07-03 at 16:30 -0600, Rob Herring wrote:
> > On Wed, Jun 27, 2018 at 09:26:02AM +1000, Benjamin Herrenschmidt wrote:
> > > This isn't per-se a real device, it's a pseudo-device that
> > > represents the use of the Aspeed built-in ColdFire to
> > > implement the FSI protocol by bitbanging the GPIOs instead
> > > of doing it from the ARM core.
> > >
> > > Thus it's a drop-in replacement for the existing
> > > fsi-master-gpio pseudo-device for use on systems for which
> > > a corresponding firmware file exists. It has most of the
> > > same properties, plus some more needed to operate the
> > > coprocessor.
> > >
> > > Signed-off-by: Benjamin Herrenschmidt 
> > > ---
> > >  .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
> > >  1 file changed, 36 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
> > > b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > > new file mode 100644
> > > index ..50913ae685cc
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > > @@ -0,0 +1,36 @@
> > > +Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
> > > +----
> > > +
> > > +Required properties:
> > > + - compatible =
> > > + "fsi-master-ast-2400-cf" for an AST2400 based system
> > > +   or
> > > + "fsi-master-ast-2500-cf" for an AST2500 based system
> >
> > ,-
>
> It's not really a SOC block from a vendor, it's a pseudo-device in a
> way. The current one that doesn't use the coldfire offload is just
> compatible "fsi-master-gpio".
>
> I can add a vendor but what should it be ? aspeed because it runs on
> the aspeed SoCs only ? ibm because we wrote it and FSI is an IBM
> protocol ?

I would say aspeed as it is tied to their chip.

>
> - doesn't make sense here though.

But you do already have  in the compatible, but in a slightly
different form and position. And "cf" is the block.

So I'd propose: aspeed,ast2500-cf-fsi-master

>
> > > +
> > > + - clock-gpios = ;: GPIO for FSI clock
> > > + - data-gpios = ; : GPIO for FSI data signal
> > > + - enable-gpios = ;   : GPIO for enable signal
> > > + - trans-gpios = ;: GPIO for voltage translator 
> > > enable
> > > + - mux-gpios = ;  : GPIO for pin multiplexing with other
> >
> > So the gpio info is pased to the CF? Otherwise, what's the point of
> > having these in DT?
>
> In the original version you are looking at, they are not passed to the
> CF per-se but the driver does use aspeed GPIO specific APIs to
> configure them to be owned by the CF, so we need the references.

Okay.

> However, I've just reworked the ucode with a few tricks to avoid losing
> singificant performance, so that we can indeed pass them to the CF,
> thus avoiding the need for a per-system image, so the above are here to
> stay.
>
> > > +  functions (eg, external FSI 
> > > masters)
> > > + - memory-region = ;  : Reference to the reserved 
> > > memory for
> > > +  the ColdFire. Must be 2M 
> > > aligned on
> > > + AST2400 and 1M aligned on AST2500
> > > + - sram = ;   : Reference to the SRAM node.
> > > + - cvic = ;   : Reference to the CVIC node.
> >
> > Vendor prefixes.
>
> On what ? Why would an "sram" pointer have a vendor prefix ? Or a
> memory region pointer ?

memory-region is a standard property. sram and cvic are not, so should
have vendor prefixes. However, perhaps we should add a common "sram"
property to sram/sram.txt.

Rob

Re: [PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Benjamin Herrenschmidt]

On Tue, 2018-07-03 at 16:30 -0600, Rob Herring wrote:
> On Wed, Jun 27, 2018 at 09:26:02AM +1000, Benjamin Herrenschmidt wrote:
> > This isn't per-se a real device, it's a pseudo-device that
> > represents the use of the Aspeed built-in ColdFire to
> > implement the FSI protocol by bitbanging the GPIOs instead
> > of doing it from the ARM core.
> > 
> > Thus it's a drop-in replacement for the existing
> > fsi-master-gpio pseudo-device for use on systems for which
> > a corresponding firmware file exists. It has most of the
> > same properties, plus some more needed to operate the
> > coprocessor.
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> >  .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
> >  1 file changed, 36 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
> > b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > new file mode 100644
> > index ..50913ae685cc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > @@ -0,0 +1,36 @@
> > +Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
> > +----
> > +
> > +Required properties:
> > + - compatible =
> > + "fsi-master-ast-2400-cf" for an AST2400 based system
> > +   or
> > + "fsi-master-ast-2500-cf" for an AST2500 based system
> 
> ,-

It's not really a SOC block from a vendor, it's a pseudo-device in a
way. The current one that doesn't use the coldfire offload is just
compatible "fsi-master-gpio".

I can add a vendor but what should it be ? aspeed because it runs on
the aspeed SoCs only ? ibm because we wrote it and FSI is an IBM
protocol ?

- doesn't make sense here though.

> > +
> > + - clock-gpios = ;: GPIO for FSI clock
> > + - data-gpios = ; : GPIO for FSI data signal
> > + - enable-gpios = ;   : GPIO for enable signal
> > + - trans-gpios = ;: GPIO for voltage translator 
> > enable
> > + - mux-gpios = ;  : GPIO for pin multiplexing with other
> 
> So the gpio info is pased to the CF? Otherwise, what's the point of 
> having these in DT?

In the original version you are looking at, they are not passed to the
CF per-se but the driver does use aspeed GPIO specific APIs to
configure them to be owned by the CF, so we need the references.

However, I've just reworked the ucode with a few tricks to avoid losing
singificant performance, so that we can indeed pass them to the CF,
thus avoiding the need for a per-system image, so the above are here to
stay.

> > +  functions (eg, external FSI 
> > masters)
> > + - memory-region = ;  : Reference to the reserved 
> > memory for
> > +  the ColdFire. Must be 2M aligned 
> > on
> > + AST2400 and 1M aligned on AST2500
> > + - sram = ;   : Reference to the SRAM node.
> > + - cvic = ;   : Reference to the CVIC node.
> 
> Vendor prefixes.

On what ? Why would an "sram" pointer have a vendor prefix ? Or a
memory region pointer ?

> > + - fw-name = ; : The name used to construct 
> > the firmware
> > + file name (cf-fsi-.bin)
> 
> firmware-name is used in some other places (and is the full filename).

It's gone in the latest version as there's a single FW file now for all
systems.
> 
> > + - fw-platform-sig = ;  : A signature value that must 
> > match the one
> > + contained in the firmware 
> > image. Known
> > + values are listed in the firmware 
> > interface
> > + file cf-fsi-fw.h
> 
> Vendor prefix unless you think this could be common.

It's going away.

> > +Examples:
> > +
> > +fsi-master {
> > +compatible = "fsi-master-gpio", "fsi-master";
> 
> Forget to update the example?

Indeed :)

> > +clock-gpios = < 0>;
> > +data-gpios = < 1>;
> > +enable-gpios = < 2>;
> > +trans-gpios = < 3>;
> > +mux-gpios = < 4>;
> > +}
> > -- 
> > 2.17.1
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Benjamin Herrenschmidt]

On Tue, 2018-07-03 at 16:30 -0600, Rob Herring wrote:
> On Wed, Jun 27, 2018 at 09:26:02AM +1000, Benjamin Herrenschmidt wrote:
> > This isn't per-se a real device, it's a pseudo-device that
> > represents the use of the Aspeed built-in ColdFire to
> > implement the FSI protocol by bitbanging the GPIOs instead
> > of doing it from the ARM core.
> > 
> > Thus it's a drop-in replacement for the existing
> > fsi-master-gpio pseudo-device for use on systems for which
> > a corresponding firmware file exists. It has most of the
> > same properties, plus some more needed to operate the
> > coprocessor.
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> >  .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
> >  1 file changed, 36 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
> > b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > new file mode 100644
> > index ..50913ae685cc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> > @@ -0,0 +1,36 @@
> > +Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
> > +----
> > +
> > +Required properties:
> > + - compatible =
> > + "fsi-master-ast-2400-cf" for an AST2400 based system
> > +   or
> > + "fsi-master-ast-2500-cf" for an AST2500 based system
> 
> ,-

It's not really a SOC block from a vendor, it's a pseudo-device in a
way. The current one that doesn't use the coldfire offload is just
compatible "fsi-master-gpio".

I can add a vendor but what should it be ? aspeed because it runs on
the aspeed SoCs only ? ibm because we wrote it and FSI is an IBM
protocol ?

- doesn't make sense here though.

> > +
> > + - clock-gpios = ;: GPIO for FSI clock
> > + - data-gpios = ; : GPIO for FSI data signal
> > + - enable-gpios = ;   : GPIO for enable signal
> > + - trans-gpios = ;: GPIO for voltage translator 
> > enable
> > + - mux-gpios = ;  : GPIO for pin multiplexing with other
> 
> So the gpio info is pased to the CF? Otherwise, what's the point of 
> having these in DT?

In the original version you are looking at, they are not passed to the
CF per-se but the driver does use aspeed GPIO specific APIs to
configure them to be owned by the CF, so we need the references.

However, I've just reworked the ucode with a few tricks to avoid losing
singificant performance, so that we can indeed pass them to the CF,
thus avoiding the need for a per-system image, so the above are here to
stay.

> > +  functions (eg, external FSI 
> > masters)
> > + - memory-region = ;  : Reference to the reserved 
> > memory for
> > +  the ColdFire. Must be 2M aligned 
> > on
> > + AST2400 and 1M aligned on AST2500
> > + - sram = ;   : Reference to the SRAM node.
> > + - cvic = ;   : Reference to the CVIC node.
> 
> Vendor prefixes.

On what ? Why would an "sram" pointer have a vendor prefix ? Or a
memory region pointer ?

> > + - fw-name = ; : The name used to construct 
> > the firmware
> > + file name (cf-fsi-.bin)
> 
> firmware-name is used in some other places (and is the full filename).

It's gone in the latest version as there's a single FW file now for all
systems.
> 
> > + - fw-platform-sig = ;  : A signature value that must 
> > match the one
> > + contained in the firmware 
> > image. Known
> > + values are listed in the firmware 
> > interface
> > + file cf-fsi-fw.h
> 
> Vendor prefix unless you think this could be common.

It's going away.

> > +Examples:
> > +
> > +fsi-master {
> > +compatible = "fsi-master-gpio", "fsi-master";
> 
> Forget to update the example?

Indeed :)

> > +clock-gpios = < 0>;
> > +data-gpios = < 1>;
> > +enable-gpios = < 2>;
> > +trans-gpios = < 3>;
> > +mux-gpios = < 4>;
> > +}
> > -- 
> > 2.17.1
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Rob Herring]

On Wed, Jun 27, 2018 at 09:26:02AM +1000, Benjamin Herrenschmidt wrote:
> This isn't per-se a real device, it's a pseudo-device that
> represents the use of the Aspeed built-in ColdFire to
> implement the FSI protocol by bitbanging the GPIOs instead
> of doing it from the ARM core.
> 
> Thus it's a drop-in replacement for the existing
> fsi-master-gpio pseudo-device for use on systems for which
> a corresponding firmware file exists. It has most of the
> same properties, plus some more needed to operate the
> coprocessor.
> 
> Signed-off-by: Benjamin Herrenschmidt 
> ---
>  .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
>  1 file changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> 
> diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
> b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> new file mode 100644
> index ..50913ae685cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> @@ -0,0 +1,36 @@
> +Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
> +
> +
> +Required properties:
> + - compatible =
> +   "fsi-master-ast-2400-cf" for an AST2400 based system
> + or
> +   "fsi-master-ast-2500-cf" for an AST2500 based system

,-

> +
> + - clock-gpios = ;  : GPIO for FSI clock
> + - data-gpios = ;   : GPIO for FSI data signal
> + - enable-gpios = ; : GPIO for enable signal
> + - trans-gpios = ;  : GPIO for voltage translator enable
> + - mux-gpios = ;: GPIO for pin multiplexing with other

So the gpio info is pased to the CF? Otherwise, what's the point of 
having these in DT?

> +  functions (eg, external FSI 
> masters)
> + - memory-region = ;: Reference to the reserved 
> memory for
> +  the ColdFire. Must be 2M aligned on
> +   AST2400 and 1M aligned on AST2500

> + - sram = ; : Reference to the SRAM node.
> + - cvic = ; : Reference to the CVIC node.

Vendor prefixes.

> + - fw-name = ;   : The name used to construct 
> the firmware
> +   file name (cf-fsi-.bin)

firmware-name is used in some other places (and is the full filename).

> + - fw-platform-sig = ;: A signature value that must 
> match the one
> +       contained in the firmware image. Known
> +   values are listed in the firmware 
> interface
> +   file cf-fsi-fw.h

Vendor prefix unless you think this could be common.

> +Examples:
> +
> +fsi-master {
> +compatible = "fsi-master-gpio", "fsi-master";

Forget to update the example?

> +clock-gpios = < 0>;
> +data-gpios = < 1>;
> +enable-gpios = < 2>;
> +trans-gpios = < 3>;
> +mux-gpios = < 4>;
> +}
> -- 
> 2.17.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Rob Herring]

On Wed, Jun 27, 2018 at 09:26:02AM +1000, Benjamin Herrenschmidt wrote:
> This isn't per-se a real device, it's a pseudo-device that
> represents the use of the Aspeed built-in ColdFire to
> implement the FSI protocol by bitbanging the GPIOs instead
> of doing it from the ARM core.
> 
> Thus it's a drop-in replacement for the existing
> fsi-master-gpio pseudo-device for use on systems for which
> a corresponding firmware file exists. It has most of the
> same properties, plus some more needed to operate the
> coprocessor.
> 
> Signed-off-by: Benjamin Herrenschmidt 
> ---
>  .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
>  1 file changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> 
> diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
> b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> new file mode 100644
> index ..50913ae685cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
> @@ -0,0 +1,36 @@
> +Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
> +
> +
> +Required properties:
> + - compatible =
> +   "fsi-master-ast-2400-cf" for an AST2400 based system
> + or
> +   "fsi-master-ast-2500-cf" for an AST2500 based system

,-

> +
> + - clock-gpios = ;  : GPIO for FSI clock
> + - data-gpios = ;   : GPIO for FSI data signal
> + - enable-gpios = ; : GPIO for enable signal
> + - trans-gpios = ;  : GPIO for voltage translator enable
> + - mux-gpios = ;: GPIO for pin multiplexing with other

So the gpio info is pased to the CF? Otherwise, what's the point of 
having these in DT?

> +  functions (eg, external FSI 
> masters)
> + - memory-region = ;: Reference to the reserved 
> memory for
> +  the ColdFire. Must be 2M aligned on
> +   AST2400 and 1M aligned on AST2500

> + - sram = ; : Reference to the SRAM node.
> + - cvic = ; : Reference to the CVIC node.

Vendor prefixes.

> + - fw-name = ;   : The name used to construct 
> the firmware
> +   file name (cf-fsi-.bin)

firmware-name is used in some other places (and is the full filename).

> + - fw-platform-sig = ;: A signature value that must 
> match the one
> +       contained in the firmware image. Known
> +   values are listed in the firmware 
> interface
> +   file cf-fsi-fw.h

Vendor prefix unless you think this could be common.

> +Examples:
> +
> +fsi-master {
> +compatible = "fsi-master-gpio", "fsi-master";

Forget to update the example?

> +clock-gpios = < 0>;
> +data-gpios = < 1>;
> +enable-gpios = < 2>;
> +trans-gpios = < 3>;
> +mux-gpios = < 4>;
> +}
> -- 
> 2.17.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 12/14] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire

[Joel Stanley]

Hi Ben,

On 27 June 2018 at 08:56, Benjamin Herrenschmidt
 wrote:
> The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
> is currently unused on OpenPower systems.
>
> This adds an alternative to the fsi-master-gpio driver that
> uses that coprocessor instead of bit banging from the ARM
> core itself. The end result is about 4 times faster.
>
> The firmware for the coprocessor and its source code can be
> found at https://github.com/ozbenh/cf-fsi and is system specific.
>
> Currently tested on Romulus and Palmetto systems.
>
> Signed-off-by: Benjamin Herrenschmidt 

Nice work. I gave this a spin on Romulus and it looked good.

If you run it through sparse there are a bunch of things to fix. I've
also got some comments below.

> --- /dev/null
> +++ b/drivers/fsi/cf-fsi-fw.h
> @@ -0,0 +1,131 @@


Copyright?

> +#ifndef __CF_FSI_FW_H
> +#define __CF_FSI_FW_H
> +
> +/*
> + * uCode file layout
> + *
> + * ...03ff : m68k exception vectors
> + * 0400...04ff : Header info & boot config block
> + * 0500... : Code & stack
> + */

> diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
> new file mode 100644
> index ..6b17f27c27f6
> --- /dev/null
> +++ b/drivers/fsi/fsi-master-ast-cf.c
> @@ -0,0 +1,1376 @@
> +// SPDX-License-Identifier: GPL-2.0

Normally 2+ for new IBM code? You also need something like this on the
next line:

// Copyright 2018 IBM Corp

> +static int read_copro_response(struct fsi_master_acf *master, uint8_t size,
> +  __be32 *response, u8 *tag)
> +{
> +   u8 rtag = readb(master->sram + STAT_RTAG);
> +   u8 rcrc = readb(master->sram + STAT_RCRC);
> +   __be32 rdata = 0;
> +   u32 crc;
> +   u8 ack;
> +
> +   *tag = ack = rtag & 3;
> +
> +   /* we have a whole message now; check CRC */
> +   crc = crc4(0, 1, 1);
> +   crc = crc4(crc, rtag, 4);
> +   if (ack == FSI_RESP_ACK && size) {
> +   rdata = readl(master->sram + RSP_DATA);
> +   crc = crc4(crc, be32_to_cpu(rdata), 32);
> +   if (response)
> +   *response = rdata;
> +   }
> +   crc = crc4(crc, rcrc, 4);
> +
> +   trace_fsi_master_acf_copro_response(master, rtag, rcrc, rdata, crc == 
> 0);
> +
> +   if (crc) {
> +   /*
> +* Check if it's all 1's or all 0's, that probably means
> +* the host is off
> +*/
> +   if ((rtag == 0xf && rcrc == 0xf) || (rtag == 0 && rcrc == 0))
> +   return -ENODEV;
> +   dev_dbg(master->dev, "Bad response CRC !\n");
> +   return -EAGAIN;
> +   }
> +   return 0;
> +}
> +
> +static int send_term(struct fsi_master_acf *master, uint8_t slave)
> +{
> +   struct fsi_msg cmd;
> +   uint8_t tag;
> +   int rc;
> +
> +   build_term_command(, slave);
> +
> +   rc = send_request(master, , true);
> +   if (rc) {
> +   dev_warn(master->dev, "Error %d sending term\n", rc);
> +   return rc;
> +   }
> +
> +   rc = read_copro_response(master, 0, NULL, );
> +   if (rc < 0) {
> +   dev_err(master->dev,
> +   "TERM failed; lost communication with 
> slave\n");
> +   return -EIO;
> +   } else if (tag != FSI_RESP_ACK) {
> +   dev_err(master->dev, "TERM failed; response %d\n", tag);
> +   return -EIO;
> +   }
> +   return 0;
> +}
> +
> +static void dump_trace(struct fsi_master_acf *master)
> +{
> +   char trbuf[52];

I was checking that this was big enough.

52 = 16 * 3 + '\n' + \0' = 50?

Looks to be okay.

> +   char *p;
> +   int i;
> +
> +   dev_dbg(master->dev,
> +   "CMDSTAT:%08x RTAG=%02x RCRC=%02x RDATA=%02x #INT=%08x\n",
> +  be32_to_cpu(readl(master->sram + CMD_STAT_REG)),
> +  readb(master->sram + STAT_RTAG),
> +  readb(master->sram + STAT_RCRC),
> +  be32_to_cpu(readl(master->sram + RSP_DATA)),
> +  be32_to_cpu(readl(master->sram + INT_CNT)));
> +
> +   for (i = 0; i < 512; i++) {
> +   uint8_t v;
> +   if ((i % 16) == 0)
> +   p = trbuf;
> +   v = readb(master->sram + TRACEBUF + i);
> +   p += sprintf(p, "%02x ", v);
> +   if (((i % 16) == 15) || v == TR_END)
> +   dev_dbg(master-&

Re: [PATCH 12/14] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire

[Joel Stanley]

Hi Ben,

On 27 June 2018 at 08:56, Benjamin Herrenschmidt
 wrote:
> The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
> is currently unused on OpenPower systems.
>
> This adds an alternative to the fsi-master-gpio driver that
> uses that coprocessor instead of bit banging from the ARM
> core itself. The end result is about 4 times faster.
>
> The firmware for the coprocessor and its source code can be
> found at https://github.com/ozbenh/cf-fsi and is system specific.
>
> Currently tested on Romulus and Palmetto systems.
>
> Signed-off-by: Benjamin Herrenschmidt 

Nice work. I gave this a spin on Romulus and it looked good.

If you run it through sparse there are a bunch of things to fix. I've
also got some comments below.

> --- /dev/null
> +++ b/drivers/fsi/cf-fsi-fw.h
> @@ -0,0 +1,131 @@


Copyright?

> +#ifndef __CF_FSI_FW_H
> +#define __CF_FSI_FW_H
> +
> +/*
> + * uCode file layout
> + *
> + * ...03ff : m68k exception vectors
> + * 0400...04ff : Header info & boot config block
> + * 0500... : Code & stack
> + */

> diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
> new file mode 100644
> index ..6b17f27c27f6
> --- /dev/null
> +++ b/drivers/fsi/fsi-master-ast-cf.c
> @@ -0,0 +1,1376 @@
> +// SPDX-License-Identifier: GPL-2.0

Normally 2+ for new IBM code? You also need something like this on the
next line:

// Copyright 2018 IBM Corp

> +static int read_copro_response(struct fsi_master_acf *master, uint8_t size,
> +  __be32 *response, u8 *tag)
> +{
> +   u8 rtag = readb(master->sram + STAT_RTAG);
> +   u8 rcrc = readb(master->sram + STAT_RCRC);
> +   __be32 rdata = 0;
> +   u32 crc;
> +   u8 ack;
> +
> +   *tag = ack = rtag & 3;
> +
> +   /* we have a whole message now; check CRC */
> +   crc = crc4(0, 1, 1);
> +   crc = crc4(crc, rtag, 4);
> +   if (ack == FSI_RESP_ACK && size) {
> +   rdata = readl(master->sram + RSP_DATA);
> +   crc = crc4(crc, be32_to_cpu(rdata), 32);
> +   if (response)
> +   *response = rdata;
> +   }
> +   crc = crc4(crc, rcrc, 4);
> +
> +   trace_fsi_master_acf_copro_response(master, rtag, rcrc, rdata, crc == 
> 0);
> +
> +   if (crc) {
> +   /*
> +* Check if it's all 1's or all 0's, that probably means
> +* the host is off
> +*/
> +   if ((rtag == 0xf && rcrc == 0xf) || (rtag == 0 && rcrc == 0))
> +   return -ENODEV;
> +   dev_dbg(master->dev, "Bad response CRC !\n");
> +   return -EAGAIN;
> +   }
> +   return 0;
> +}
> +
> +static int send_term(struct fsi_master_acf *master, uint8_t slave)
> +{
> +   struct fsi_msg cmd;
> +   uint8_t tag;
> +   int rc;
> +
> +   build_term_command(, slave);
> +
> +   rc = send_request(master, , true);
> +   if (rc) {
> +   dev_warn(master->dev, "Error %d sending term\n", rc);
> +   return rc;
> +   }
> +
> +   rc = read_copro_response(master, 0, NULL, );
> +   if (rc < 0) {
> +   dev_err(master->dev,
> +   "TERM failed; lost communication with 
> slave\n");
> +   return -EIO;
> +   } else if (tag != FSI_RESP_ACK) {
> +   dev_err(master->dev, "TERM failed; response %d\n", tag);
> +   return -EIO;
> +   }
> +   return 0;
> +}
> +
> +static void dump_trace(struct fsi_master_acf *master)
> +{
> +   char trbuf[52];

I was checking that this was big enough.

52 = 16 * 3 + '\n' + \0' = 50?

Looks to be okay.

> +   char *p;
> +   int i;
> +
> +   dev_dbg(master->dev,
> +   "CMDSTAT:%08x RTAG=%02x RCRC=%02x RDATA=%02x #INT=%08x\n",
> +  be32_to_cpu(readl(master->sram + CMD_STAT_REG)),
> +  readb(master->sram + STAT_RTAG),
> +  readb(master->sram + STAT_RCRC),
> +  be32_to_cpu(readl(master->sram + RSP_DATA)),
> +  be32_to_cpu(readl(master->sram + INT_CNT)));
> +
> +   for (i = 0; i < 512; i++) {
> +   uint8_t v;
> +   if ((i % 16) == 0)
> +   p = trbuf;
> +   v = readb(master->sram + TRACEBUF + i);
> +   p += sprintf(p, "%02x ", v);
> +   if (((i % 16) == 15) || v == TR_END)
> +   dev_dbg(master-&

Re: [PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Joel Stanley]

On 27 June 2018 at 08:56, Benjamin Herrenschmidt
 wrote:
> This isn't per-se a real device, it's a pseudo-device that
> represents the use of the Aspeed built-in ColdFire to
> implement the FSI protocol by bitbanging the GPIOs instead
> of doing it from the ARM core.
>
> Thus it's a drop-in replacement for the existing
> fsi-master-gpio pseudo-device for use on systems for which
> a corresponding firmware file exists. It has most of the
> same properties, plus some more needed to operate the
> coprocessor.
>
> Signed-off-by: Benjamin Herrenschmidt 

Acked-by: Joel Stanley 

Re: [PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Joel Stanley]

On 27 June 2018 at 08:56, Benjamin Herrenschmidt
 wrote:
> This isn't per-se a real device, it's a pseudo-device that
> represents the use of the Aspeed built-in ColdFire to
> implement the FSI protocol by bitbanging the GPIOs instead
> of doing it from the ARM core.
>
> Thus it's a drop-in replacement for the existing
> fsi-master-gpio pseudo-device for use on systems for which
> a corresponding firmware file exists. It has most of the
> same properties, plus some more needed to operate the
> coprocessor.
>
> Signed-off-by: Benjamin Herrenschmidt 

Acked-by: Joel Stanley 

[PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Benjamin Herrenschmidt]

This isn't per-se a real device, it's a pseudo-device that
represents the use of the Aspeed built-in ColdFire to
implement the FSI protocol by bitbanging the GPIOs instead
of doing it from the ARM core.

Thus it's a drop-in replacement for the existing
fsi-master-gpio pseudo-device for use on systems for which
a corresponding firmware file exists. It has most of the
same properties, plus some more needed to operate the
coprocessor.

Signed-off-by: Benjamin Herrenschmidt 
---
 .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt

diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
new file mode 100644
index ..50913ae685cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
@@ -0,0 +1,36 @@
+Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
+
+
+Required properties:
+ - compatible =
+ "fsi-master-ast-2400-cf" for an AST2400 based system
+   or
+ "fsi-master-ast-2500-cf" for an AST2500 based system
+
+ - clock-gpios = ;: GPIO for FSI clock
+ - data-gpios = ; : GPIO for FSI data signal
+ - enable-gpios = ;   : GPIO for enable signal
+ - trans-gpios = ;: GPIO for voltage translator enable
+ - mux-gpios = ;  : GPIO for pin multiplexing with other
+  functions (eg, external FSI masters)
+ - memory-region = ;  : Reference to the reserved memory for
+  the ColdFire. Must be 2M aligned on
+ AST2400 and 1M aligned on AST2500
+ - sram = ;   : Reference to the SRAM node.
+ - cvic = ;   : Reference to the CVIC node.
+ - fw-name = ; : The name used to construct the 
firmware
+     file name (cf-fsi-.bin)
+ - fw-platform-sig = ;  : A signature value that must match the 
one
+ contained in the firmware image. Known
+ values are listed in the firmware 
interface
+     file cf-fsi-fw.h
+Examples:
+
+fsi-master {
+compatible = "fsi-master-gpio", "fsi-master";
+clock-gpios = < 0>;
+data-gpios = < 1>;
+enable-gpios = < 2>;
+trans-gpios = < 3>;
+mux-gpios = < 4>;
+}
-- 
2.17.1

[PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"

[Benjamin Herrenschmidt]

This isn't per-se a real device, it's a pseudo-device that
represents the use of the Aspeed built-in ColdFire to
implement the FSI protocol by bitbanging the GPIOs instead
of doing it from the ARM core.

Thus it's a drop-in replacement for the existing
fsi-master-gpio pseudo-device for use on systems for which
a corresponding firmware file exists. It has most of the
same properties, plus some more needed to operate the
coprocessor.

Signed-off-by: Benjamin Herrenschmidt 
---
 .../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt

diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 
b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
new file mode 100644
index ..50913ae685cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
@@ -0,0 +1,36 @@
+Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
+
+
+Required properties:
+ - compatible =
+ "fsi-master-ast-2400-cf" for an AST2400 based system
+   or
+ "fsi-master-ast-2500-cf" for an AST2500 based system
+
+ - clock-gpios = ;: GPIO for FSI clock
+ - data-gpios = ; : GPIO for FSI data signal
+ - enable-gpios = ;   : GPIO for enable signal
+ - trans-gpios = ;: GPIO for voltage translator enable
+ - mux-gpios = ;  : GPIO for pin multiplexing with other
+  functions (eg, external FSI masters)
+ - memory-region = ;  : Reference to the reserved memory for
+  the ColdFire. Must be 2M aligned on
+ AST2400 and 1M aligned on AST2500
+ - sram = ;   : Reference to the SRAM node.
+ - cvic = ;   : Reference to the CVIC node.
+ - fw-name = ; : The name used to construct the 
firmware
+     file name (cf-fsi-.bin)
+ - fw-platform-sig = ;  : A signature value that must match the 
one
+ contained in the firmware image. Known
+ values are listed in the firmware 
interface
+     file cf-fsi-fw.h
+Examples:
+
+fsi-master {
+compatible = "fsi-master-gpio", "fsi-master";
+clock-gpios = < 0>;
+data-gpios = < 1>;
+enable-gpios = < 2>;
+trans-gpios = < 3>;
+mux-gpios = < 4>;
+}
-- 
2.17.1

[PATCH 12/14] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire

[Benjamin Herrenschmidt]

The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
is currently unused on OpenPower systems.

This adds an alternative to the fsi-master-gpio driver that
uses that coprocessor instead of bit banging from the ARM
core itself. The end result is about 4 times faster.

The firmware for the coprocessor and its source code can be
found at https://github.com/ozbenh/cf-fsi and is system specific.

Currently tested on Romulus and Palmetto systems.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/fsi/Kconfig  |9 +
 drivers/fsi/Makefile |1 +
 drivers/fsi/cf-fsi-fw.h  |  131 ++
 drivers/fsi/fsi-master-ast-cf.c  | 1376 ++
 include/trace/events/fsi_master_ast_cf.h |  150 +++
 5 files changed, 1667 insertions(+)
 create mode 100644 drivers/fsi/cf-fsi-fw.h
 create mode 100644 drivers/fsi/fsi-master-ast-cf.c
 create mode 100644 include/trace/events/fsi_master_ast_cf.h

diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
index 322cec393cf2..e0220d1e1357 100644
--- a/drivers/fsi/Kconfig
+++ b/drivers/fsi/Kconfig
@@ -27,6 +27,15 @@ config FSI_MASTER_HUB
allow chaining of FSI links to an arbitrary depth.  This allows for
a high target device fanout.
 
+config FSI_MASTER_AST_CF
+   tristate "FSI master based on Aspeed ColdFire coprocessor"
+   depends on GPIOLIB
+   depends on GPIO_ASPEED
+   ---help---
+   This option enables a FSI master using the AST2400 and AST2500 GPIO
+   lines driven by the internal ColdFire coprocessor. This requires
+   the corresponding machine specific ColdFire firmware to be available.
+
 config FSI_SCOM
tristate "SCOM FSI client device driver"
---help---
diff --git a/drivers/fsi/Makefile b/drivers/fsi/Makefile
index 75fdc6d8cfc4..62687ec86d2e 100644
--- a/drivers/fsi/Makefile
+++ b/drivers/fsi/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_FSI) += fsi-core.o
 obj-$(CONFIG_FSI_MASTER_HUB) += fsi-master-hub.o
 obj-$(CONFIG_FSI_MASTER_GPIO) += fsi-master-gpio.o
+obj-$(CONFIG_FSI_MASTER_AST_CF) += fsi-master-ast-cf.o
 obj-$(CONFIG_FSI_SCOM) += fsi-scom.o
 obj-$(CONFIG_FSI_SBEFIFO) += fsi-sbefifo.o
 obj-$(CONFIG_FSI_OCC) += fsi-occ.o
diff --git a/drivers/fsi/cf-fsi-fw.h b/drivers/fsi/cf-fsi-fw.h
new file mode 100644
index ..5f6cffd30861
--- /dev/null
+++ b/drivers/fsi/cf-fsi-fw.h
@@ -0,0 +1,131 @@
+#ifndef __CF_FSI_FW_H
+#define __CF_FSI_FW_H
+
+/*
+ * uCode file layout
+ *
+ * ...03ff : m68k exception vectors
+ * 0400...04ff : Header info & boot config block
+ * 0500... : Code & stack
+ */
+
+/*
+ * Header info & boot config area
+ *
+ * The Header info is built into the ucode and provide version and
+ * platform information.
+ *
+ * the Boot config needs to be adjusted by the ARM prior to starting
+ * the ucode if the Command/Status area isn't at 0x32 in CF space
+ * (ie. beginning of SRAM).
+ */
+
+#define HDR_OFFSET 0x400
+
+/* Info: Signature & version */
+#define HDR_SYS_SIG0x00/* 2 bytes system signature */
+#define  SYS_SIG_ROMULUS   0x526d  /* 'Rm' */
+#define  SYS_SIG_WITHERSPOON   0x5773  /* 'Ws' */
+#define HDR_FW_VERS0x02/* 2 bytes Major.Minor */
+#define HDR_API_VERS   0x04/* 2 bytes Major.Minor */
+#define  API_VERSION_MAJ   1   /* Current version */
+#define  API_VERSION_MIN   1
+#define HDR_FW_OPTIONS 0x08/* 4 bytes option flags */
+#define   FW_OPTION_TRACE_EN   0x0001  /* FW tracing enabled */
+
+/* Boot Config: Address of Command/Status area */
+#define HDR_CMD_STAT_AREA  0x80/* 4 bytes CF address */
+
+/*
+ *  Command/Status area layout: Main part
+ */
+
+/* Command/Status register:
+ *
+ * +---+
+ * | STAT | RLEN | CLEN | CMD  |
+ * |   8  |   8  |   8  |   8  |
+ * +---+
+ *|   |  |  |
+ *status  |  |  |
+ * Response len  |  |
+ * (in bits) |  |
+ *   |  |
+ * Command len  |
+ * (in bits)|
+ *  |
+ *   Command code
+ *
+ * Due to the big endian layout, that means that a byte read will
+ * return the status byte
+ */
+#defineCMD_STAT_REG0x00
+#define  CMD_REG_CMD_MASK  0x00ff
+#define  CMD_REG_CMD_SHIFT 0
+#define  CMD_NONE  0x00
+#define  CMD_COMMAND   0x01
+#define  CMD_BREAK 0x02
+#define  CMD_IDLE_CLOCKS   0x03 /* clen = #clocks */
+#define   CMD_INVALID  0xff
+#define  CMD_REG_CLEN_MASK 0xff00
+#define  CMD_REG_CLEN_SHIFT8
+#define  CMD_REG_RLEN_MASK 0x00ff
+#define  CMD_REG_RLEN_SHIFT16
+#define  CMD_REG_STAT_MASK 0xff00
+#define  CMD_REG_STAT_SHIFT24
+#define  STAT_WORKING  0x00
+#define 

[PATCH 12/14] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire

[Benjamin Herrenschmidt]

The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
is currently unused on OpenPower systems.

This adds an alternative to the fsi-master-gpio driver that
uses that coprocessor instead of bit banging from the ARM
core itself. The end result is about 4 times faster.

The firmware for the coprocessor and its source code can be
found at https://github.com/ozbenh/cf-fsi and is system specific.

Currently tested on Romulus and Palmetto systems.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/fsi/Kconfig  |9 +
 drivers/fsi/Makefile |1 +
 drivers/fsi/cf-fsi-fw.h  |  131 ++
 drivers/fsi/fsi-master-ast-cf.c  | 1376 ++
 include/trace/events/fsi_master_ast_cf.h |  150 +++
 5 files changed, 1667 insertions(+)
 create mode 100644 drivers/fsi/cf-fsi-fw.h
 create mode 100644 drivers/fsi/fsi-master-ast-cf.c
 create mode 100644 include/trace/events/fsi_master_ast_cf.h

diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
index 322cec393cf2..e0220d1e1357 100644
--- a/drivers/fsi/Kconfig
+++ b/drivers/fsi/Kconfig
@@ -27,6 +27,15 @@ config FSI_MASTER_HUB
allow chaining of FSI links to an arbitrary depth.  This allows for
a high target device fanout.
 
+config FSI_MASTER_AST_CF
+   tristate "FSI master based on Aspeed ColdFire coprocessor"
+   depends on GPIOLIB
+   depends on GPIO_ASPEED
+   ---help---
+   This option enables a FSI master using the AST2400 and AST2500 GPIO
+   lines driven by the internal ColdFire coprocessor. This requires
+   the corresponding machine specific ColdFire firmware to be available.
+
 config FSI_SCOM
tristate "SCOM FSI client device driver"
---help---
diff --git a/drivers/fsi/Makefile b/drivers/fsi/Makefile
index 75fdc6d8cfc4..62687ec86d2e 100644
--- a/drivers/fsi/Makefile
+++ b/drivers/fsi/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_FSI) += fsi-core.o
 obj-$(CONFIG_FSI_MASTER_HUB) += fsi-master-hub.o
 obj-$(CONFIG_FSI_MASTER_GPIO) += fsi-master-gpio.o
+obj-$(CONFIG_FSI_MASTER_AST_CF) += fsi-master-ast-cf.o
 obj-$(CONFIG_FSI_SCOM) += fsi-scom.o
 obj-$(CONFIG_FSI_SBEFIFO) += fsi-sbefifo.o
 obj-$(CONFIG_FSI_OCC) += fsi-occ.o
diff --git a/drivers/fsi/cf-fsi-fw.h b/drivers/fsi/cf-fsi-fw.h
new file mode 100644
index ..5f6cffd30861
--- /dev/null
+++ b/drivers/fsi/cf-fsi-fw.h
@@ -0,0 +1,131 @@
+#ifndef __CF_FSI_FW_H
+#define __CF_FSI_FW_H
+
+/*
+ * uCode file layout
+ *
+ * ...03ff : m68k exception vectors
+ * 0400...04ff : Header info & boot config block
+ * 0500... : Code & stack
+ */
+
+/*
+ * Header info & boot config area
+ *
+ * The Header info is built into the ucode and provide version and
+ * platform information.
+ *
+ * the Boot config needs to be adjusted by the ARM prior to starting
+ * the ucode if the Command/Status area isn't at 0x32 in CF space
+ * (ie. beginning of SRAM).
+ */
+
+#define HDR_OFFSET 0x400
+
+/* Info: Signature & version */
+#define HDR_SYS_SIG0x00/* 2 bytes system signature */
+#define  SYS_SIG_ROMULUS   0x526d  /* 'Rm' */
+#define  SYS_SIG_WITHERSPOON   0x5773  /* 'Ws' */
+#define HDR_FW_VERS0x02/* 2 bytes Major.Minor */
+#define HDR_API_VERS   0x04/* 2 bytes Major.Minor */
+#define  API_VERSION_MAJ   1   /* Current version */
+#define  API_VERSION_MIN   1
+#define HDR_FW_OPTIONS 0x08/* 4 bytes option flags */
+#define   FW_OPTION_TRACE_EN   0x0001  /* FW tracing enabled */
+
+/* Boot Config: Address of Command/Status area */
+#define HDR_CMD_STAT_AREA  0x80/* 4 bytes CF address */
+
+/*
+ *  Command/Status area layout: Main part
+ */
+
+/* Command/Status register:
+ *
+ * +---+
+ * | STAT | RLEN | CLEN | CMD  |
+ * |   8  |   8  |   8  |   8  |
+ * +---+
+ *|   |  |  |
+ *status  |  |  |
+ * Response len  |  |
+ * (in bits) |  |
+ *   |  |
+ * Command len  |
+ * (in bits)|
+ *  |
+ *   Command code
+ *
+ * Due to the big endian layout, that means that a byte read will
+ * return the status byte
+ */
+#defineCMD_STAT_REG0x00
+#define  CMD_REG_CMD_MASK  0x00ff
+#define  CMD_REG_CMD_SHIFT 0
+#define  CMD_NONE  0x00
+#define  CMD_COMMAND   0x01
+#define  CMD_BREAK 0x02
+#define  CMD_IDLE_CLOCKS   0x03 /* clen = #clocks */
+#define   CMD_INVALID  0xff
+#define  CMD_REG_CLEN_MASK 0xff00
+#define  CMD_REG_CLEN_SHIFT8
+#define  CMD_REG_RLEN_MASK 0x00ff
+#define  CMD_REG_RLEN_SHIFT16
+#define  CMD_REG_STAT_MASK 0xff00
+#define  CMD_REG_STAT_SHIFT24
+#define  STAT_WORKING  0x00
+#define 

[PATCH 0/3] PATA-Arasan CF: Adjustments for arasan_cf_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 16 Feb 2018 16:51:23 +0100

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation
  Delete an unnecessary variable initialisation
  Move two variable assignments

 drivers/ata/pata_arasan_cf.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

-- 
2.16.1

[PATCH 0/3] PATA-Arasan CF: Adjustments for arasan_cf_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 16 Feb 2018 16:51:23 +0100

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation
  Delete an unnecessary variable initialisation
  Move two variable assignments

 drivers/ata/pata_arasan_cf.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

-- 
2.16.1

Re: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1 Toughbook

[Bjørn Mork]

Johan Hovold <jo...@kernel.org> writes:

> On Mon, Aug 07, 2017 at 04:22:27PM +0200, Oleg Kokorin wrote:
>> From 336f8adb0292a25ea41f0515a80850031f814b9b Mon Sep 17 00:00:00 2001
>> From: Oleg Kokorin <ole2m...@mail.com>
>> Date: Mon, 7 Aug 2017 15:35:53 +0200
>> Subject: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1
>>  Toughbook
>
> Please use
>
>   USB: serial: qcserial: add support for Panasonic CF-U1 Toughbook
>
> as Subject (patch summary), and also add a commit message here (e.g.
> your current summary).
>
>> Signed-off-by: Oleg Kokorin <ole2m...@mail.com>
>> ---
>>  drivers/usb/serial/qcserial.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
>> index ebc0bee..53786ce 100644
>> --- a/drivers/usb/serial/qcserial.c
>> +++ b/drivers/usb/serial/qcserial.c
>> @@ -76,6 +76,8 @@ static const struct usb_device_id id_table[] = {
>> {DEVICE_G1K(0x1bc7, 0x900e)},   /* Telit Gobi QDL device */
>>  
>> /* Gobi 2000 devices */
>> +   {USB_DEVICE(0x04da, 0x250e)},   /* Panasonic Gobi 2000 QDL device */
>> +   {USB_DEVICE(0x04da, 0x250f)},   /* Panasonic Gobi 2000 Modem device 
>> */
>
> This patch is whitespace-damaged and does not apply. Please try sending
> the patch to yourself first (e.g. using git-send-email) and make sure
> you can apply it it with git am. Running checkpatch on the result is
> also a good idea.

And please send a patch for qmi_wwan too, assuming this really is a Gobi
2000 modem. Thanks.


Bjørn

Re: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1 Toughbook

[Bjørn Mork]

Johan Hovold  writes:

> On Mon, Aug 07, 2017 at 04:22:27PM +0200, Oleg Kokorin wrote:
>> From 336f8adb0292a25ea41f0515a80850031f814b9b Mon Sep 17 00:00:00 2001
>> From: Oleg Kokorin 
>> Date: Mon, 7 Aug 2017 15:35:53 +0200
>> Subject: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1
>>  Toughbook
>
> Please use
>
>   USB: serial: qcserial: add support for Panasonic CF-U1 Toughbook
>
> as Subject (patch summary), and also add a commit message here (e.g.
> your current summary).
>
>> Signed-off-by: Oleg Kokorin 
>> ---
>>  drivers/usb/serial/qcserial.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
>> index ebc0bee..53786ce 100644
>> --- a/drivers/usb/serial/qcserial.c
>> +++ b/drivers/usb/serial/qcserial.c
>> @@ -76,6 +76,8 @@ static const struct usb_device_id id_table[] = {
>> {DEVICE_G1K(0x1bc7, 0x900e)},   /* Telit Gobi QDL device */
>>  
>> /* Gobi 2000 devices */
>> +   {USB_DEVICE(0x04da, 0x250e)},   /* Panasonic Gobi 2000 QDL device */
>> +   {USB_DEVICE(0x04da, 0x250f)},   /* Panasonic Gobi 2000 Modem device 
>> */
>
> This patch is whitespace-damaged and does not apply. Please try sending
> the patch to yourself first (e.g. using git-send-email) and make sure
> you can apply it it with git am. Running checkpatch on the result is
> also a good idea.

And please send a patch for qmi_wwan too, assuming this really is a Gobi
2000 modem. Thanks.


Bjørn

Re: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1 Toughbook

[Johan Hovold]

On Mon, Aug 07, 2017 at 04:22:27PM +0200, Oleg Kokorin wrote:
> From 336f8adb0292a25ea41f0515a80850031f814b9b Mon Sep 17 00:00:00 2001
> From: Oleg Kokorin <ole2m...@mail.com>
> Date: Mon, 7 Aug 2017 15:35:53 +0200
> Subject: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1
>  Toughbook

Please use

USB: serial: qcserial: add support for Panasonic CF-U1 Toughbook

as Subject (patch summary), and also add a commit message here (e.g.
your current summary).

> Signed-off-by: Oleg Kokorin <ole2m...@mail.com>
> ---
>  drivers/usb/serial/qcserial.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> index ebc0bee..53786ce 100644
> --- a/drivers/usb/serial/qcserial.c
> +++ b/drivers/usb/serial/qcserial.c
> @@ -76,6 +76,8 @@ static const struct usb_device_id id_table[] = {
> {DEVICE_G1K(0x1bc7, 0x900e)},   /* Telit Gobi QDL device */
>  
> /* Gobi 2000 devices */
> +   {USB_DEVICE(0x04da, 0x250e)},   /* Panasonic Gobi 2000 QDL device */
> +   {USB_DEVICE(0x04da, 0x250f)},   /* Panasonic Gobi 2000 Modem device */

This patch is whitespace-damaged and does not apply. Please try sending
the patch to yourself first (e.g. using git-send-email) and make sure
you can apply it it with git am. Running checkpatch on the result is
also a good idea.

> {USB_DEVICE(0x1410, 0xa010)},   /* Novatel Gobi 2000 QDL device */
> {USB_DEVICE(0x1410, 0xa011)},   /* Novatel Gobi 2000 QDL device */
> {USB_DEVICE(0x1410, 0xa012)},   /* Novatel Gobi 2000 QDL device */

Thanks,
Johan

Re: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1 Toughbook

[Johan Hovold]

On Mon, Aug 07, 2017 at 04:22:27PM +0200, Oleg Kokorin wrote:
> From 336f8adb0292a25ea41f0515a80850031f814b9b Mon Sep 17 00:00:00 2001
> From: Oleg Kokorin 
> Date: Mon, 7 Aug 2017 15:35:53 +0200
> Subject: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1
>  Toughbook

Please use

USB: serial: qcserial: add support for Panasonic CF-U1 Toughbook

as Subject (patch summary), and also add a commit message here (e.g.
your current summary).

> Signed-off-by: Oleg Kokorin 
> ---
>  drivers/usb/serial/qcserial.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> index ebc0bee..53786ce 100644
> --- a/drivers/usb/serial/qcserial.c
> +++ b/drivers/usb/serial/qcserial.c
> @@ -76,6 +76,8 @@ static const struct usb_device_id id_table[] = {
> {DEVICE_G1K(0x1bc7, 0x900e)},   /* Telit Gobi QDL device */
>  
> /* Gobi 2000 devices */
> +   {USB_DEVICE(0x04da, 0x250e)},   /* Panasonic Gobi 2000 QDL device */
> +   {USB_DEVICE(0x04da, 0x250f)},   /* Panasonic Gobi 2000 Modem device */

This patch is whitespace-damaged and does not apply. Please try sending
the patch to yourself first (e.g. using git-send-email) and make sure
you can apply it it with git am. Running checkpatch on the result is
also a good idea.

> {USB_DEVICE(0x1410, 0xa010)},   /* Novatel Gobi 2000 QDL device */
> {USB_DEVICE(0x1410, 0xa011)},   /* Novatel Gobi 2000 QDL device */
> {USB_DEVICE(0x1410, 0xa012)},   /* Novatel Gobi 2000 QDL device */

Thanks,
Johan

[tip:x86/asm] x86, bitops: remove use of "sbb" to return CF

[tip-bot for H. Peter Anvin]

Commit-ID:  2823d4da5d8a0c222747b24eceb65f5b30717d02
Gitweb: http://git.kernel.org/tip/2823d4da5d8a0c222747b24eceb65f5b30717d02
Author: H. Peter Anvin <h...@zytor.com>
AuthorDate: Wed, 8 Jun 2016 12:38:37 -0700
Committer:  H. Peter Anvin <h...@linux.intel.com>
CommitDate: Wed, 8 Jun 2016 12:41:20 -0700

x86, bitops: remove use of "sbb" to return CF

Use SETC instead of SBB to return the value of CF from assembly. Using
SETcc enables uniformity with other flags-returning pieces of assembly
code.

Signed-off-by: H. Peter Anvin <h...@zytor.com>
Link: 
http://lkml.kernel.org/r/1465414726-197858-2-git-send-email-...@linux.intel.com
Reviewed-by: Andy Lutomirski <l...@kernel.org>
Reviewed-by: Borislav Petkov <b...@suse.de>
Acked-by: Peter Zijlstra (Intel) <pet...@infradead.org>
---
 arch/x86/include/asm/bitops.h  | 24 
 arch/x86/include/asm/percpu.h  | 12 ++--
 arch/x86/include/asm/signal.h  |  6 +++---
 arch/x86/include/asm/sync_bitops.h | 18 +-
 arch/x86/kernel/vm86_32.c  |  5 +
 5 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 7766d1c..b2b797d 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -230,11 +230,11 @@ test_and_set_bit_lock(long nr, volatile unsigned long 
*addr)
  */
 static __always_inline int __test_and_set_bit(long nr, volatile unsigned long 
*addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm("bts %2,%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit), ADDR
+   "setc %0"
+   : "=qm" (oldbit), ADDR
: "Ir" (nr));
return oldbit;
 }
@@ -270,11 +270,11 @@ static __always_inline int test_and_clear_bit(long nr, 
volatile unsigned long *a
  */
 static __always_inline int __test_and_clear_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btr %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr));
return oldbit;
 }
@@ -282,11 +282,11 @@ static __always_inline int __test_and_clear_bit(long nr, 
volatile unsigned long
 /* WARNING: non atomic and it can be reordered! */
 static __always_inline int __test_and_change_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btc %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr) : "memory");
 
return oldbit;
@@ -313,11 +313,11 @@ static __always_inline int constant_test_bit(long nr, 
const volatile unsigned lo
 
 static __always_inline int variable_test_bit(long nr, volatile const unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit)
+"setc %0"
+: "=qm" (oldbit)
 : "m" (*(unsigned long *)addr), "Ir" (nr));
 
return oldbit;
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index e0ba66c..65039e9 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -510,9 +510,9 @@ do {
\
 /* This is not atomic against other CPUs -- CPU preemption needs to be off */
 #define x86_test_and_clear_bit_percpu(bit, var)
\
 ({ \
-   int old__;  \
-   asm volatile("btr %2,"__percpu_arg(1)"\n\tsbbl %0,%0"   \
-: "=r" (old__), "+m" (var) \
+   unsigned char old__;\
+   asm volatile("btr %2,"__percpu_arg(1)"\n\tsetc %0"  \
+: "=qm" (old__), "+m" (var)\
 : "dIr" (bit));\
old__;  \
 })
@@ -532,11 +532,11 @@ static __always_inline int 
x86_this_cpu_constant_test_bit(unsigned int nr,
 static inline int x86_this_cpu_variable_test_bit(int nr,
 const u

[tip:x86/asm] x86, bitops: remove use of "sbb" to return CF

[tip-bot for H. Peter Anvin]

Commit-ID:  2823d4da5d8a0c222747b24eceb65f5b30717d02
Gitweb: http://git.kernel.org/tip/2823d4da5d8a0c222747b24eceb65f5b30717d02
Author: H. Peter Anvin 
AuthorDate: Wed, 8 Jun 2016 12:38:37 -0700
Committer:  H. Peter Anvin 
CommitDate: Wed, 8 Jun 2016 12:41:20 -0700

x86, bitops: remove use of "sbb" to return CF

Use SETC instead of SBB to return the value of CF from assembly. Using
SETcc enables uniformity with other flags-returning pieces of assembly
code.

Signed-off-by: H. Peter Anvin 
Link: 
http://lkml.kernel.org/r/1465414726-197858-2-git-send-email-...@linux.intel.com
Reviewed-by: Andy Lutomirski 
Reviewed-by: Borislav Petkov 
Acked-by: Peter Zijlstra (Intel) 
---
 arch/x86/include/asm/bitops.h  | 24 
 arch/x86/include/asm/percpu.h  | 12 ++--
 arch/x86/include/asm/signal.h  |  6 +++---
 arch/x86/include/asm/sync_bitops.h | 18 +-
 arch/x86/kernel/vm86_32.c  |  5 +
 5 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 7766d1c..b2b797d 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -230,11 +230,11 @@ test_and_set_bit_lock(long nr, volatile unsigned long 
*addr)
  */
 static __always_inline int __test_and_set_bit(long nr, volatile unsigned long 
*addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm("bts %2,%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit), ADDR
+   "setc %0"
+   : "=qm" (oldbit), ADDR
: "Ir" (nr));
return oldbit;
 }
@@ -270,11 +270,11 @@ static __always_inline int test_and_clear_bit(long nr, 
volatile unsigned long *a
  */
 static __always_inline int __test_and_clear_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btr %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr));
return oldbit;
 }
@@ -282,11 +282,11 @@ static __always_inline int __test_and_clear_bit(long nr, 
volatile unsigned long
 /* WARNING: non atomic and it can be reordered! */
 static __always_inline int __test_and_change_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btc %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr) : "memory");
 
return oldbit;
@@ -313,11 +313,11 @@ static __always_inline int constant_test_bit(long nr, 
const volatile unsigned lo
 
 static __always_inline int variable_test_bit(long nr, volatile const unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit)
+"setc %0"
+: "=qm" (oldbit)
 : "m" (*(unsigned long *)addr), "Ir" (nr));
 
return oldbit;
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index e0ba66c..65039e9 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -510,9 +510,9 @@ do {
\
 /* This is not atomic against other CPUs -- CPU preemption needs to be off */
 #define x86_test_and_clear_bit_percpu(bit, var)
\
 ({ \
-   int old__;  \
-   asm volatile("btr %2,"__percpu_arg(1)"\n\tsbbl %0,%0"   \
-: "=r" (old__), "+m" (var) \
+   unsigned char old__;\
+   asm volatile("btr %2,"__percpu_arg(1)"\n\tsetc %0"  \
+: "=qm" (old__), "+m" (var)\
 : "dIr" (bit));\
old__;  \
 })
@@ -532,11 +532,11 @@ static __always_inline int 
x86_this_cpu_constant_test_bit(unsigned int nr,
 static inline int x86_this_cpu_variable_test_bit(int nr,
 const unsigned long __percpu *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt "__percpu_arg(2)&qu

[PATCH v2 01/10] x86, bitops: remove use of "sbb" to return CF

[H. Peter Anvin]

From: "H. Peter Anvin" <h...@zytor.com>

Use SETC instead of SBB to return the value of CF from assembly. Using
SETcc enables uniformity with other flags-returning pieces of assembly
code.

Signed-off-by: H. Peter Anvin <h...@zytor.com>
Reviewed-by: Andy Lutomirski <l...@kernel.org>
Reviewed-by: Borislav Petkov <b...@suse.de>
Acked-by: Peter Zijlstra (Intel) <pet...@infradead.org>
---
 arch/x86/include/asm/bitops.h  | 24 
 arch/x86/include/asm/percpu.h  | 12 ++--
 arch/x86/include/asm/signal.h  |  6 +++---
 arch/x86/include/asm/sync_bitops.h | 18 +-
 arch/x86/kernel/vm86_32.c  |  5 +
 5 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 7766d1c..b2b797d 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -230,11 +230,11 @@ test_and_set_bit_lock(long nr, volatile unsigned long 
*addr)
  */
 static __always_inline int __test_and_set_bit(long nr, volatile unsigned long 
*addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm("bts %2,%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit), ADDR
+   "setc %0"
+   : "=qm" (oldbit), ADDR
: "Ir" (nr));
return oldbit;
 }
@@ -270,11 +270,11 @@ static __always_inline int test_and_clear_bit(long nr, 
volatile unsigned long *a
  */
 static __always_inline int __test_and_clear_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btr %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr));
return oldbit;
 }
@@ -282,11 +282,11 @@ static __always_inline int __test_and_clear_bit(long nr, 
volatile unsigned long
 /* WARNING: non atomic and it can be reordered! */
 static __always_inline int __test_and_change_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btc %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr) : "memory");
 
return oldbit;
@@ -313,11 +313,11 @@ static __always_inline int constant_test_bit(long nr, 
const volatile unsigned lo
 
 static __always_inline int variable_test_bit(long nr, volatile const unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit)
+"setc %0"
+: "=qm" (oldbit)
 : "m" (*(unsigned long *)addr), "Ir" (nr));
 
return oldbit;
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index e0ba66c..65039e9 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -510,9 +510,9 @@ do {
\
 /* This is not atomic against other CPUs -- CPU preemption needs to be off */
 #define x86_test_and_clear_bit_percpu(bit, var)
\
 ({ \
-   int old__;  \
-   asm volatile("btr %2,"__percpu_arg(1)"\n\tsbbl %0,%0"   \
-: "=r" (old__), "+m" (var) \
+   unsigned char old__;\
+   asm volatile("btr %2,"__percpu_arg(1)"\n\tsetc %0"  \
+: "=qm" (old__), "+m" (var)\
 : "dIr" (bit));\
old__;  \
 })
@@ -532,11 +532,11 @@ static __always_inline int 
x86_this_cpu_constant_test_bit(unsigned int nr,
 static inline int x86_this_cpu_variable_test_bit(int nr,
 const unsigned long __percpu *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt "__percpu_arg(2)",%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit)
+   "setc %0"
+   : "=qm" (oldbit)
: "m" (*(unsigned long *)addr

[PATCH v2 01/10] x86, bitops: remove use of "sbb" to return CF

[H. Peter Anvin]

From: "H. Peter Anvin" 

Use SETC instead of SBB to return the value of CF from assembly. Using
SETcc enables uniformity with other flags-returning pieces of assembly
code.

Signed-off-by: H. Peter Anvin 
Reviewed-by: Andy Lutomirski 
Reviewed-by: Borislav Petkov 
Acked-by: Peter Zijlstra (Intel) 
---
 arch/x86/include/asm/bitops.h  | 24 
 arch/x86/include/asm/percpu.h  | 12 ++--
 arch/x86/include/asm/signal.h  |  6 +++---
 arch/x86/include/asm/sync_bitops.h | 18 +-
 arch/x86/kernel/vm86_32.c  |  5 +
 5 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 7766d1c..b2b797d 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -230,11 +230,11 @@ test_and_set_bit_lock(long nr, volatile unsigned long 
*addr)
  */
 static __always_inline int __test_and_set_bit(long nr, volatile unsigned long 
*addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm("bts %2,%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit), ADDR
+   "setc %0"
+   : "=qm" (oldbit), ADDR
: "Ir" (nr));
return oldbit;
 }
@@ -270,11 +270,11 @@ static __always_inline int test_and_clear_bit(long nr, 
volatile unsigned long *a
  */
 static __always_inline int __test_and_clear_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btr %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr));
return oldbit;
 }
@@ -282,11 +282,11 @@ static __always_inline int __test_and_clear_bit(long nr, 
volatile unsigned long
 /* WARNING: non atomic and it can be reordered! */
 static __always_inline int __test_and_change_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btc %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr) : "memory");
 
return oldbit;
@@ -313,11 +313,11 @@ static __always_inline int constant_test_bit(long nr, 
const volatile unsigned lo
 
 static __always_inline int variable_test_bit(long nr, volatile const unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit)
+"setc %0"
+: "=qm" (oldbit)
 : "m" (*(unsigned long *)addr), "Ir" (nr));
 
return oldbit;
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index e0ba66c..65039e9 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -510,9 +510,9 @@ do {
\
 /* This is not atomic against other CPUs -- CPU preemption needs to be off */
 #define x86_test_and_clear_bit_percpu(bit, var)
\
 ({ \
-   int old__;  \
-   asm volatile("btr %2,"__percpu_arg(1)"\n\tsbbl %0,%0"   \
-: "=r" (old__), "+m" (var) \
+   unsigned char old__;\
+   asm volatile("btr %2,"__percpu_arg(1)"\n\tsetc %0"  \
+: "=qm" (old__), "+m" (var)\
 : "dIr" (bit));\
old__;  \
 })
@@ -532,11 +532,11 @@ static __always_inline int 
x86_this_cpu_constant_test_bit(unsigned int nr,
 static inline int x86_this_cpu_variable_test_bit(int nr,
 const unsigned long __percpu *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt "__percpu_arg(2)",%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit)
+   "setc %0"
+   : "=qm" (oldbit)
: "m" (*(unsigned long *)addr), "Ir" (nr));
 
return oldbit;
diff --git a/arch/x86/include/asm/signal.h b/arch/x86/inclu

[tip:x86/asm] x86, bitops: remove use of "sbb" to return CF

[tip-bot for H. Peter Anvin]

Commit-ID:  4ec1063787c26243ab709165bc7b7771a1c19bc6
Gitweb: http://git.kernel.org/tip/4ec1063787c26243ab709165bc7b7771a1c19bc6
Author: H. Peter Anvin <h...@zytor.com>
AuthorDate: Tue, 7 Jun 2016 16:31:00 -0700
Committer:  H. Peter Anvin <h...@linux.intel.com>
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700

x86, bitops: remove use of "sbb" to return CF

Use SETC instead of SBB to return the value of CF from assembly. Using
SETcc enables uniformity with other flags-returning pieces of assembly
code.

Signed-off-by: H. Peter Anvin <h...@zytor.com>
Link: 
http://lkml.kernel.org/r/1465342269-492350-2-git-send-email-...@linux.intel.com
---
 arch/x86/include/asm/bitops.h  | 24 
 arch/x86/include/asm/percpu.h  | 12 ++--
 arch/x86/include/asm/signal.h  |  6 +++---
 arch/x86/include/asm/sync_bitops.h | 18 +-
 arch/x86/kernel/vm86_32.c  |  5 +
 5 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 7766d1c..b2b797d 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -230,11 +230,11 @@ test_and_set_bit_lock(long nr, volatile unsigned long 
*addr)
  */
 static __always_inline int __test_and_set_bit(long nr, volatile unsigned long 
*addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm("bts %2,%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit), ADDR
+   "setc %0"
+   : "=qm" (oldbit), ADDR
: "Ir" (nr));
return oldbit;
 }
@@ -270,11 +270,11 @@ static __always_inline int test_and_clear_bit(long nr, 
volatile unsigned long *a
  */
 static __always_inline int __test_and_clear_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btr %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr));
return oldbit;
 }
@@ -282,11 +282,11 @@ static __always_inline int __test_and_clear_bit(long nr, 
volatile unsigned long
 /* WARNING: non atomic and it can be reordered! */
 static __always_inline int __test_and_change_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btc %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr) : "memory");
 
return oldbit;
@@ -313,11 +313,11 @@ static __always_inline int constant_test_bit(long nr, 
const volatile unsigned lo
 
 static __always_inline int variable_test_bit(long nr, volatile const unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit)
+"setc %0"
+: "=qm" (oldbit)
 : "m" (*(unsigned long *)addr), "Ir" (nr));
 
return oldbit;
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index e0ba66c..65039e9 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -510,9 +510,9 @@ do {
\
 /* This is not atomic against other CPUs -- CPU preemption needs to be off */
 #define x86_test_and_clear_bit_percpu(bit, var)
\
 ({ \
-   int old__;  \
-   asm volatile("btr %2,"__percpu_arg(1)"\n\tsbbl %0,%0"   \
-: "=r" (old__), "+m" (var) \
+   unsigned char old__;\
+   asm volatile("btr %2,"__percpu_arg(1)"\n\tsetc %0"  \
+: "=qm" (old__), "+m" (var)\
 : "dIr" (bit));\
old__;  \
 })
@@ -532,11 +532,11 @@ static __always_inline int 
x86_this_cpu_constant_test_bit(unsigned int nr,
 static inline int x86_this_cpu_variable_test_bit(int nr,
 const unsigned long __percpu *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt "__percpu_arg(2)",%1\n\t"
-

[tip:x86/asm] x86, bitops: remove use of "sbb" to return CF

[tip-bot for H. Peter Anvin]

Commit-ID:  4ec1063787c26243ab709165bc7b7771a1c19bc6
Gitweb: http://git.kernel.org/tip/4ec1063787c26243ab709165bc7b7771a1c19bc6
Author: H. Peter Anvin 
AuthorDate: Tue, 7 Jun 2016 16:31:00 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700

x86, bitops: remove use of "sbb" to return CF

Use SETC instead of SBB to return the value of CF from assembly. Using
SETcc enables uniformity with other flags-returning pieces of assembly
code.

Signed-off-by: H. Peter Anvin 
Link: 
http://lkml.kernel.org/r/1465342269-492350-2-git-send-email-...@linux.intel.com
---
 arch/x86/include/asm/bitops.h  | 24 
 arch/x86/include/asm/percpu.h  | 12 ++--
 arch/x86/include/asm/signal.h  |  6 +++---
 arch/x86/include/asm/sync_bitops.h | 18 +-
 arch/x86/kernel/vm86_32.c  |  5 +
 5 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 7766d1c..b2b797d 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -230,11 +230,11 @@ test_and_set_bit_lock(long nr, volatile unsigned long 
*addr)
  */
 static __always_inline int __test_and_set_bit(long nr, volatile unsigned long 
*addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm("bts %2,%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit), ADDR
+   "setc %0"
+   : "=qm" (oldbit), ADDR
: "Ir" (nr));
return oldbit;
 }
@@ -270,11 +270,11 @@ static __always_inline int test_and_clear_bit(long nr, 
volatile unsigned long *a
  */
 static __always_inline int __test_and_clear_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btr %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr));
return oldbit;
 }
@@ -282,11 +282,11 @@ static __always_inline int __test_and_clear_bit(long nr, 
volatile unsigned long
 /* WARNING: non atomic and it can be reordered! */
 static __always_inline int __test_and_change_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btc %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr) : "memory");
 
return oldbit;
@@ -313,11 +313,11 @@ static __always_inline int constant_test_bit(long nr, 
const volatile unsigned lo
 
 static __always_inline int variable_test_bit(long nr, volatile const unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit)
+"setc %0"
+: "=qm" (oldbit)
 : "m" (*(unsigned long *)addr), "Ir" (nr));
 
return oldbit;
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index e0ba66c..65039e9 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -510,9 +510,9 @@ do {
\
 /* This is not atomic against other CPUs -- CPU preemption needs to be off */
 #define x86_test_and_clear_bit_percpu(bit, var)
\
 ({ \
-   int old__;  \
-   asm volatile("btr %2,"__percpu_arg(1)"\n\tsbbl %0,%0"   \
-: "=r" (old__), "+m" (var) \
+   unsigned char old__;\
+   asm volatile("btr %2,"__percpu_arg(1)"\n\tsetc %0"  \
+: "=qm" (old__), "+m" (var)\
 : "dIr" (bit));\
old__;  \
 })
@@ -532,11 +532,11 @@ static __always_inline int 
x86_this_cpu_constant_test_bit(unsigned int nr,
 static inline int x86_this_cpu_variable_test_bit(int nr,
 const unsigned long __percpu *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt "__percpu_arg(2)",%1\n\t"
-   "sbb %0,%0"
-   : &quo

[PATCH 01/10] x86, bitops: remove use of "sbb" to return CF

[H. Peter Anvin]

From: "H. Peter Anvin" <h...@zytor.com>

Use SETC instead of SBB to return the value of CF from assembly. Using
SETcc enables uniformity with other flags-returning pieces of assembly
code.

Signed-off-by: H. Peter Anvin <h...@zytor.com>
---
 arch/x86/include/asm/bitops.h  | 24 
 arch/x86/include/asm/percpu.h  | 12 ++--
 arch/x86/include/asm/signal.h  |  6 +++---
 arch/x86/include/asm/sync_bitops.h | 18 +-
 arch/x86/kernel/vm86_32.c  |  5 +
 5 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 7766d1c..b2b797d 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -230,11 +230,11 @@ test_and_set_bit_lock(long nr, volatile unsigned long 
*addr)
  */
 static __always_inline int __test_and_set_bit(long nr, volatile unsigned long 
*addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm("bts %2,%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit), ADDR
+   "setc %0"
+   : "=qm" (oldbit), ADDR
: "Ir" (nr));
return oldbit;
 }
@@ -270,11 +270,11 @@ static __always_inline int test_and_clear_bit(long nr, 
volatile unsigned long *a
  */
 static __always_inline int __test_and_clear_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btr %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr));
return oldbit;
 }
@@ -282,11 +282,11 @@ static __always_inline int __test_and_clear_bit(long nr, 
volatile unsigned long
 /* WARNING: non atomic and it can be reordered! */
 static __always_inline int __test_and_change_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btc %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr) : "memory");
 
return oldbit;
@@ -313,11 +313,11 @@ static __always_inline int constant_test_bit(long nr, 
const volatile unsigned lo
 
 static __always_inline int variable_test_bit(long nr, volatile const unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit)
+"setc %0"
+: "=qm" (oldbit)
 : "m" (*(unsigned long *)addr), "Ir" (nr));
 
return oldbit;
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index e0ba66c..65039e9 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -510,9 +510,9 @@ do {
\
 /* This is not atomic against other CPUs -- CPU preemption needs to be off */
 #define x86_test_and_clear_bit_percpu(bit, var)
\
 ({ \
-   int old__;  \
-   asm volatile("btr %2,"__percpu_arg(1)"\n\tsbbl %0,%0"   \
-: "=r" (old__), "+m" (var) \
+   unsigned char old__;\
+   asm volatile("btr %2,"__percpu_arg(1)"\n\tsetc %0"  \
+: "=qm" (old__), "+m" (var)\
 : "dIr" (bit));\
old__;  \
 })
@@ -532,11 +532,11 @@ static __always_inline int 
x86_this_cpu_constant_test_bit(unsigned int nr,
 static inline int x86_this_cpu_variable_test_bit(int nr,
 const unsigned long __percpu *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt "__percpu_arg(2)",%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit)
+   "setc %0"
+   : "=qm" (oldbit)
: "m" (*(unsigned long *)addr), "Ir" (nr));
 
return oldbit;
diff --git a/arch/x86/include/asm/signal.h b/arch/x86/include/asm/signal.h
index 2138c9a..dd1e7d6 100644

[PATCH 01/10] x86, bitops: remove use of "sbb" to return CF

[H. Peter Anvin]

From: "H. Peter Anvin" 

Use SETC instead of SBB to return the value of CF from assembly. Using
SETcc enables uniformity with other flags-returning pieces of assembly
code.

Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/bitops.h  | 24 
 arch/x86/include/asm/percpu.h  | 12 ++--
 arch/x86/include/asm/signal.h  |  6 +++---
 arch/x86/include/asm/sync_bitops.h | 18 +-
 arch/x86/kernel/vm86_32.c  |  5 +
 5 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 7766d1c..b2b797d 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -230,11 +230,11 @@ test_and_set_bit_lock(long nr, volatile unsigned long 
*addr)
  */
 static __always_inline int __test_and_set_bit(long nr, volatile unsigned long 
*addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm("bts %2,%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit), ADDR
+   "setc %0"
+   : "=qm" (oldbit), ADDR
: "Ir" (nr));
return oldbit;
 }
@@ -270,11 +270,11 @@ static __always_inline int test_and_clear_bit(long nr, 
volatile unsigned long *a
  */
 static __always_inline int __test_and_clear_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btr %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr));
return oldbit;
 }
@@ -282,11 +282,11 @@ static __always_inline int __test_and_clear_bit(long nr, 
volatile unsigned long
 /* WARNING: non atomic and it can be reordered! */
 static __always_inline int __test_and_change_bit(long nr, volatile unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("btc %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit), ADDR
+"setc %0"
+: "=qm" (oldbit), ADDR
 : "Ir" (nr) : "memory");
 
return oldbit;
@@ -313,11 +313,11 @@ static __always_inline int constant_test_bit(long nr, 
const volatile unsigned lo
 
 static __always_inline int variable_test_bit(long nr, volatile const unsigned 
long *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt %2,%1\n\t"
-"sbb %0,%0"
-: "=r" (oldbit)
+"setc %0"
+: "=qm" (oldbit)
 : "m" (*(unsigned long *)addr), "Ir" (nr));
 
return oldbit;
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index e0ba66c..65039e9 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -510,9 +510,9 @@ do {
\
 /* This is not atomic against other CPUs -- CPU preemption needs to be off */
 #define x86_test_and_clear_bit_percpu(bit, var)
\
 ({ \
-   int old__;  \
-   asm volatile("btr %2,"__percpu_arg(1)"\n\tsbbl %0,%0"   \
-: "=r" (old__), "+m" (var) \
+   unsigned char old__;\
+   asm volatile("btr %2,"__percpu_arg(1)"\n\tsetc %0"  \
+: "=qm" (old__), "+m" (var)\
 : "dIr" (bit));\
old__;  \
 })
@@ -532,11 +532,11 @@ static __always_inline int 
x86_this_cpu_constant_test_bit(unsigned int nr,
 static inline int x86_this_cpu_variable_test_bit(int nr,
 const unsigned long __percpu *addr)
 {
-   int oldbit;
+   unsigned char oldbit;
 
asm volatile("bt "__percpu_arg(2)",%1\n\t"
-   "sbb %0,%0"
-   : "=r" (oldbit)
+   "setc %0"
+   : "=qm" (oldbit)
: "m" (*(unsigned long *)addr), "Ir" (nr));
 
return oldbit;
diff --git a/arch/x86/include/asm/signal.h b/arch/x86/include/asm/signal.h
index 2138c9a..dd1e7d6 100644
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include

[PATCH 4.4 38/74] pata-rb532-cf: get rid of the irq_to_gpio() call

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Gabor Juhos <juh...@openwrt.org>

commit 018361767a21fb2d5ebd3ac182c04baf8a8b4e08 upstream.

The RB532 platform specific irq_to_gpio() implementation has been
removed with commit 832f5dacfa0b ("MIPS: Remove all the uses of
custom gpio.h"). Now the platform uses the generic stub which causes
the following error:

  pata-rb532-cf pata-rb532-cf: no GPIO found for irq149
  pata-rb532-cf: probe of pata-rb532-cf failed with error -2

Drop the irq_to_gpio() call and get the GPIO number from platform
data instead. After this change, the driver works again:

  scsi host0: pata-rb532-cf
  ata1: PATA max PIO4 irq 149
  ata1.00: CFA: CF 1GB, 20080820, max MWDMA4
  ata1.00: 1989792 sectors, multi 0: LBA
  ata1.00: configured for PIO4
  scsi 0:0:0:0: Direct-Access ATA  CF 1GB   0820 PQ: 0\
  ANSI: 5
  sd 0:0:0:0: [sda] 1989792 512-byte logical blocks: (1.01 GB/971 MiB)
  sd 0:0:0:0: [sda] Write Protect is off
  sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't\
  support DPO or FUA
   sda: sda1 sda2
  sd 0:0:0:0: [sda] Attached SCSI disk

Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h")
Cc: Alban Bedel <al...@free.fr>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: Arnd Bergmann <a...@arndb.de>
Signed-off-by: Gabor Juhos <juh...@openwrt.org>
Signed-off-by: Tejun Heo <t...@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/ata/pata_rb532_cf.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

--- a/drivers/ata/pata_rb532_cf.c
+++ b/drivers/ata/pata_rb532_cf.c
@@ -32,6 +32,8 @@
 #include 
 #include 
 
+#include 
+
 #define DRV_NAME   "pata-rb532-cf"
 #define DRV_VERSION"0.1.0"
 #define DRV_DESC   "PATA driver for RouterBOARD 532 Compact Flash"
@@ -107,6 +109,7 @@ static int rb532_pata_driver_probe(struc
int gpio;
struct resource *res;
struct ata_host *ah;
+   struct cf_device *pdata;
struct rb532_cf_info *info;
int ret;
 
@@ -122,7 +125,13 @@ static int rb532_pata_driver_probe(struc
return -ENOENT;
}
 
-   gpio = irq_to_gpio(irq);
+   pdata = dev_get_platdata(>dev);
+   if (!pdata) {
+   dev_err(>dev, "no platform data specified\n");
+   return -EINVAL;
+   }
+
+   gpio = pdata->gpio_pin;
if (gpio < 0) {
dev_err(>dev, "no GPIO found for irq%d\n", irq);
return -ENOENT;

[PATCH 4.4 38/74] pata-rb532-cf: get rid of the irq_to_gpio() call

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Gabor Juhos 

commit 018361767a21fb2d5ebd3ac182c04baf8a8b4e08 upstream.

The RB532 platform specific irq_to_gpio() implementation has been
removed with commit 832f5dacfa0b ("MIPS: Remove all the uses of
custom gpio.h"). Now the platform uses the generic stub which causes
the following error:

  pata-rb532-cf pata-rb532-cf: no GPIO found for irq149
  pata-rb532-cf: probe of pata-rb532-cf failed with error -2

Drop the irq_to_gpio() call and get the GPIO number from platform
data instead. After this change, the driver works again:

  scsi host0: pata-rb532-cf
  ata1: PATA max PIO4 irq 149
  ata1.00: CFA: CF 1GB, 20080820, max MWDMA4
  ata1.00: 1989792 sectors, multi 0: LBA
  ata1.00: configured for PIO4
  scsi 0:0:0:0: Direct-Access ATA  CF 1GB   0820 PQ: 0\
  ANSI: 5
  sd 0:0:0:0: [sda] 1989792 512-byte logical blocks: (1.01 GB/971 MiB)
  sd 0:0:0:0: [sda] Write Protect is off
  sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't\
  support DPO or FUA
   sda: sda1 sda2
  sd 0:0:0:0: [sda] Attached SCSI disk

Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h")
Cc: Alban Bedel 
Cc: Ralf Baechle 
Cc: Arnd Bergmann 
Signed-off-by: Gabor Juhos 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/ata/pata_rb532_cf.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

--- a/drivers/ata/pata_rb532_cf.c
+++ b/drivers/ata/pata_rb532_cf.c
@@ -32,6 +32,8 @@
 #include 
 #include 
 
+#include 
+
 #define DRV_NAME   "pata-rb532-cf"
 #define DRV_VERSION"0.1.0"
 #define DRV_DESC   "PATA driver for RouterBOARD 532 Compact Flash"
@@ -107,6 +109,7 @@ static int rb532_pata_driver_probe(struc
int gpio;
struct resource *res;
struct ata_host *ah;
+   struct cf_device *pdata;
struct rb532_cf_info *info;
int ret;
 
@@ -122,7 +125,13 @@ static int rb532_pata_driver_probe(struc
return -ENOENT;
}
 
-   gpio = irq_to_gpio(irq);
+   pdata = dev_get_platdata(>dev);
+   if (!pdata) {
+   dev_err(>dev, "no platform data specified\n");
+   return -EINVAL;
+   }
+
+   gpio = pdata->gpio_pin;
if (gpio < 0) {
dev_err(>dev, "no GPIO found for irq%d\n", irq);
return -ENOENT;

4.0-rc2+: PATA CF card not detected in PCMCIA slot

[Pavel Machek]

Hi!

> It seems that pcmcia was unhappy even before, but eject definitely
> oopsed it.

Aha, I was confused; the oops is with 3.18, not with 4.0. For 4.0,
pcmcia does not work at all:

[  617.062718] pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0
[  622.840108] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into 
slot 0
pavel@duo:~$ zcat /proc/config.gz | grep PATA_PCMCIA
CONFIG_PATA_PCMCIA=y


Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/