[PATCH v2 2/2] dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller

[Heiko Schocher]

add compatible entry "nxp,imx8mp-fspi" in NXP FlexSPI controller

Signed-off-by: Heiko Schocher 
---

Changes in v4:
rebased against:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
a43e89624baea ("Merge remote-tracking branch 'spi/for-5.13' into spi-next")

Changes in v3:
- no changes, rebased against
  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
  144c79ef33536 Merge tag 'perf-tools-fixes-for-v5.12-2020-03-07' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux

 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt 
b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
index df178d1b62e67..8f34a7c7d8b84 100644
--- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
@@ -4,6 +4,7 @@ Required properties:
   - compatible : Should be "nxp,lx2160a-fspi"
"nxp,imx8qxp-fspi"
"nxp,imx8mm-fspi"
+   "nxp,imx8mp-fspi"
"nxp,imx8dxl-fspi"
 
   - reg :First contains the register location and length,
-- 
2.29.2

[PATCH v2 1/2] spi: fspi: enable fspi driver for on imx8mp

[Heiko Schocher]

add compatible entry in nxp_fspi driver for imx8mp.

Signed-off-by: Heiko Schocher 
---

Changes in v4:
rebased against:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
a43e89624baea ("Merge remote-tracking branch 'spi/for-5.13' into spi-next")

Changes in v3:
- seperate spi changes from series:
  http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643289.html
  into own series as Kuldeep suggested and rebased against
  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
  144c79ef33536 ("Merge tag 'perf-tools-fixes-for-v5.12-2020-03-07' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux")

Changes in v2:
- work in comments from Marco
  add own compatible entry for imx8mp

 drivers/spi/spi-nxp-fspi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
index ed1e888c7ece4..6e6c2403944dd 100644
--- a/drivers/spi/spi-nxp-fspi.c
+++ b/drivers/spi/spi-nxp-fspi.c
@@ -1242,6 +1242,7 @@ static int nxp_fspi_resume(struct device *dev)
 static const struct of_device_id nxp_fspi_dt_ids[] = {
{ .compatible = "nxp,lx2160a-fspi", .data = (void *)_data, },
{ .compatible = "nxp,imx8mm-fspi", .data = (void *)_data, },
+   { .compatible = "nxp,imx8mp-fspi", .data = (void *)_data, },
{ .compatible = "nxp,imx8qxp-fspi", .data = (void *)_data, },
{ .compatible = "nxp,imx8dxl-fspi", .data = (void *)_data, },
{ /* sentinel */ }
-- 
2.29.2

[PATCH v2 0/2] enable flexspi support on imx8mp

[Heiko Schocher]

add compatible entry in nxp_fspi driver for imx8mp

@Shawn: If this series is accepted, can you apply the DTS patches from
series v2?
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643292.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643293.html


Changes in v4:
rebased against:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
a43e89624baea ("Merge remote-tracking branch 'spi/for-5.13' into spi-next")

Changes in v3:
- seperate spi changes from series:
  http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643289.html
  into own series as Kuldeep suggested and rebased against
  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
  144c79ef33536 ("Merge tag 'perf-tools-fixes-for-v5.12-2020-03-07' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux")
- no changes, rebased against
  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
  144c79ef33536 Merge tag 'perf-tools-fixes-for-v5.12-2020-03-07' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux

Changes in v2:
- work in comments from Marco
  add own compatible entry for imx8mp

Heiko Schocher (2):
  spi: fspi: enable fspi driver for on imx8mp
  dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
controller

 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 +
 drivers/spi/spi-nxp-fspi.c | 1 +
 2 files changed, 2 insertions(+)

-- 
2.29.2

Re: [EXT] [PATCH 0/2] enable flexspi support on imx8mp

[Heiko Schocher]

Hello Kuldeep,

On 16.03.21 07:42, Kuldeep Singh wrote:
> Hi Heiko,
> 
>> -Original Message-----
>> From: Heiko Schocher 
>> Sent: Tuesday, March 16, 2021 10:34 AM
>> To: linux-...@vger.kernel.org
>> Cc: Heiko Schocher ; linux-arm-ker...@lists.infradead.org;
>> Ashish Kumar ; Kuldeep Singh
>> ; Mark Brown ; Rob Herring
>> ; Shawn Guo ; Yogesh Gaur
>> ; devicet...@vger.kernel.org; linux-
>> ker...@vger.kernel.org
>> Subject: [EXT] [PATCH 0/2] enable flexspi support on imx8mp
>>
>> Caution: EXT Email
>>
>> add compatible entry in nxp_fspi driver for imx8mp
>>
>> new in v3:
>> seperate spi changes from series:
>> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.inf
>> radead.org%2Fpipermail%2Flinux-arm-kernel%2F2021-
>> March%2F643289.htmldata=04%7C01%7Ckuldeep.singh%40nxp.com%
>> 7C5da0c3da3dbe410baaf508d8e83903f4%7C686ea1d3bc2b4c6fa92cd99c5c3
>> 01635%7C0%7C0%7C637514678868305498%7CUnknown%7CTWFpbGZsb3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>> D%7C1000sdata=2uy0EKUh4Nt0BceSQbIkCZDfakid3wx5uwebw0DhEIQ
>> %3Dreserved=0
>>
>> into own series as Kuldeep suggested and rebased against
>> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
>> 144c79ef33536 ("Merge tag 'perf-tools-fixes-for-v5.12-2020-03-07' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux")
> 
> The changes are not on on top of spi tree
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
> and therefore may not apply seamlessly.
> 
> I recently added driver support for imx8dxl which is accepted in spi tree
> And these patches will cause conflict with it.
> 
> Kindly rebase these patches on top of the tree.

Sorry, my fault. I thought the patches go into for-next ... 3 days
old ...

Ah, I had the wrong base ... I used "144c79ef33536" but it should
be "a43e89624baea"

Sorry and thanks for detecting!

I sent a new version soon...

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

[PATCH 2/2] dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller

[Heiko Schocher]

add compatible entry "nxp,imx8mp-fspi" in NXP FlexSPI controller

Signed-off-by: Heiko Schocher 
---

Changes in v3:
- no changes, rebased against
  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
  144c79ef33536 Merge tag 'perf-tools-fixes-for-v5.12-2020-03-07' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux

 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt 
b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
index 7ac60d9fe3571..fd5f081f6d91b 100644
--- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
@@ -4,6 +4,7 @@ Required properties:
   - compatible : Should be "nxp,lx2160a-fspi"
"nxp,imx8qxp-fspi"
"nxp,imx8mm-fspi"
+   "nxp,imx8mp-fspi"
 
   - reg :First contains the register location and length,
  Second contains the memory mapping address and length
-- 
2.29.2

[PATCH 1/2] spi: fspi: enable fspi driver for on imx8mp

[Heiko Schocher]

add compatible entry in nxp_fspi driver for imx8mp.

Signed-off-by: Heiko Schocher 
  into own series as Kuldeep suggested and rebased against
  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
  144c79ef33536 ("Merge tag 'perf-tools-fixes-for-v5.12-2020-03-07' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux")

---

Changes in v3:
- seperate spi changes from series:
  http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643289.html

Changes in v2:
- work in comments from Marco
  add own compatible entry for imx8mp

 drivers/spi/spi-nxp-fspi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
index ab9035662717a..19ce4a854cc97 100644
--- a/drivers/spi/spi-nxp-fspi.c
+++ b/drivers/spi/spi-nxp-fspi.c
@@ -1151,6 +1151,7 @@ static int nxp_fspi_resume(struct device *dev)
 static const struct of_device_id nxp_fspi_dt_ids[] = {
{ .compatible = "nxp,lx2160a-fspi", .data = (void *)_data, },
{ .compatible = "nxp,imx8mm-fspi", .data = (void *)_data, },
+   { .compatible = "nxp,imx8mp-fspi", .data = (void *)_data, },
{ .compatible = "nxp,imx8qxp-fspi", .data = (void *)_data, },
{ /* sentinel */ }
 };
-- 
2.29.2

[PATCH 0/2] enable flexspi support on imx8mp

[Heiko Schocher]

add compatible entry in nxp_fspi driver for imx8mp

new in v3:
seperate spi changes from series:
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643289.html

into own series as Kuldeep suggested and rebased against
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
144c79ef33536 ("Merge tag 'perf-tools-fixes-for-v5.12-2020-03-07' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux")

@Shawn: If this series is accepted, can you apply the DTS patches from
series v2?
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643292.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643293.html


Changes in v3:
- seperate spi changes from series:
  http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643289.html
- no changes, rebased against
  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
  144c79ef33536 Merge tag 'perf-tools-fixes-for-v5.12-2020-03-07' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux

Changes in v2:
- work in comments from Marco
  add own compatible entry for imx8mp

Heiko Schocher (2):
  spi: fspi: enable fspi driver for on imx8mp
  dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
controller

 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 +
 drivers/spi/spi-nxp-fspi.c | 1 +
 2 files changed, 2 insertions(+)

-- 
2.29.2

Re: [PATCH v2 0/4] enable flexspi support on imx8mp

[Heiko Schocher]

Hello Shawn,

On 15.03.21 07:47, Shawn Guo wrote:
> On Tue, Mar 09, 2021 at 06:31:12AM +0100, Heiko Schocher wrote:
>>
>> This series enables support for the SPI NOR on the
>> imx8mp based phyboard-pollux-rdk board.
>>
>> Patches new in v2:
>> "spi: fspi: enable fspi driver for on imx8mp"
>> which adds own compatible entry for imx8mp
>>
>> and seperate in own patch the documentation entry in
>> patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI 
>> controller"
>> as checkpatch says:
>>
>> warning: DT binding docs and includes should be a separate patch. See: 
>> Documentation/devicetree/bindings/submitting-patches.rst
>>
>>
>> Changes in v2:
>> - work in comments from Marco
>>   add own compatible entry for imx8mp
>> - work in comments from Marco
>>   - add own compatible entry "nxp,imx8mp-fspi"
>>   - reworked order of properties as Marco mentioned
>> - work in comments from Marco and Teresa
>>   - rename node into "'som_flash: flash@0 { }"
>>   - compatible is now first entry
>>   - removed #size-cells and #address-cells
>> as no child node. If bootloader adds them bootloader
>> can add them too.
>>
>> Heiko Schocher (4):
>>   spi: fspi: enable fspi driver for on imx8mp
>>   dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
>> controller
>>   arm64: dts: imx8mp: add flexspi node
>>   arm64: imx8mp: imx8mp-phycore-som enable spi nor
> 
> Two DTS patch look good.  Ping me when driver and bindings changes are
> accepted.

Thanks!

Hmm.. I have not splitted this series into 2 series... should I do
this now?

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

[PATCH] rtc: rv3028: correct weekday register usage

[Heiko Schocher]

The datasheet for the rv3028 says the weekday has exact 3 bits
and in chapter 3.4.0 for the "3h–Weekday" register it says:
"""
This register holds the current day of the week. Each value represents
one weekday that is assigned by the user. Values will range from 0 to 6
The weekday counter is simply a 3-bit counter which counts up to 6
and then resets to 0.
"""

So do not code weekday bitwise instead, use the raw values from
0-6.

Tested on "PHYTEC phyBOARD-Pollux i.MX8MP" board.

Signed-off-by: Heiko Schocher 
---

 drivers/rtc/rtc-rv3028.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-rv3028.c b/drivers/rtc/rtc-rv3028.c
index 0c48d980d06ae..12c807306893f 100644
--- a/drivers/rtc/rtc-rv3028.c
+++ b/drivers/rtc/rtc-rv3028.c
@@ -320,7 +320,7 @@ static int rv3028_get_time(struct device *dev, struct 
rtc_time *tm)
tm->tm_sec  = bcd2bin(date[RV3028_SEC] & 0x7f);
tm->tm_min  = bcd2bin(date[RV3028_MIN] & 0x7f);
tm->tm_hour = bcd2bin(date[RV3028_HOUR] & 0x3f);
-   tm->tm_wday = ilog2(date[RV3028_WDAY] & 0x7f);
+   tm->tm_wday = date[RV3028_WDAY] & 0x7f;
tm->tm_mday = bcd2bin(date[RV3028_DAY] & 0x3f);
tm->tm_mon  = bcd2bin(date[RV3028_MONTH] & 0x1f) - 1;
tm->tm_year = bcd2bin(date[RV3028_YEAR]) + 100;
@@ -337,7 +337,7 @@ static int rv3028_set_time(struct device *dev, struct 
rtc_time *tm)
date[RV3028_SEC]   = bin2bcd(tm->tm_sec);
date[RV3028_MIN]   = bin2bcd(tm->tm_min);
date[RV3028_HOUR]  = bin2bcd(tm->tm_hour);
-   date[RV3028_WDAY]  = 1 << (tm->tm_wday);
+   date[RV3028_WDAY]  = tm->tm_wday;
date[RV3028_DAY]   = bin2bcd(tm->tm_mday);
date[RV3028_MONTH] = bin2bcd(tm->tm_mon + 1);
date[RV3028_YEAR]  = bin2bcd(tm->tm_year - 100);
-- 
2.29.2

Re: [PATCH v2 0/4] enable flexspi support on imx8mp

[Heiko Schocher]

Hello Marco,

On 09.03.21 09:19, Marco Felsch wrote:
> Hi Heiko,
> 
> On 21-03-09 06:31, Heiko Schocher wrote:
>>
>> This series enables support for the SPI NOR on the
>> imx8mp based phyboard-pollux-rdk board.
>>
>> Patches new in v2:
>> "spi: fspi: enable fspi driver for on imx8mp"
>> which adds own compatible entry for imx8mp
>>
>> and seperate in own patch the documentation entry in
>> patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI 
>> controller"
>> as checkpatch says:
>>
>> warning: DT binding docs and includes should be a separate patch. See: 
>> Documentation/devicetree/bindings/submitting-patches.rst
> 
> Thanks for picking up the comments :) Did you missed to send them or did
> you used an other Cc: and To: for the new patches?

Damn, I use patman tool from u-boot source whoch generates cc list
and missed to add you explicitely to Cc... sorry

They are all on linux-arm-kernel:

http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643290.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643291.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643292.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643293.html

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller

[Heiko Schocher]

Hello Kuldeep,

On 09.03.21 07:29, Kuldeep Singh wrote:
>> Hi!
>>
>> On 09.03.21 06:56, Kuldeep Singh wrote:
>>> Hi Heiko,
>>>
>>>> -Original Message-
>>>> From: Heiko Schocher 
>>>> Sent: Tuesday, March 9, 2021 11:01 AM
>>>> To: linux-arm-ker...@lists.infradead.org
>>>> Cc: Heiko Schocher ; Ashish Kumar ;
>>>> Mark Brown ; Rob Herring ;
>>>> Yogesh Gaur ; devicet...@vger.kernel.org;
>>>> linux- ker...@vger.kernel.org; linux-...@vger.kernel.org
>>>> Subject: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry
>>>> for imx8mp in FlexSPI controller
>>>>
>>>> Caution: EXT Email
>>>>
>>>> add compatible entry "nxp,imx8mp-fspi" in NXP FlexSPI controller
>>>>
>>>> Signed-off-by: Heiko Schocher 
>>>> ---
>>>>
>>>> (no changes since v1)
>>>>
>>>>  Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
>>>> b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
>>>> index 7ac60d9fe3571..fd5f081f6d91b 100644
>>>> --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
>>>> +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
>>>> @@ -4,6 +4,7 @@ Required properties:
>>>>- compatible : Should be "nxp,lx2160a-fspi"
>>>> "nxp,imx8qxp-fspi"
>>>> "nxp,imx8mm-fspi"
>>>> +   "nxp,imx8mp-fspi"
>>>
>>> It seems the changes are not on top of tree. Please see[1] for latest 
>>> changes
>> including imx8dxl entry.
>>> Snippet below:
>>>
>>> Required properties:
>>>   - compatible : Should be "nxp,lx2160a-fspi"
>>>   "nxp,imx8qxp-fspi"
>>>   "nxp,imx8mm-fspi"
>>>   "nxp,imx8dxl-fspi"
>>
>> My patches are based on mainline..
>> *   144c79ef33536 - (origin/master, origin/HEAD) Merge tag 
>> 'perf-tools-fixes-for-
>> v5.12-2020-03-07'
>> of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux (vor 32 Stunden)
>> 
>>
>> Should I post this patch rebased on [1] or may all patches rebased on [1] ?
> 
> Hi Heiko,
> 
> As per cover letter, I can identify that first two are driver/Documentation 
> patches and other two are device-tree patches.
> Device-tree patches(3/4 and 4/4) will go via Shawn tree 
> (git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git)
> And initial two driver patches(1/4 and 2/4) will go via Mark's tree 
> (git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git)
> 
> One approach I can think of is to send driver patches first and later send 
> device-tree patches mentioning dependency on first two patches.

Yep, seems a good approach to me.

> Maybe Mark can comment here if he has any other opinion.

Yep, will wait for more comments, and if all is fine with this
patchset, I can split it into 2 series.

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller

[Heiko Schocher]

Hi!

On 09.03.21 06:56, Kuldeep Singh wrote:
> Hi Heiko,
> 
>> -Original Message-----
>> From: Heiko Schocher 
>> Sent: Tuesday, March 9, 2021 11:01 AM
>> To: linux-arm-ker...@lists.infradead.org
>> Cc: Heiko Schocher ; Ashish Kumar ;
>> Mark Brown ; Rob Herring ; Yogesh
>> Gaur ; devicet...@vger.kernel.org; linux-
>> ker...@vger.kernel.org; linux-...@vger.kernel.org
>> Subject: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry for 
>> imx8mp in
>> FlexSPI controller
>>
>> Caution: EXT Email
>>
>> add compatible entry "nxp,imx8mp-fspi" in NXP FlexSPI controller
>>
>> Signed-off-by: Heiko Schocher 
>> ---
>>
>> (no changes since v1)
>>
>>  Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
>> b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
>> index 7ac60d9fe3571..fd5f081f6d91b 100644
>> --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
>> +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
>> @@ -4,6 +4,7 @@ Required properties:
>>- compatible : Should be "nxp,lx2160a-fspi"
>> "nxp,imx8qxp-fspi"
>> "nxp,imx8mm-fspi"
>> +   "nxp,imx8mp-fspi"
> 
> It seems the changes are not on top of tree. Please see[1] for latest changes 
> including imx8dxl entry.
> Snippet below:
> 
> Required properties:
>   - compatible : Should be "nxp,lx2160a-fspi"
>   "nxp,imx8qxp-fspi"
>   "nxp,imx8mm-fspi"
>   "nxp,imx8dxl-fspi"

My patches are based on mainline..
*   144c79ef33536 - (origin/master, origin/HEAD) Merge tag 
'perf-tools-fixes-for-v5.12-2020-03-07'
of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux (vor 32 Stunden) 


Should I post this patch rebased on [1] or may all patches
rebased on [1] ?

Thanks!

bye,
Heiko
> 
> Thanks
> Kuldeep
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/tree/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
> 

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

[PATCH v2 3/4] arm64: dts: imx8mp: add flexspi node

[Heiko Schocher]

add node for the flexspi modul on imx8mp.

Signed-off-by: Heiko Schocher 

---

Changes in v2:
- work in comments from Marco
  - add own compatible entry "nxp,imx8mp-fspi"
  - reworked order of properties as Marco mentioned

 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index c7523fd4eae9b..18023d97235ed 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -36,6 +36,7 @@ aliases {
serial1 = 
serial2 = 
serial3 = 
+   spi0 = 
};
 
cpus {
@@ -744,6 +745,21 @@ usdhc3: mmc@30b6 {
status = "disabled";
};
 
+   flexspi: spi@30bb {
+   compatible = "nxp,imx8mp-fspi";
+   reg = <0x30bb 0x1>, <0x800 
0x1000>;
+   reg-names = "fspi_base", "fspi_mmap";
+   interrupts = ;
+   clocks = < IMX8MP_CLK_QSPI_ROOT>,
+< IMX8MP_CLK_QSPI_ROOT>;
+   clock-names = "fspi", "fspi_en";
+   assigned-clock-rates = <8000>;
+   assigned-clocks = < IMX8MP_CLK_QSPI>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
sdma1: dma-controller@30bd {
compatible = "fsl,imx8mp-sdma", 
"fsl,imx8mq-sdma";
reg = <0x30bd 0x1>;
-- 
2.29.2

[PATCH v2 4/4] arm64: imx8mp: imx8mp-phycore-som enable spi nor

[Heiko Schocher]

enable the mt25qu256aba spi nor on the imx8mp-phycore-som.

Signed-off-by: Heiko Schocher 

---

Changes in v2:
- work in comments from Marco and Teresa
  - rename node into "'som_flash: flash@0 { }"
  - compatible is now first entry
  - removed #size-cells and #address-cells
as no child node. If bootloader adds them bootloader
can add them too.

 .../dts/freescale/imx8mp-phycore-som.dtsi | 25 +++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
index 44a8c2337cee4..e648b1b6acdaa 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
@@ -65,6 +65,20 @@ ethphy1: ethernet-phy@0 {
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_flexspi0>;
+   status = "okay";
+
+   som_flash: flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <8000>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   };
+};
+
  {
clock-frequency = <40>;
pinctrl-names = "default";
@@ -217,6 +231,17 @@ MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO150x11
>;
};
 
+   pinctrl_flexspi0: flexspi0grp {
+   fsl,pins = <
+   MX8MP_IOMUXC_NAND_ALE__FLEXSPI_A_SCLK   0x1c2
+   MX8MP_IOMUXC_NAND_CE0_B__FLEXSPI_A_SS0_B0x82
+   MX8MP_IOMUXC_NAND_DATA00__FLEXSPI_A_DATA00  0x82
+   MX8MP_IOMUXC_NAND_DATA01__FLEXSPI_A_DATA01  0x82
+   MX8MP_IOMUXC_NAND_DATA02__FLEXSPI_A_DATA02  0x82
+   MX8MP_IOMUXC_NAND_DATA03__FLEXSPI_A_DATA03  0x82
+   >;
+   };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x41c3
-- 
2.29.2

[PATCH v2 2/4] dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller

[Heiko Schocher]

add compatible entry "nxp,imx8mp-fspi" in NXP FlexSPI controller

Signed-off-by: Heiko Schocher 
---

(no changes since v1)

 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt 
b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
index 7ac60d9fe3571..fd5f081f6d91b 100644
--- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
@@ -4,6 +4,7 @@ Required properties:
   - compatible : Should be "nxp,lx2160a-fspi"
"nxp,imx8qxp-fspi"
"nxp,imx8mm-fspi"
+   "nxp,imx8mp-fspi"
 
   - reg :First contains the register location and length,
  Second contains the memory mapping address and length
-- 
2.29.2

[PATCH v2 0/4] enable flexspi support on imx8mp

[Heiko Schocher]

This series enables support for the SPI NOR on the
imx8mp based phyboard-pollux-rdk board.

Patches new in v2:
"spi: fspi: enable fspi driver for on imx8mp"
which adds own compatible entry for imx8mp

and seperate in own patch the documentation entry in
patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller"
as checkpatch says:

warning: DT binding docs and includes should be a separate patch. See: 
Documentation/devicetree/bindings/submitting-patches.rst


Changes in v2:
- work in comments from Marco
  add own compatible entry for imx8mp
- work in comments from Marco
  - add own compatible entry "nxp,imx8mp-fspi"
  - reworked order of properties as Marco mentioned
- work in comments from Marco and Teresa
  - rename node into "'som_flash: flash@0 { }"
  - compatible is now first entry
  - removed #size-cells and #address-cells
as no child node. If bootloader adds them bootloader
can add them too.

Heiko Schocher (4):
  spi: fspi: enable fspi driver for on imx8mp
  dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
controller
  arm64: dts: imx8mp: add flexspi node
  arm64: imx8mp: imx8mp-phycore-som enable spi nor

 .../devicetree/bindings/spi/spi-nxp-fspi.txt  |  1 +
 .../dts/freescale/imx8mp-phycore-som.dtsi | 25 +++
 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16 
 drivers/spi/spi-nxp-fspi.c|  1 +
 4 files changed, 43 insertions(+)

-- 
2.29.2

[PATCH v2 1/4] spi: fspi: enable fspi driver for on imx8mp

[Heiko Schocher]

add compatible entry in nxp_fspi driver for imx8mp.

Signed-off-by: Heiko Schocher 

---

Changes in v2:
- work in comments from Marco
  add own compatible entry for imx8mp

 drivers/spi/spi-nxp-fspi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
index ab9035662717a..19ce4a854cc97 100644
--- a/drivers/spi/spi-nxp-fspi.c
+++ b/drivers/spi/spi-nxp-fspi.c
@@ -1151,6 +1151,7 @@ static int nxp_fspi_resume(struct device *dev)
 static const struct of_device_id nxp_fspi_dt_ids[] = {
{ .compatible = "nxp,lx2160a-fspi", .data = (void *)_data, },
{ .compatible = "nxp,imx8mm-fspi", .data = (void *)_data, },
+   { .compatible = "nxp,imx8mp-fspi", .data = (void *)_data, },
{ .compatible = "nxp,imx8qxp-fspi", .data = (void *)_data, },
{ /* sentinel */ }
 };
-- 
2.29.2

Re: [PATCH 2/2] arm64: imx8mp: imx8mp-phycore-som enable spi nor

[Heiko Schocher]

Hello Marco,

On 08.03.21 10:28, Marco Felsch wrote:
> On 21-03-08 08:52, Teresa Remmet wrote:
>> Hello Marco,
>>
>> Am Montag, den 08.03.2021, 09:40 +0100 schrieb Marco Felsch:
>>> On 21-03-08 07:40, Heiko Schocher wrote:
>>>> enable the mt25qu256aba spi nor on the imx8mp-phycore-som.
>>>>
>>>> Signed-off-by: Heiko Schocher 
>>>> ---
>>>>
>>>>  .../dts/freescale/imx8mp-phycore-som.dtsi | 27
>>>> +++
>>>>  1 file changed, 27 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
>>>> b/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
>>>> index 44a8c2337cee4..0284e7a5c6bba 100644
>>>> --- a/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
>>>> @@ -65,6 +65,22 @@ ethphy1: ethernet-phy@0 {
>>>>};
>>>>  };
>>>>  
>>>> + {
>>>> +  pinctrl-names = "default";
>>>> +  pinctrl-0 = <_flexspi0>;
>>>> +  status = "okay";
>>>> +
>>>> +  flash0: mt25qu256aba@0 {
>>>> +  reg = <0>;
>>>> +  #address-cells = <1>;
>>>> +  #size-cells = <1>;
>>>> +  compatible = "jedec,spi-nor";
>>>
>>> Please make the compatible the first property followed by the reg
>>> property. Also you don't need to add the #size-cells and #address-
>>> cells
>>> now since you don't add a child node.
>>
>> but is this not similar to the label here? If you add partitions in the
>> bootloader you need the cells properties?
> 
> If the bootloader will add partitions the bootloader can add the
> size/address-cells too using the phandle. But this is more a nit.

Yes. I personally prefer to pass mtd partitions through kernel commandline.

I will work in your and Teresas comment, thanks!

bye,
Heiko
> 
> Regards,
>   Marco
> 
>> Teresa
>>
>>>
>>> Regards,
>>>   Marco
>>>
>>>> +  spi-max-frequency = <8000>;
>>>> +  spi-tx-bus-width = <4>;
>>>> +  spi-rx-bus-width = <4>;
>>>> +  };
>>>> +};
>>>> +
>>>>   {
>>>>clock-frequency = <40>;
>>>>pinctrl-names = "default";
>>>> @@ -217,6 +233,17 @@ MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO15   
>>>> 0x11
>>>>>;
>>>>};
>>>>  
>>>> +  pinctrl_flexspi0: flexspi0grp {
>>>> +  fsl,pins = <
>>>> +  MX8MP_IOMUXC_NAND_ALE__FLEXSPI_A_SCLK   
>>>> 0x1c2
>>>> +  MX8MP_IOMUXC_NAND_CE0_B__FLEXSPI_A_SS0_B0x8
>>>> 2
>>>> +  MX8MP_IOMUXC_NAND_DATA00__FLEXSPI_A_DATA00  0x8
>>>> 2
>>>> +  MX8MP_IOMUXC_NAND_DATA01__FLEXSPI_A_DATA01  0x8
>>>> 2
>>>> +  MX8MP_IOMUXC_NAND_DATA02__FLEXSPI_A_DATA02  0x8
>>>> 2
>>>> +  MX8MP_IOMUXC_NAND_DATA03__FLEXSPI_A_DATA03  0x8
>>>> 2
>>>> +  >;
>>>> +  };
>>>> +
>>>>pinctrl_i2c1: i2c1grp {
>>>>fsl,pins = <
>>>>MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x4
>>>> 1c3
>>>> -- 
>>>> 2.29.2
>>>>
>>>>
>>>>
> 

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

[PATCH 2/2] arm64: imx8mp: imx8mp-phycore-som enable spi nor

[Heiko Schocher]

enable the mt25qu256aba spi nor on the imx8mp-phycore-som.

Signed-off-by: Heiko Schocher 
---

 .../dts/freescale/imx8mp-phycore-som.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
index 44a8c2337cee4..0284e7a5c6bba 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
@@ -65,6 +65,22 @@ ethphy1: ethernet-phy@0 {
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_flexspi0>;
+   status = "okay";
+
+   flash0: mt25qu256aba@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   spi-max-frequency = <8000>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   };
+};
+
  {
clock-frequency = <40>;
pinctrl-names = "default";
@@ -217,6 +233,17 @@ MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO150x11
>;
};
 
+   pinctrl_flexspi0: flexspi0grp {
+   fsl,pins = <
+   MX8MP_IOMUXC_NAND_ALE__FLEXSPI_A_SCLK   0x1c2
+   MX8MP_IOMUXC_NAND_CE0_B__FLEXSPI_A_SS0_B0x82
+   MX8MP_IOMUXC_NAND_DATA00__FLEXSPI_A_DATA00  0x82
+   MX8MP_IOMUXC_NAND_DATA01__FLEXSPI_A_DATA01  0x82
+   MX8MP_IOMUXC_NAND_DATA02__FLEXSPI_A_DATA02  0x82
+   MX8MP_IOMUXC_NAND_DATA03__FLEXSPI_A_DATA03  0x82
+   >;
+   };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x41c3
-- 
2.29.2

[PATCH 1/2] arm64: dts: imx8mp: add flexspi node

[Heiko Schocher]

add node for the flexspi modul on imx8mp.

Signed-off-by: Heiko Schocher 

---

 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index c7523fd4eae9b..086cfbbef43d7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -36,6 +36,7 @@ aliases {
serial1 = 
serial2 = 
serial3 = 
+   spi0 = 
};
 
cpus {
@@ -744,6 +745,21 @@ usdhc3: mmc@30b6 {
status = "disabled";
};
 
+   flexspi: spi@30bb {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "nxp,imx8mm-fspi";
+   reg = <0x30bb 0x1>, <0x800 
0x1000>;
+   reg-names = "fspi_base", "fspi_mmap";
+   interrupts = ;
+   clocks = < IMX8MP_CLK_QSPI_ROOT>,
+< IMX8MP_CLK_QSPI_ROOT>;
+   clock-names = "fspi", "fspi_en";
+   assigned-clock-rates = <8000>;
+   assigned-clocks = < IMX8MP_CLK_QSPI>;
+   status = "disabled";
+   };
+
sdma1: dma-controller@30bd {
compatible = "fsl,imx8mp-sdma", 
"fsl,imx8mq-sdma";
reg = <0x30bd 0x1>;
-- 
2.29.2

[PATCH 0/2] enable flexspi support on imx8mp

[Heiko Schocher]

This series enables support for the SPI NOR on the
imx8mp based phyboard-pollux-rdk board.



Heiko Schocher (2):
  arm64: dts: imx8mp: add flexspi node
  arm64: imx8mp: imx8mp-phycore-som enable spi nor

 .../dts/freescale/imx8mp-phycore-som.dtsi | 27 +++
 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16 +++
 2 files changed, 43 insertions(+)

-- 
2.29.2

Re: [PATCH v2 10/12] dt-bindings: arm: fsl: document i.MX6DL Aristainetos boards

[Heiko Schocher]

Hello Krzysztof,

Am 30.09.2020 um 21:01 schrieb Krzysztof Kozlowski:

Document and adjust the compatibles for i.MX6DL based Aristainetos
boards from ABB.

Cc: Heiko Schocher 
Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Use ABB vendor prefix
---
  Documentation/devicetree/bindings/arm/fsl.yaml | 4 
  1 file changed, 4 insertions(+)


Thanks!

Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 11/12] ARM: dts: imx6dl: add compatibles for Aristainetos boards

[Heiko Schocher]

Hello Krzysztof,

Am 30.09.2020 um 21:01 schrieb Krzysztof Kozlowski:

The Aristainetos and Aristainetos2 boards have only SoC compatible.

Cc: Heiko Schocher 
Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Use ABB vendor prefix
---
  arch/arm/boot/dts/imx6dl-aristainetos2_4.dts | 2 +-
  arch/arm/boot/dts/imx6dl-aristainetos2_7.dts | 2 +-
  arch/arm/boot/dts/imx6dl-aristainetos_4.dts  | 2 +-
  arch/arm/boot/dts/imx6dl-aristainetos_7.dts  | 2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)


Thanks!

Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 09/12] dt-bindings: vendor-prefixes: add ABB

[Heiko Schocher]

Hello Krzysztof,

Am 30.09.2020 um 21:01 schrieb Krzysztof Kozlowski:

Document binding for ABB.

Cc: Heiko Schocher 
Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Use ABB vendor prefix
---
  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
  1 file changed, 2 insertions(+)


Thanks!

Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [RFC 12/14] dt-bindings: vendor-prefixes: add Aristainetos

[Heiko Schocher]

Hello Krzysztof,

Am 30.09.2020 um 09:11 schrieb Krzysztof Kozlowski:

On Wed, 30 Sep 2020 at 06:16, Heiko Schocher  wrote:


Hello Krzysztof,

Am 28.09.2020 um 06:04 schrieb Heiko Schocher:

Hello Krzysztof,

Am 26.09.2020 um 18:28 schrieb Krzysztof Kozlowski:

Document binding for an unknown entity Aristainetos with few boards
mainlined.

Cc: Heiko Schocher 
Signed-off-by: Krzysztof Kozlowski 

---

I tried to Google but except the patches from Heiko Schocher, I could
not find any meaningful data.

Heiko, you posted this. Do you know what is it?


aristainetos is the name of the board, so it is not the vendor name.

I just asked the customer if we can add a valid vendor name...


Ok, it is not easy to get an okay from the customer to publish
his name.

Is there a dummy or unknown entry for vendor?


We could use "denx" as it was done as part of your work or "linux".
Rob, any hints here?


Ok we can use as vendor "abb" in all DTS files and regarding your
change in Documentation/devicetree/bindings/vendor-prefixes.yaml
it can be:

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml

index 789a01b3d93a..bb4c85f00c8f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -105,6 +105,8 @@ patternProperties:
 description: arcx Inc. / Archronix Inc.
   "^aries,.*":
 description: Aries Embedded GmbH
+  "^abb,.*":
+description: ABB
   "^arm,.*":
 description: ARM Ltd.
   "^armadeus,.*":

Would you work in this changes?

Many thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [RFC 12/14] dt-bindings: vendor-prefixes: add Aristainetos

[Heiko Schocher]

Hello Krzysztof,

Am 28.09.2020 um 06:04 schrieb Heiko Schocher:

Hello Krzysztof,

Am 26.09.2020 um 18:28 schrieb Krzysztof Kozlowski:

Document binding for an unknown entity Aristainetos with few boards
mainlined.

Cc: Heiko Schocher 
Signed-off-by: Krzysztof Kozlowski 

---

I tried to Google but except the patches from Heiko Schocher, I could
not find any meaningful data.

Heiko, you posted this. Do you know what is it?


aristainetos is the name of the board, so it is not the vendor name.

I just asked the customer if we can add a valid vendor name...


Ok, it is not easy to get an okay from the customer to publish
his name.

Is there a dummy or unknown entry for vendor?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [RFC 12/14] dt-bindings: vendor-prefixes: add Aristainetos

[Heiko Schocher]

Hello Krzysztof,

Am 26.09.2020 um 18:28 schrieb Krzysztof Kozlowski:

Document binding for an unknown entity Aristainetos with few boards
mainlined.

Cc: Heiko Schocher 
Signed-off-by: Krzysztof Kozlowski 

---

I tried to Google but except the patches from Heiko Schocher, I could
not find any meaningful data.

Heiko, you posted this. Do you know what is it?


aristainetos is the name of the board, so it is not the vendor name.

I just asked the customer if we can add a valid vendor name...

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH 1/2] misc: add cc1101 devicetree binding

[Heiko Schocher]

Hello Rob,

Am 02.10.2019 um 16:19 schrieb Rob Herring:

On Sun, Sep 22, 2019 at 08:03:55AM +0200, Heiko Schocher wrote:

add devicetree binding for cc1101 misc driver.

Signed-off-by: Heiko Schocher 
---

  .../devicetree/bindings/misc/cc1101.txt   | 27 +++
  1 file changed, 27 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/misc/cc1101.txt


Can you please convert this to DT schema.


Of course, missed this point, sorry, reworked. Is there a HowTo
for writting a schema?
(beside Documentation/devicetree/bindings/example-schema.yaml)


diff --git a/Documentation/devicetree/bindings/misc/cc1101.txt 
b/Documentation/devicetree/bindings/misc/cc1101.txt
new file mode 100644
index 0..afea6acf4a9c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/cc1101.txt


Normal naming is to use compatible string. So ti,cc1101.yaml for schema.


renamed.




@@ -0,0 +1,27 @@
+driver cc1101 Low-Power Sub-1 GHz RF Transceiver chip from Texas
+Instruments.
+
+Requires node properties:
+- compatible : should be "ti,cc1101";
+- reg: Chip select address of device, see:
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+- gpios  : list of 2 gpios, first gpio is for GDO0 pin
+   second for GDO2 pin, see more:


Is there a GDO1? Would be hard to add later because you can't change the
indices once defined.


Good point. There is a GDO1, so yes, this makes sense, added.




+   Documentation/devicetree/bindings/gpio/gpio.txt
+
+Recommended properties:
+ - spi-max-frequency: Definition as per
+Documentation/devicetree/bindings/spi/spi-bus.txt


Notice that this file is now just in redirection...


Ok.




+ - freq   : used spi frequency for communication with cc1101 chip


What's this? Doesn't spi-max-frequency cover it?


Of course, removed.

Thanks for your time and review.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

[PATCH 1/2] misc: add cc1101 devicetree binding

[Heiko Schocher]

add devicetree binding for cc1101 misc driver.

Signed-off-by: Heiko Schocher 
---

 .../devicetree/bindings/misc/cc1101.txt   | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/cc1101.txt

diff --git a/Documentation/devicetree/bindings/misc/cc1101.txt 
b/Documentation/devicetree/bindings/misc/cc1101.txt
new file mode 100644
index 0..afea6acf4a9c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/cc1101.txt
@@ -0,0 +1,27 @@
+driver cc1101 Low-Power Sub-1 GHz RF Transceiver chip from Texas
+Instruments.
+
+Requires node properties:
+- compatible : should be "ti,cc1101";
+- reg: Chip select address of device, see:
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+- gpios  : list of 2 gpios, first gpio is for GDO0 pin
+   second for GDO2 pin, see more:
+   Documentation/devicetree/bindings/gpio/gpio.txt
+
+Recommended properties:
+ - spi-max-frequency: Definition as per
+Documentation/devicetree/bindings/spi/spi-bus.txt
+ - freq   : used spi frequency for communication with cc1101 chip
+
+example:
+
+ {
+cc1101@0 {
+compatible = "ti,cc1101";
+spi-max-frequency = <1000>;
+reg = <0>;
+freq = <500>;
+gpios = < 11 GPIO_ACTIVE_HIGH  8 GPIO_ACTIVE_HIGH>;
+};
+};
-- 
2.21.0

Re: [PATCH] tty: 8250_of: Use software emulated RS485 direction control

[Heiko Schocher]

Hello Andy,

Am 13.09.2019 um 12:24 schrieb Andy Shevchenko:

On Fri, Sep 13, 2019 at 07:01:05AM +0200, Heiko Schocher wrote:

Use software emulated RS485 direction control to provide RS485 API

Currently it is not possible to use rs485 as pointer to
rs485_config struct in struct uart_port is NULL in case we
configure the port through device tree.


Thank you for the patch, few recommendations for the future submissions.


Patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit:
505a8ec7e11a - Revert "drm/i915/userptr: Acquire the page lock around 
set_page_dirty()"


More reliably is to base on corresponding subsystem tree, i.e. tty-next for
this case.


Ok, should I send a rebased v2 (I tend to wait for other comments)?


checkpatch output:
$ ./scripts/checkpatch.pl 
0001-tty-8250_of-Use-software-emulated-RS485-direction-co.patch
total: 0 errors, 0 warnings, 43 lines checked

0001-tty-8250_of-Use-software-emulated-RS485-direction-co.patch has no obvious 
style problems and is ready for submission.


There is no need to mention this. It's supposed that submitter did that
themselves.


Hmm... ok.


When you gather people to send the patch to, I recommend to use some threshold,
e.g. `scripts/get_maintainer.pl --git --git-min-percent=67 ...`


Ah, good tip, thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

[PATCH] tty: 8250_of: Use software emulated RS485 direction control

[Heiko Schocher]

Use software emulated RS485 direction control to provide RS485 API

Currently it is not possible to use rs485 as pointer to
rs485_config struct in struct uart_port is NULL in case we
configure the port through device tree.

Signed-off-by: Heiko Schocher 

---
Patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit:
505a8ec7e11a - Revert "drm/i915/userptr: Acquire the page lock around 
set_page_dirty()"

checkpatch output:
$ ./scripts/checkpatch.pl 
0001-tty-8250_of-Use-software-emulated-RS485-direction-co.patch
total: 0 errors, 0 warnings, 43 lines checked

0001-tty-8250_of-Use-software-emulated-RS485-direction-co.patch has no obvious 
style problems and is ready for submission.

 drivers/tty/serial/8250/8250_of.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_of.c 
b/drivers/tty/serial/8250/8250_of.c
index 0826cfdbd4063..92fbf46ce3bd9 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -48,6 +48,36 @@ static inline void tegra_serial_handle_break(struct 
uart_port *port)
 }
 #endif
 
+static int of_8250_rs485_config(struct uart_port *port,
+ struct serial_rs485 *rs485)
+{
+   struct uart_8250_port *up = up_to_u8250p(port);
+
+   /* Clamp the delays to [0, 100ms] */
+   rs485->delay_rts_before_send = min(rs485->delay_rts_before_send, 100U);
+   rs485->delay_rts_after_send  = min(rs485->delay_rts_after_send, 100U);
+
+   port->rs485 = *rs485;
+
+   /*
+* Both serial8250_em485_init and serial8250_em485_destroy
+* are idempotent
+*/
+   if (rs485->flags & SER_RS485_ENABLED) {
+   int ret = serial8250_em485_init(up);
+
+   if (ret) {
+   rs485->flags &= ~SER_RS485_ENABLED;
+   port->rs485.flags &= ~SER_RS485_ENABLED;
+   }
+   return ret;
+   }
+
+   serial8250_em485_destroy(up);
+
+   return 0;
+}
+
 /*
  * Fill a struct uart_port for a given device node
  */
@@ -178,6 +208,7 @@ static int of_platform_serial_setup(struct platform_device 
*ofdev,
port->flags |= UPF_SKIP_TEST;
 
port->dev = >dev;
+   port->rs485_config = of_8250_rs485_config;
 
switch (type) {
case PORT_TEGRA:
-- 
2.21.0

[PATCH v1 0/2] ARM: dts: am335x-shc.dts: small updates for shc board

[Heiko Schocher]

small updates for am335x based shc board:
- switch DTS to SPDX identifier
- fix wrong gpio level for mmc1 cd pin


Heiko Schocher (2):
  ARM: dts: am335x-shc.dts: Switch to SPDX identifier
  ARM: dts: am335x-shc.dts: fix wrong cd pin level

 arch/arm/boot/dts/am335x-shc.dts | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

-- 
2.17.2

[PATCH v1 1/2] ARM: dts: am335x-shc.dts: Switch to SPDX identifier

[Heiko Schocher]

Adopt the SPDX license identifier headers to ease license
compliance management.

Signed-off-by: Heiko Schocher 
---

 arch/arm/boot/dts/am335x-shc.dts | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
index d0fd68873689..5cdaf0cd9401 100644
--- a/arch/arm/boot/dts/am335x-shc.dts
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -1,11 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * support for the bosch am335x based shc c3 board
  *
  * Copyright, C) 2015 Heiko Schocher 
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 /dts-v1/;
 
-- 
2.17.2

[PATCH v1 2/2] ARM: dts: am335x-shc.dts: fix wrong cd pin level

[Heiko Schocher]

cd pin on mmc1 is GPIO_ACTIVE_LOW not GPIO_ACTIVE_HIGH

Signed-off-by: Heiko Schocher 
---

 arch/arm/boot/dts/am335x-shc.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
index 5cdaf0cd9401..bfbe27a80006 100644
--- a/arch/arm/boot/dts/am335x-shc.dts
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -213,7 +213,7 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
bus-width = <0x4>;
-   cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
cd-inverted;
max-frequency = <2600>;
vmmc-supply = <_fixed>;
-- 
2.17.2

Re: [PATCH] ARM: dts: imx6ull: fix pinmux input_val for uart5 rx pin

[Heiko Schocher]

Hello Sébastien,

Am 30.08.2018 um 15:25 schrieb Sébastien Szymanski:

Hi,

On 08/30/2018 02:47 PM, Heiko Schocher wrote:

on the imx6ull the input_val for uart5 rx function
of pin MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX
is 7 and not 5 as on the imx6ul. With this
patch, console on an imx6ull based board works
with uart5.

Signed-off-by: Heiko Schocher 


This is already fixed on v4.19-rc1 and also on a few others PADs that
have similar issue.
Moreover signals common for both i.MX6UL and i.MX6ULL should have
IMX6UL_ as prefix:

https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?h=for-next=387301d5b88e2fe91de9baf4ca25f771cc633f70


My patch was based on current HEAD ...Ah, got it, this patch is in
"for-next"

Thanks! And sorry for the noise.

bye,
Heiko


Regards,



---

  arch/arm/boot/dts/imx6ull-pinfunc.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h 
b/arch/arm/boot/dts/imx6ull-pinfunc.h
index fdc46bb09cc1a..d835aeae5485b 100644
--- a/arch/arm/boot/dts/imx6ull-pinfunc.h
+++ b/arch/arm/boot/dts/imx6ull-pinfunc.h
@@ -61,5 +61,6 @@
  #define MX6ULL_PAD_CSI_DATA05__ESAI_TX_CLK0x01F8 
0x0484 0x 0x9 0x0
  #define MX6ULL_PAD_CSI_DATA06__ESAI_TX5_RX0   0x01FC 
0x0488 0x 0x9 0x0
  #define MX6ULL_PAD_CSI_DATA07__ESAI_T00x0200 
0x048C 0x 0x9 0x0
+#define MX6ULL_PAD_UART5_RX_DATA__UART5_DCE_RX 0x00C0 0x034C 0x0644 0 7
  
  #endif /* __DTS_IMX6ULL_PINFUNC_H */







--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH] ARM: dts: imx6ull: fix pinmux input_val for uart5 rx pin

[Heiko Schocher]

Hello Sébastien,

Am 30.08.2018 um 15:25 schrieb Sébastien Szymanski:

Hi,

On 08/30/2018 02:47 PM, Heiko Schocher wrote:

on the imx6ull the input_val for uart5 rx function
of pin MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX
is 7 and not 5 as on the imx6ul. With this
patch, console on an imx6ull based board works
with uart5.

Signed-off-by: Heiko Schocher 


This is already fixed on v4.19-rc1 and also on a few others PADs that
have similar issue.
Moreover signals common for both i.MX6UL and i.MX6ULL should have
IMX6UL_ as prefix:

https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?h=for-next=387301d5b88e2fe91de9baf4ca25f771cc633f70


My patch was based on current HEAD ...Ah, got it, this patch is in
"for-next"

Thanks! And sorry for the noise.

bye,
Heiko


Regards,



---

  arch/arm/boot/dts/imx6ull-pinfunc.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h 
b/arch/arm/boot/dts/imx6ull-pinfunc.h
index fdc46bb09cc1a..d835aeae5485b 100644
--- a/arch/arm/boot/dts/imx6ull-pinfunc.h
+++ b/arch/arm/boot/dts/imx6ull-pinfunc.h
@@ -61,5 +61,6 @@
  #define MX6ULL_PAD_CSI_DATA05__ESAI_TX_CLK0x01F8 
0x0484 0x 0x9 0x0
  #define MX6ULL_PAD_CSI_DATA06__ESAI_TX5_RX0   0x01FC 
0x0488 0x 0x9 0x0
  #define MX6ULL_PAD_CSI_DATA07__ESAI_T00x0200 
0x048C 0x 0x9 0x0
+#define MX6ULL_PAD_UART5_RX_DATA__UART5_DCE_RX 0x00C0 0x034C 0x0644 0 7
  
  #endif /* __DTS_IMX6ULL_PINFUNC_H */







--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

[PATCH] ARM: dts: imx6ull: fix pinmux input_val for uart5 rx pin

[Heiko Schocher]

on the imx6ull the input_val for uart5 rx function
of pin MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX
is 7 and not 5 as on the imx6ul. With this
patch, console on an imx6ull based board works
with uart5.

Signed-off-by: Heiko Schocher 

---

 arch/arm/boot/dts/imx6ull-pinfunc.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h 
b/arch/arm/boot/dts/imx6ull-pinfunc.h
index fdc46bb09cc1a..d835aeae5485b 100644
--- a/arch/arm/boot/dts/imx6ull-pinfunc.h
+++ b/arch/arm/boot/dts/imx6ull-pinfunc.h
@@ -61,5 +61,6 @@
 #define MX6ULL_PAD_CSI_DATA05__ESAI_TX_CLK0x01F8 
0x0484 0x 0x9 0x0
 #define MX6ULL_PAD_CSI_DATA06__ESAI_TX5_RX0   0x01FC 
0x0488 0x 0x9 0x0
 #define MX6ULL_PAD_CSI_DATA07__ESAI_T00x0200 
0x048C 0x 0x9 0x0
+#define MX6ULL_PAD_UART5_RX_DATA__UART5_DCE_RX 0x00C0 0x034C 0x0644 0 7
 
 #endif /* __DTS_IMX6ULL_PINFUNC_H */
-- 
2.14.4

[PATCH] ARM: dts: imx6ull: fix pinmux input_val for uart5 rx pin

[Heiko Schocher]

on the imx6ull the input_val for uart5 rx function
of pin MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX
is 7 and not 5 as on the imx6ul. With this
patch, console on an imx6ull based board works
with uart5.

Signed-off-by: Heiko Schocher 

---

 arch/arm/boot/dts/imx6ull-pinfunc.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h 
b/arch/arm/boot/dts/imx6ull-pinfunc.h
index fdc46bb09cc1a..d835aeae5485b 100644
--- a/arch/arm/boot/dts/imx6ull-pinfunc.h
+++ b/arch/arm/boot/dts/imx6ull-pinfunc.h
@@ -61,5 +61,6 @@
 #define MX6ULL_PAD_CSI_DATA05__ESAI_TX_CLK0x01F8 
0x0484 0x 0x9 0x0
 #define MX6ULL_PAD_CSI_DATA06__ESAI_TX5_RX0   0x01FC 
0x0488 0x 0x9 0x0
 #define MX6ULL_PAD_CSI_DATA07__ESAI_T00x0200 
0x048C 0x 0x9 0x0
+#define MX6ULL_PAD_UART5_RX_DATA__UART5_DCE_RX 0x00C0 0x034C 0x0644 0 7
 
 #endif /* __DTS_IMX6ULL_PINFUNC_H */
-- 
2.14.4

[PATCH v2 1/2] net, can, ifi: fix "write buffer full" error

[Heiko Schocher]

the driver reads in the ISR first the IRQpending register,
and clears after that in a write *all* bits in it.

It could happen that the isr register raise bits between
this 2 register accesses, which leads in lost bits ...

In case it clears "TX message sent successfully", the driver
never sends any Tx data, and buffers to userspace run over.

Fixed this:
clear only the bits in the IRQpending register, the
driver had read.

Signed-off-by: Heiko Schocher <h...@denx.de>
Reviewed-by: Marek Vasut <ma...@denx.de>
---

Changes in v2:
- add Reviewed-by from Marek

 drivers/net/can/ifi_canfd/ifi_canfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/ifi_canfd/ifi_canfd.c 
b/drivers/net/can/ifi_canfd/ifi_canfd.c
index 2772d05ff11c..05feb8177936 100644
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -607,7 +607,7 @@ static irqreturn_t ifi_canfd_isr(int irq, void *dev_id)
return IRQ_NONE;
 
/* Clear all pending interrupts but ErrWarn */
-   writel(clr_irq_mask, priv->base + IFI_CANFD_INTERRUPT);
+   writel(isr & clr_irq_mask, priv->base + IFI_CANFD_INTERRUPT);
 
/* RX IRQ or bus warning, start NAPI */
if (isr & rx_irq_mask) {
-- 
2.14.3

[PATCH v2 1/2] net, can, ifi: fix "write buffer full" error

[Heiko Schocher]

the driver reads in the ISR first the IRQpending register,
and clears after that in a write *all* bits in it.

It could happen that the isr register raise bits between
this 2 register accesses, which leads in lost bits ...

In case it clears "TX message sent successfully", the driver
never sends any Tx data, and buffers to userspace run over.

Fixed this:
clear only the bits in the IRQpending register, the
driver had read.

Signed-off-by: Heiko Schocher 
Reviewed-by: Marek Vasut 
---

Changes in v2:
- add Reviewed-by from Marek

 drivers/net/can/ifi_canfd/ifi_canfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/ifi_canfd/ifi_canfd.c 
b/drivers/net/can/ifi_canfd/ifi_canfd.c
index 2772d05ff11c..05feb8177936 100644
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -607,7 +607,7 @@ static irqreturn_t ifi_canfd_isr(int irq, void *dev_id)
return IRQ_NONE;
 
/* Clear all pending interrupts but ErrWarn */
-   writel(clr_irq_mask, priv->base + IFI_CANFD_INTERRUPT);
+   writel(isr & clr_irq_mask, priv->base + IFI_CANFD_INTERRUPT);
 
/* RX IRQ or bus warning, start NAPI */
if (isr & rx_irq_mask) {
-- 
2.14.3

[PATCH v2 2/2] net, can, ifi: loopback Tx message in IFI block

[Heiko Schocher]

Current ifi driver reads first Rx messages, than loopback
the Tx message, if the IFI_CANFD_INTERRUPT_TXFIFO_REMOVE
bit is set. This can lead into the case, that Rx messages
overhelm Tx messages!

Fixed this in the following way:

Set in the IFI_CANFD_TXFIFO_DLC register the FN value to
1, so the IFI block loopsback itself the Tx message when
sended correctly on the canfd bus. Only the IFI block can
insert the Tx message in the correct place.

The linux driver now needs only to free the skb, when
the Tx message was sended correctly.

Signed-off-by: Heiko Schocher <h...@denx.de>
Reviewed-by: Marek Vasut <ma...@denx.de>
---

Changes in v2:
- add Reviewed-by from Marek, fixed comment into one liner

 drivers/net/can/ifi_canfd/ifi_canfd.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/ifi_canfd/ifi_canfd.c 
b/drivers/net/can/ifi_canfd/ifi_canfd.c
index 05feb8177936..ee74ee8f9b38 100644
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -211,6 +211,7 @@ struct ifi_canfd_priv {
struct napi_struct  napi;
struct net_device   *ndev;
void __iomem*base;
+   unsigned inttx_len;
 };
 
 static void ifi_canfd_irq_enable(struct net_device *ndev, bool enable)
@@ -617,8 +618,10 @@ static irqreturn_t ifi_canfd_isr(int irq, void *dev_id)
 
/* TX IRQ */
if (isr & IFI_CANFD_INTERRUPT_TXFIFO_REMOVE) {
-   stats->tx_bytes += can_get_echo_skb(ndev, 0);
+   can_free_echo_skb(ndev, 0);
+   stats->tx_bytes += priv->tx_len;
stats->tx_packets++;
+   priv->tx_len = 0;
can_led_event(ndev, CAN_LED_EVENT_TX);
}
 
@@ -889,6 +892,7 @@ static netdev_tx_t ifi_canfd_start_xmit(struct sk_buff *skb,
}
 
txdlc = can_len2dlc(cf->len);
+   priv->tx_len = txdlc;
if ((priv->can.ctrlmode & CAN_CTRLMODE_FD) && can_is_canfd_skb(skb)) {
txdlc |= IFI_CANFD_TXFIFO_DLC_EDL;
if (cf->flags & CANFD_BRS)
@@ -898,6 +902,9 @@ static netdev_tx_t ifi_canfd_start_xmit(struct sk_buff *skb,
if (cf->can_id & CAN_RTR_FLAG)
txdlc |= IFI_CANFD_TXFIFO_DLC_RTR;
 
+   /* set FNR to 1, so we get our Tx Message looped back into RxFIFO */
+   txdlc += (1 << IFI_CANFD_TXFIFO_DLC_FNR_OFFSET);
+
/* message ram configuration */
writel(txid, priv->base + IFI_CANFD_TXFIFO_ID);
writel(txdlc, priv->base + IFI_CANFD_TXFIFO_DLC);
-- 
2.14.3

[PATCH v2 2/2] net, can, ifi: loopback Tx message in IFI block

[Heiko Schocher]

Current ifi driver reads first Rx messages, than loopback
the Tx message, if the IFI_CANFD_INTERRUPT_TXFIFO_REMOVE
bit is set. This can lead into the case, that Rx messages
overhelm Tx messages!

Fixed this in the following way:

Set in the IFI_CANFD_TXFIFO_DLC register the FN value to
1, so the IFI block loopsback itself the Tx message when
sended correctly on the canfd bus. Only the IFI block can
insert the Tx message in the correct place.

The linux driver now needs only to free the skb, when
the Tx message was sended correctly.

Signed-off-by: Heiko Schocher 
Reviewed-by: Marek Vasut 
---

Changes in v2:
- add Reviewed-by from Marek, fixed comment into one liner

 drivers/net/can/ifi_canfd/ifi_canfd.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/ifi_canfd/ifi_canfd.c 
b/drivers/net/can/ifi_canfd/ifi_canfd.c
index 05feb8177936..ee74ee8f9b38 100644
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -211,6 +211,7 @@ struct ifi_canfd_priv {
struct napi_struct  napi;
struct net_device   *ndev;
void __iomem*base;
+   unsigned inttx_len;
 };
 
 static void ifi_canfd_irq_enable(struct net_device *ndev, bool enable)
@@ -617,8 +618,10 @@ static irqreturn_t ifi_canfd_isr(int irq, void *dev_id)
 
/* TX IRQ */
if (isr & IFI_CANFD_INTERRUPT_TXFIFO_REMOVE) {
-   stats->tx_bytes += can_get_echo_skb(ndev, 0);
+   can_free_echo_skb(ndev, 0);
+   stats->tx_bytes += priv->tx_len;
stats->tx_packets++;
+   priv->tx_len = 0;
can_led_event(ndev, CAN_LED_EVENT_TX);
}
 
@@ -889,6 +892,7 @@ static netdev_tx_t ifi_canfd_start_xmit(struct sk_buff *skb,
}
 
txdlc = can_len2dlc(cf->len);
+   priv->tx_len = txdlc;
if ((priv->can.ctrlmode & CAN_CTRLMODE_FD) && can_is_canfd_skb(skb)) {
txdlc |= IFI_CANFD_TXFIFO_DLC_EDL;
if (cf->flags & CANFD_BRS)
@@ -898,6 +902,9 @@ static netdev_tx_t ifi_canfd_start_xmit(struct sk_buff *skb,
if (cf->can_id & CAN_RTR_FLAG)
txdlc |= IFI_CANFD_TXFIFO_DLC_RTR;
 
+   /* set FNR to 1, so we get our Tx Message looped back into RxFIFO */
+   txdlc += (1 << IFI_CANFD_TXFIFO_DLC_FNR_OFFSET);
+
/* message ram configuration */
writel(txid, priv->base + IFI_CANFD_TXFIFO_ID);
writel(txdlc, priv->base + IFI_CANFD_TXFIFO_DLC);
-- 
2.14.3

[PATCH 1/2] net, can, ifi: fix "write buffer full" error

[Heiko Schocher]

the driver reads in the ISR first the IRQpending register,
and clears after that in a write *all* bits in it.

It could happen that the isr register raise bits between
this 2 register accesses, which leads in lost bits ...

In case it clears "TX message sent successfully", the driver
never sends any Tx data, and buffers to userspace run over.

Fixed this:
clear only the bits in the IRQpending register, the
driver had read.

Signed-off-by: Heiko Schocher <h...@denx.de>
---

 drivers/net/can/ifi_canfd/ifi_canfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/ifi_canfd/ifi_canfd.c 
b/drivers/net/can/ifi_canfd/ifi_canfd.c
index 2772d05ff11c..05feb8177936 100644
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -607,7 +607,7 @@ static irqreturn_t ifi_canfd_isr(int irq, void *dev_id)
return IRQ_NONE;
 
/* Clear all pending interrupts but ErrWarn */
-   writel(clr_irq_mask, priv->base + IFI_CANFD_INTERRUPT);
+   writel(isr & clr_irq_mask, priv->base + IFI_CANFD_INTERRUPT);
 
/* RX IRQ or bus warning, start NAPI */
if (isr & rx_irq_mask) {
-- 
2.14.3

[PATCH 1/2] net, can, ifi: fix "write buffer full" error

[Heiko Schocher]

the driver reads in the ISR first the IRQpending register,
and clears after that in a write *all* bits in it.

It could happen that the isr register raise bits between
this 2 register accesses, which leads in lost bits ...

In case it clears "TX message sent successfully", the driver
never sends any Tx data, and buffers to userspace run over.

Fixed this:
clear only the bits in the IRQpending register, the
driver had read.

Signed-off-by: Heiko Schocher 
---

 drivers/net/can/ifi_canfd/ifi_canfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/ifi_canfd/ifi_canfd.c 
b/drivers/net/can/ifi_canfd/ifi_canfd.c
index 2772d05ff11c..05feb8177936 100644
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -607,7 +607,7 @@ static irqreturn_t ifi_canfd_isr(int irq, void *dev_id)
return IRQ_NONE;
 
/* Clear all pending interrupts but ErrWarn */
-   writel(clr_irq_mask, priv->base + IFI_CANFD_INTERRUPT);
+   writel(isr & clr_irq_mask, priv->base + IFI_CANFD_INTERRUPT);
 
/* RX IRQ or bus warning, start NAPI */
if (isr & rx_irq_mask) {
-- 
2.14.3

[PATCH 2/2] net, can, ifi: loopback Tx message in IFI block

[Heiko Schocher]

Current ifi driver reads first Rx messages, than loopback
the Tx message, if the IFI_CANFD_INTERRUPT_TXFIFO_REMOVE
bit is set. This can lead into the case, that Rx messages
overhelm Tx messages!

Fixed this in the following way:

Set in the IFI_CANFD_TXFIFO_DLC register the FN value to
1, so the IFI block loopsback itself the Tx message when
sended correctly on the canfd bus. Only the IFI block can
insert the Tx message in the correct place.

The linux driver now needs only to free the skb, when
the Tx message was sended correctly.

Signed-off-by: Heiko Schocher <h...@denx.de>
---

 drivers/net/can/ifi_canfd/ifi_canfd.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/ifi_canfd/ifi_canfd.c 
b/drivers/net/can/ifi_canfd/ifi_canfd.c
index 05feb8177936..0d36cb8659ae 100644
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -211,6 +211,7 @@ struct ifi_canfd_priv {
struct napi_struct  napi;
struct net_device   *ndev;
void __iomem*base;
+   unsigned inttx_len;
 };
 
 static void ifi_canfd_irq_enable(struct net_device *ndev, bool enable)
@@ -617,8 +618,10 @@ static irqreturn_t ifi_canfd_isr(int irq, void *dev_id)
 
/* TX IRQ */
if (isr & IFI_CANFD_INTERRUPT_TXFIFO_REMOVE) {
-   stats->tx_bytes += can_get_echo_skb(ndev, 0);
+   can_free_echo_skb(ndev, 0);
+   stats->tx_bytes += priv->tx_len;
stats->tx_packets++;
+   priv->tx_len = 0;
can_led_event(ndev, CAN_LED_EVENT_TX);
}
 
@@ -889,6 +892,7 @@ static netdev_tx_t ifi_canfd_start_xmit(struct sk_buff *skb,
}
 
txdlc = can_len2dlc(cf->len);
+   priv->tx_len = txdlc;
if ((priv->can.ctrlmode & CAN_CTRLMODE_FD) && can_is_canfd_skb(skb)) {
txdlc |= IFI_CANFD_TXFIFO_DLC_EDL;
if (cf->flags & CANFD_BRS)
@@ -898,6 +902,12 @@ static netdev_tx_t ifi_canfd_start_xmit(struct sk_buff 
*skb,
if (cf->can_id & CAN_RTR_FLAG)
txdlc |= IFI_CANFD_TXFIFO_DLC_RTR;
 
+   /*
+* set FNR to 1, so we get our Tx Message looped back
+* into RxFIFO
+*/
+   txdlc += (1 << IFI_CANFD_TXFIFO_DLC_FNR_OFFSET);
+
/* message ram configuration */
writel(txid, priv->base + IFI_CANFD_TXFIFO_ID);
writel(txdlc, priv->base + IFI_CANFD_TXFIFO_DLC);
-- 
2.14.3

[PATCH 2/2] net, can, ifi: loopback Tx message in IFI block

[Heiko Schocher]

Current ifi driver reads first Rx messages, than loopback
the Tx message, if the IFI_CANFD_INTERRUPT_TXFIFO_REMOVE
bit is set. This can lead into the case, that Rx messages
overhelm Tx messages!

Fixed this in the following way:

Set in the IFI_CANFD_TXFIFO_DLC register the FN value to
1, so the IFI block loopsback itself the Tx message when
sended correctly on the canfd bus. Only the IFI block can
insert the Tx message in the correct place.

The linux driver now needs only to free the skb, when
the Tx message was sended correctly.

Signed-off-by: Heiko Schocher 
---

 drivers/net/can/ifi_canfd/ifi_canfd.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/ifi_canfd/ifi_canfd.c 
b/drivers/net/can/ifi_canfd/ifi_canfd.c
index 05feb8177936..0d36cb8659ae 100644
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -211,6 +211,7 @@ struct ifi_canfd_priv {
struct napi_struct  napi;
struct net_device   *ndev;
void __iomem*base;
+   unsigned inttx_len;
 };
 
 static void ifi_canfd_irq_enable(struct net_device *ndev, bool enable)
@@ -617,8 +618,10 @@ static irqreturn_t ifi_canfd_isr(int irq, void *dev_id)
 
/* TX IRQ */
if (isr & IFI_CANFD_INTERRUPT_TXFIFO_REMOVE) {
-   stats->tx_bytes += can_get_echo_skb(ndev, 0);
+   can_free_echo_skb(ndev, 0);
+   stats->tx_bytes += priv->tx_len;
stats->tx_packets++;
+   priv->tx_len = 0;
can_led_event(ndev, CAN_LED_EVENT_TX);
}
 
@@ -889,6 +892,7 @@ static netdev_tx_t ifi_canfd_start_xmit(struct sk_buff *skb,
}
 
txdlc = can_len2dlc(cf->len);
+   priv->tx_len = txdlc;
if ((priv->can.ctrlmode & CAN_CTRLMODE_FD) && can_is_canfd_skb(skb)) {
txdlc |= IFI_CANFD_TXFIFO_DLC_EDL;
if (cf->flags & CANFD_BRS)
@@ -898,6 +902,12 @@ static netdev_tx_t ifi_canfd_start_xmit(struct sk_buff 
*skb,
if (cf->can_id & CAN_RTR_FLAG)
txdlc |= IFI_CANFD_TXFIFO_DLC_RTR;
 
+   /*
+* set FNR to 1, so we get our Tx Message looped back
+* into RxFIFO
+*/
+   txdlc += (1 << IFI_CANFD_TXFIFO_DLC_FNR_OFFSET);
+
/* message ram configuration */
writel(txid, priv->base + IFI_CANFD_TXFIFO_ID);
writel(txdlc, priv->base + IFI_CANFD_TXFIFO_DLC);
-- 
2.14.3

Re: [PATCH] hwmon: tmp103: use SIMPLE_DEV_PM_OPS helper macro

[Heiko Schocher]

Hello Guenter, Rahul,

Am 23.04.2017 um 17:43 schrieb Guenter Roeck:

Hi Rahul,

On 04/23/2017 07:10 AM, Rahul Bedarkar wrote:

Replace ifdefs with SIMPLE_DEV_PM_OPS helper macro.

Signed-off-by: Rahul Bedarkar <rahulbedarka...@gmail.com>


Thanks a lot for your patch.

While I in general prefer code that avoids #ifdef, I have seen patches
which do the opposite when handling PM code. It appears that it is
unsettled if __maybe_unused or #ifdef should be used in such situations.
Until that is the case, I won't accept patches changing one into another
unless they are from the driver author or Acked by the driver author.


Hmm.. I like this patch too, but have also no idea, what is preffered.

Looking into drivers/hwmon

pollux:linux hs [master] $ grep -lr __maybe_unused drivers/hwmon/
drivers/hwmon/tmp108.c
drivers/hwmon/nct6775.c
drivers/hwmon/hwmon-vid.c
drivers/hwmon/max31722.c

Ok, there are hwmon drivers, which use this version already ...

pollux:linux hs [master] $ grep -lr CONFIG_PM drivers/hwmon/
drivers/hwmon/max6639.c
drivers/hwmon/jc42.c
drivers/hwmon/fam15h_power.c
drivers/hwmon/tmp102.c
drivers/hwmon/gpio-fan.c
drivers/hwmon/pwm-fan.c
drivers/hwmon/tmp103.c
drivers/hwmon/pmbus/Makefile
drivers/hwmon/lm75.c
drivers/hwmon/nct6683.c
drivers/hwmon/adt7x10.h
drivers/hwmon/w83627hf.c
drivers/hwmon/abituguru3.c
drivers/hwmon/Makefile
drivers/hwmon/acpi_power_meter.c
drivers/hwmon/adt7x10.c
drivers/hwmon/abituguru.c
drivers/hwmon/w83627ehf.c

May this conversion should be done in a patch, which touches more
devices?

Nevertheless, I like this approach, so:

Acked-by: Heiko Schocher <h...@denx.de>

bye,
Heiko



Thanks,
Guenter


---
 drivers/hwmon/tmp103.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/hwmon/tmp103.c b/drivers/hwmon/tmp103.c
index d0bb28b..7f85b14 100644
--- a/drivers/hwmon/tmp103.c
+++ b/drivers/hwmon/tmp103.c
@@ -150,8 +150,7 @@ static int tmp103_probe(struct i2c_client *client,
 return PTR_ERR_OR_ZERO(hwmon_dev);
 }

-#ifdef CONFIG_PM
-static int tmp103_suspend(struct device *dev)
+static int __maybe_unused tmp103_suspend(struct device *dev)
 {
 struct regmap *regmap = dev_get_drvdata(dev);

@@ -159,7 +158,7 @@ static int tmp103_suspend(struct device *dev)
   TMP103_CONF_SD_MASK, 0);
 }

-static int tmp103_resume(struct device *dev)
+static int __maybe_unused tmp103_resume(struct device *dev)
 {
 struct regmap *regmap = dev_get_drvdata(dev);

@@ -167,15 +166,7 @@ static int tmp103_resume(struct device *dev)
   TMP103_CONF_SD_MASK, TMP103_CONF_SD);
 }

-static const struct dev_pm_ops tmp103_dev_pm_ops = {
-.suspend= tmp103_suspend,
-.resume= tmp103_resume,
-};
-
-#define TMP103_DEV_PM_OPS (_dev_pm_ops)
-#else
-#defineTMP103_DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
+static SIMPLE_DEV_PM_OPS(tmp103_dev_pm_ops, tmp103_suspend, tmp103_resume);

 static const struct i2c_device_id tmp103_id[] = {
 { "tmp103", 0 },
@@ -193,7 +184,7 @@ static struct i2c_driver tmp103_driver = {
 .driver = {
 .name= "tmp103",
 .of_match_table = of_match_ptr(tmp103_of_match),
-.pm= TMP103_DEV_PM_OPS,
+.pm= _dev_pm_ops,
 },
 .probe= tmp103_probe,
 .id_table= tmp103_id,





--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] hwmon: tmp103: use SIMPLE_DEV_PM_OPS helper macro

[Heiko Schocher]

Hello Guenter, Rahul,

Am 23.04.2017 um 17:43 schrieb Guenter Roeck:

Hi Rahul,

On 04/23/2017 07:10 AM, Rahul Bedarkar wrote:

Replace ifdefs with SIMPLE_DEV_PM_OPS helper macro.

Signed-off-by: Rahul Bedarkar 


Thanks a lot for your patch.

While I in general prefer code that avoids #ifdef, I have seen patches
which do the opposite when handling PM code. It appears that it is
unsettled if __maybe_unused or #ifdef should be used in such situations.
Until that is the case, I won't accept patches changing one into another
unless they are from the driver author or Acked by the driver author.


Hmm.. I like this patch too, but have also no idea, what is preffered.

Looking into drivers/hwmon

pollux:linux hs [master] $ grep -lr __maybe_unused drivers/hwmon/
drivers/hwmon/tmp108.c
drivers/hwmon/nct6775.c
drivers/hwmon/hwmon-vid.c
drivers/hwmon/max31722.c

Ok, there are hwmon drivers, which use this version already ...

pollux:linux hs [master] $ grep -lr CONFIG_PM drivers/hwmon/
drivers/hwmon/max6639.c
drivers/hwmon/jc42.c
drivers/hwmon/fam15h_power.c
drivers/hwmon/tmp102.c
drivers/hwmon/gpio-fan.c
drivers/hwmon/pwm-fan.c
drivers/hwmon/tmp103.c
drivers/hwmon/pmbus/Makefile
drivers/hwmon/lm75.c
drivers/hwmon/nct6683.c
drivers/hwmon/adt7x10.h
drivers/hwmon/w83627hf.c
drivers/hwmon/abituguru3.c
drivers/hwmon/Makefile
drivers/hwmon/acpi_power_meter.c
drivers/hwmon/adt7x10.c
drivers/hwmon/abituguru.c
drivers/hwmon/w83627ehf.c

May this conversion should be done in a patch, which touches more
devices?

Nevertheless, I like this approach, so:

Acked-by: Heiko Schocher 

bye,
Heiko



Thanks,
Guenter


---
 drivers/hwmon/tmp103.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/hwmon/tmp103.c b/drivers/hwmon/tmp103.c
index d0bb28b..7f85b14 100644
--- a/drivers/hwmon/tmp103.c
+++ b/drivers/hwmon/tmp103.c
@@ -150,8 +150,7 @@ static int tmp103_probe(struct i2c_client *client,
 return PTR_ERR_OR_ZERO(hwmon_dev);
 }

-#ifdef CONFIG_PM
-static int tmp103_suspend(struct device *dev)
+static int __maybe_unused tmp103_suspend(struct device *dev)
 {
 struct regmap *regmap = dev_get_drvdata(dev);

@@ -159,7 +158,7 @@ static int tmp103_suspend(struct device *dev)
   TMP103_CONF_SD_MASK, 0);
 }

-static int tmp103_resume(struct device *dev)
+static int __maybe_unused tmp103_resume(struct device *dev)
 {
 struct regmap *regmap = dev_get_drvdata(dev);

@@ -167,15 +166,7 @@ static int tmp103_resume(struct device *dev)
   TMP103_CONF_SD_MASK, TMP103_CONF_SD);
 }

-static const struct dev_pm_ops tmp103_dev_pm_ops = {
-.suspend= tmp103_suspend,
-.resume= tmp103_resume,
-};
-
-#define TMP103_DEV_PM_OPS (_dev_pm_ops)
-#else
-#defineTMP103_DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
+static SIMPLE_DEV_PM_OPS(tmp103_dev_pm_ops, tmp103_suspend, tmp103_resume);

 static const struct i2c_device_id tmp103_id[] = {
 { "tmp103", 0 },
@@ -193,7 +184,7 @@ static struct i2c_driver tmp103_driver = {
 .driver = {
 .name= "tmp103",
 .of_match_table = of_match_ptr(tmp103_of_match),
-.pm= TMP103_DEV_PM_OPS,
+.pm= _dev_pm_ops,
 },
 .probe= tmp103_probe,
 .id_table= tmp103_id,





--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

Hello all,

Am 21.02.2017 um 17:43 schrieb Rob Herring:

On Sun, Feb 19, 2017 at 11:19 PM, Heiko Schocher <h...@denx.de> wrote:

Hello all,

Am 13.02.2017 um 22:31 schrieb Rob Herring:


On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher <h...@denx.de> wrote:


Hello Rob,


Am 10.02.2017 um 16:51 schrieb Rob Herring:



On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:



From: Guan Ben <ben.g...@cn.bosch.com>

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
Signed-off-by: Heiko Schocher <h...@denx.de>

---

.../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
drivers/nfc/trf7970a.c | 26
--
2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
- spi-max-frequency: Maximum SPI frequency (<= 200).
- interrupt-parent: phandle of parent interrupt handler.
- interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on
the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2'
pins
on the
+  TRF7970A. EN2 is optional.




Could EN ever be optional/fixed? If so, perhaps deprecate this property
and do 2 properties, one for each pin.




The hardware I have has the EN2 pin fix connected to ground. Looking
into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
selects between Power Down and Sleep Mode ... I see no reason why
this is not possible/allowed ...

Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
property into 2 seperate properties ... but if this would be a reason
for not accepting this patch, I can do this ... How should I name
the 2 new properties?



I guess if this ever happens, then we just add "ti,enable2-gpios" and
ti,enable-gpios continues to point to EN. We don't need to deprecate
anything (or maybe just deprecate having both GPIOs on single
property).

In that case,

Acked-by: Rob Herring <r...@kernel.org>



gentle ping.

Are there any more comments to this patch? Is it acceptable as it
is?


I acked it, so yes, it is fine.


Gentle ping. Any more issues or can this patch go into mainline?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

Hello all,

Am 21.02.2017 um 17:43 schrieb Rob Herring:

On Sun, Feb 19, 2017 at 11:19 PM, Heiko Schocher  wrote:

Hello all,

Am 13.02.2017 um 22:31 schrieb Rob Herring:


On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher  wrote:


Hello Rob,


Am 10.02.2017 um 16:51 schrieb Rob Herring:



On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:



From: Guan Ben 

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
Signed-off-by: Heiko Schocher 

---

.../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
drivers/nfc/trf7970a.c | 26
--
2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
- spi-max-frequency: Maximum SPI frequency (<= 200).
- interrupt-parent: phandle of parent interrupt handler.
- interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on
the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2'
pins
on the
+  TRF7970A. EN2 is optional.




Could EN ever be optional/fixed? If so, perhaps deprecate this property
and do 2 properties, one for each pin.




The hardware I have has the EN2 pin fix connected to ground. Looking
into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
selects between Power Down and Sleep Mode ... I see no reason why
this is not possible/allowed ...

Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
property into 2 seperate properties ... but if this would be a reason
for not accepting this patch, I can do this ... How should I name
the 2 new properties?



I guess if this ever happens, then we just add "ti,enable2-gpios" and
ti,enable-gpios continues to point to EN. We don't need to deprecate
anything (or maybe just deprecate having both GPIOs on single
property).

In that case,

Acked-by: Rob Herring 



gentle ping.

Are there any more comments to this patch? Is it acceptable as it
is?


I acked it, so yes, it is fine.


Gentle ping. Any more issues or can this patch go into mainline?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[PATCH v3] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

From: Guan Ben <ben.g...@cn.bosch.com>

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher <h...@denx.de>

Acked-by: Rob Herring <r...@kernel.org>
---

Changes in v3:
- add comment from David Lechner:
  - readd the switch statement, instead using if / then
  - remove check IS_ENABLED(CONFIG_OF)
  - remove not used node variable
  - change warning string from "Failed to read beeper-hz" to
"'beeper-hz' not specified"
  - remove function pwm_beeper_init_bell_frequency() as it is
to simple.
  - checked that device_property_read_u32() does not modify the
bell_frequency, if the property "beeper_hz" is not defined.
- add comment from Rob Herring:
  - add Acked-by from Rob Herring
Rob also mentioned to remove the IS_ENABLED(CONFIG_OF) check
and node variable is unused.

Changes in v2:
- add comment from Rob Herring:
  rename property name "bell-frequency" to "beeper-hz"
- add comment from Dmitry Torokhov:
  use device_property_read_u32() instead of of_property_read_u32()
- rebased against c470abd4fde40ea6a0846a2beab642a578c0b8cd
  Linux 4.10

 Documentation/devicetree/bindings/input/pwm-beeper.txt |  3 +++
 drivers/input/misc/pwm-beeper.c| 11 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..4e4e128 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
 Required properties:
 - compatible: should be "pwm-beeper"
 - pwms: phandle to the physical PWM device
+
+optional properties:
+- beeper-hz:  bell frequency in Hz
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 5f9655d..f2fcd50 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -27,6 +27,7 @@ struct pwm_beeper {
struct pwm_device *pwm;
struct work_struct work;
unsigned long period;
+   unsigned int bell_frequency;
 };
 
 #define HZ_TO_NANOSECONDS(x) (10UL/(x))
@@ -60,7 +61,7 @@ static int pwm_beeper_event(struct input_dev *input,
 
switch (code) {
case SND_BELL:
-   value = value ? 1000 : 0;
+   value = value ? beeper->bell_frequency : 0;
break;
case SND_TONE:
break;
@@ -97,6 +98,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
 {
unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
struct pwm_beeper *beeper;
+   unsigned int bell_frequency = 1000;
int error;
 
beeper = kzalloc(sizeof(*beeper), GFP_KERNEL);
@@ -122,6 +124,13 @@ static int pwm_beeper_probe(struct platform_device *pdev)
pwm_apply_args(beeper->pwm);
 
INIT_WORK(>work, pwm_beeper_work);
+   error = device_property_read_u32(>dev, "beeper-hz",
+  _frequency);
+   if (error < 0)
+   dev_dbg(>dev, "'beeper-hz' not specified, using default: 
%u Hz\n",
+   bell_frequency);
+
+   beeper->bell_frequency = bell_frequency;
 
beeper->input = input_allocate_device();
if (!beeper->input) {
-- 
2.7.4

[PATCH v3] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

From: Guan Ben 

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher 

Acked-by: Rob Herring 
---

Changes in v3:
- add comment from David Lechner:
  - readd the switch statement, instead using if / then
  - remove check IS_ENABLED(CONFIG_OF)
  - remove not used node variable
  - change warning string from "Failed to read beeper-hz" to
"'beeper-hz' not specified"
  - remove function pwm_beeper_init_bell_frequency() as it is
to simple.
  - checked that device_property_read_u32() does not modify the
bell_frequency, if the property "beeper_hz" is not defined.
- add comment from Rob Herring:
  - add Acked-by from Rob Herring
Rob also mentioned to remove the IS_ENABLED(CONFIG_OF) check
and node variable is unused.

Changes in v2:
- add comment from Rob Herring:
  rename property name "bell-frequency" to "beeper-hz"
- add comment from Dmitry Torokhov:
  use device_property_read_u32() instead of of_property_read_u32()
- rebased against c470abd4fde40ea6a0846a2beab642a578c0b8cd
  Linux 4.10

 Documentation/devicetree/bindings/input/pwm-beeper.txt |  3 +++
 drivers/input/misc/pwm-beeper.c| 11 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..4e4e128 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
 Required properties:
 - compatible: should be "pwm-beeper"
 - pwms: phandle to the physical PWM device
+
+optional properties:
+- beeper-hz:  bell frequency in Hz
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 5f9655d..f2fcd50 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -27,6 +27,7 @@ struct pwm_beeper {
struct pwm_device *pwm;
struct work_struct work;
unsigned long period;
+   unsigned int bell_frequency;
 };
 
 #define HZ_TO_NANOSECONDS(x) (10UL/(x))
@@ -60,7 +61,7 @@ static int pwm_beeper_event(struct input_dev *input,
 
switch (code) {
case SND_BELL:
-   value = value ? 1000 : 0;
+   value = value ? beeper->bell_frequency : 0;
break;
case SND_TONE:
break;
@@ -97,6 +98,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
 {
unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
struct pwm_beeper *beeper;
+   unsigned int bell_frequency = 1000;
int error;
 
beeper = kzalloc(sizeof(*beeper), GFP_KERNEL);
@@ -122,6 +124,13 @@ static int pwm_beeper_probe(struct platform_device *pdev)
pwm_apply_args(beeper->pwm);
 
INIT_WORK(>work, pwm_beeper_work);
+   error = device_property_read_u32(>dev, "beeper-hz",
+  _frequency);
+   if (error < 0)
+   dev_dbg(>dev, "'beeper-hz' not specified, using default: 
%u Hz\n",
+   bell_frequency);
+
+   beeper->bell_frequency = bell_frequency;
 
beeper->input = input_allocate_device();
if (!beeper->input) {
-- 
2.7.4

Re: [v2] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello Dimitry,

Am 28.02.2017 um 07:20 schrieb Dmitry Torokhov:

On February 27, 2017 10:13:43 PM PST, Heiko Schocher <h...@denx.de> wrote:

Hello David,

Am 28.02.2017 um 06:30 schrieb David Lechner:

On 02/27/2017 11:19 PM, Heiko Schocher wrote:

Hello David,

Am 27.02.2017 um 19:11 schrieb David Lechner:

On 02/20/2017 02:37 AM, Heiko Schocher wrote:

From: Guan Ben <ben.g...@cn.bosch.com>

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher <h...@denx.de>
---

Changes in v2:
- add comment from Rob Herring:
   rename property name "bell-frequency" to "beeper-hz"


Is there a separate patch for the devicetree bindings

documentation?


No, it is in this patch ... In the meantime I got an
Acked-by from Rob Herring ...



What I should have said is that, in general, I think it is preferred

to have the device tree

bindings as a separate patch from the code changes.


I can split this into 2 patches ...


Don't - since Rob already asked DT change you don't need to post to device tree 
list again and I'll merge them back together since they do not make sense 
separately.


Ok, I post a v3 with the changes suggested from David and Rob soon,
without splitting.

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [v2] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello Dimitry,

Am 28.02.2017 um 07:20 schrieb Dmitry Torokhov:

On February 27, 2017 10:13:43 PM PST, Heiko Schocher  wrote:

Hello David,

Am 28.02.2017 um 06:30 schrieb David Lechner:

On 02/27/2017 11:19 PM, Heiko Schocher wrote:

Hello David,

Am 27.02.2017 um 19:11 schrieb David Lechner:

On 02/20/2017 02:37 AM, Heiko Schocher wrote:

From: Guan Ben 

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher 
---

Changes in v2:
- add comment from Rob Herring:
   rename property name "bell-frequency" to "beeper-hz"


Is there a separate patch for the devicetree bindings

documentation?


No, it is in this patch ... In the meantime I got an
Acked-by from Rob Herring ...



What I should have said is that, in general, I think it is preferred

to have the device tree

bindings as a separate patch from the code changes.


I can split this into 2 patches ...


Don't - since Rob already asked DT change you don't need to post to device tree 
list again and I'll merge them back together since they do not make sense 
separately.


Ok, I post a v3 with the changes suggested from David and Rob soon,
without splitting.

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [v2] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello David,

Am 28.02.2017 um 06:30 schrieb David Lechner:

On 02/27/2017 11:19 PM, Heiko Schocher wrote:

Hello David,

Am 27.02.2017 um 19:11 schrieb David Lechner:

On 02/20/2017 02:37 AM, Heiko Schocher wrote:

From: Guan Ben <ben.g...@cn.bosch.com>

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher <h...@denx.de>
---

Changes in v2:
- add comment from Rob Herring:
  rename property name "bell-frequency" to "beeper-hz"


Is there a separate patch for the devicetree bindings documentation?


No, it is in this patch ... In the meantime I got an
Acked-by from Rob Herring ...



What I should have said is that, in general, I think it is preferred to have 
the device tree
bindings as a separate patch from the code changes.


I can split this into 2 patches ...

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [v2] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello David,

Am 28.02.2017 um 06:30 schrieb David Lechner:

On 02/27/2017 11:19 PM, Heiko Schocher wrote:

Hello David,

Am 27.02.2017 um 19:11 schrieb David Lechner:

On 02/20/2017 02:37 AM, Heiko Schocher wrote:

From: Guan Ben 

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher 
---

Changes in v2:
- add comment from Rob Herring:
  rename property name "bell-frequency" to "beeper-hz"


Is there a separate patch for the devicetree bindings documentation?


No, it is in this patch ... In the meantime I got an
Acked-by from Rob Herring ...



What I should have said is that, in general, I think it is preferred to have 
the device tree
bindings as a separate patch from the code changes.


I can split this into 2 patches ...

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH v2] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello Rob,

Am 27.02.2017 um 20:10 schrieb Rob Herring:

On Mon, Feb 20, 2017 at 09:37:43AM +0100, Heiko Schocher wrote:

From: Guan Ben <ben.g...@cn.bosch.com>

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher <h...@denx.de>

---

Changes in v2:
- add comment from Rob Herring:
   rename property name "bell-frequency" to "beeper-hz"
- add comment from Dmitry Torokhov:
   use device_property_read_u32() instead of of_property_read_u32()
- rebased against c470abd4fde40ea6a0846a2beab642a578c0b8cd
   Linux 4.10

  .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++


Acked-by: Rob Herring <r...@kernel.org>


Thanks!


A few comments on the driver though.


  drivers/input/misc/pwm-beeper.c| 36 --
  2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..4e4e128 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
  Required properties:
  - compatible: should be "pwm-beeper"
  - pwms: phandle to the physical PWM device
+
+optional properties:
+- beeper-hz:  bell frequency in Hz
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 5f9655d..5ea6fda 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -27,6 +27,7 @@ struct pwm_beeper {
struct pwm_device *pwm;
struct work_struct work;
unsigned long period;
+   unsigned int bell_frequency;
  };

  #define HZ_TO_NANOSECONDS(x) (10UL/(x))
@@ -58,20 +59,17 @@ static int pwm_beeper_event(struct input_dev *input,
if (type != EV_SND || value < 0)
return -EINVAL;

-   switch (code) {
-   case SND_BELL:
-   value = value ? 1000 : 0;
-   break;
-   case SND_TONE:
-   break;
-   default:
+   if (code != SND_BELL && code != SND_TONE)
return -EINVAL;
-   }

if (value == 0)
beeper->period = 0;
-   else
+   else {
+   if (code == SND_BELL)
+   value = beeper->bell_frequency;
+
beeper->period = HZ_TO_NANOSECONDS(value);
+   }

schedule_work(>work);

@@ -93,6 +91,25 @@ static void pwm_beeper_close(struct input_dev *input)
pwm_beeper_stop(beeper);
  }

+static void pwm_beeper_init_bell_frequency(struct device *dev,
+  struct pwm_beeper *beeper)
+{
+   struct device_node *node;
+   unsigned int bell_frequency = 1000;
+   int err;
+
+   if (IS_ENABLED(CONFIG_OF)) {


You don't really need this. There should be an empty version of the
function.


removed, as also David mentioned this.




+   node = dev->of_node;


You don't need this line.


Yep, removed.




+   err = device_property_read_u32(dev, "beeper-hz",
+  _frequency);
+   if (err < 0)
+   dev_dbg(dev, "Failed to read beeper-hz, using default: %u 
Hz\n",
+   bell_frequency);
+   }
+
+   beeper->bell_frequency = bell_frequency;
+}
+
  static int pwm_beeper_probe(struct platform_device *pdev)
  {
unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
@@ -122,6 +139,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
pwm_apply_args(beeper->pwm);

INIT_WORK(>work, pwm_beeper_work);
+   pwm_beeper_init_bell_frequency(>dev, beeper);

beeper->input = input_allocate_device();
if (!beeper->input) {
--
2.7.4





Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH v2] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello Rob,

Am 27.02.2017 um 20:10 schrieb Rob Herring:

On Mon, Feb 20, 2017 at 09:37:43AM +0100, Heiko Schocher wrote:

From: Guan Ben 

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher 

---

Changes in v2:
- add comment from Rob Herring:
   rename property name "bell-frequency" to "beeper-hz"
- add comment from Dmitry Torokhov:
   use device_property_read_u32() instead of of_property_read_u32()
- rebased against c470abd4fde40ea6a0846a2beab642a578c0b8cd
   Linux 4.10

  .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++


Acked-by: Rob Herring 


Thanks!


A few comments on the driver though.


  drivers/input/misc/pwm-beeper.c| 36 --
  2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..4e4e128 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
  Required properties:
  - compatible: should be "pwm-beeper"
  - pwms: phandle to the physical PWM device
+
+optional properties:
+- beeper-hz:  bell frequency in Hz
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 5f9655d..5ea6fda 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -27,6 +27,7 @@ struct pwm_beeper {
struct pwm_device *pwm;
struct work_struct work;
unsigned long period;
+   unsigned int bell_frequency;
  };

  #define HZ_TO_NANOSECONDS(x) (10UL/(x))
@@ -58,20 +59,17 @@ static int pwm_beeper_event(struct input_dev *input,
if (type != EV_SND || value < 0)
return -EINVAL;

-   switch (code) {
-   case SND_BELL:
-   value = value ? 1000 : 0;
-   break;
-   case SND_TONE:
-   break;
-   default:
+   if (code != SND_BELL && code != SND_TONE)
return -EINVAL;
-   }

if (value == 0)
beeper->period = 0;
-   else
+   else {
+   if (code == SND_BELL)
+   value = beeper->bell_frequency;
+
beeper->period = HZ_TO_NANOSECONDS(value);
+   }

schedule_work(>work);

@@ -93,6 +91,25 @@ static void pwm_beeper_close(struct input_dev *input)
pwm_beeper_stop(beeper);
  }

+static void pwm_beeper_init_bell_frequency(struct device *dev,
+  struct pwm_beeper *beeper)
+{
+   struct device_node *node;
+   unsigned int bell_frequency = 1000;
+   int err;
+
+   if (IS_ENABLED(CONFIG_OF)) {


You don't really need this. There should be an empty version of the
function.


removed, as also David mentioned this.




+   node = dev->of_node;


You don't need this line.


Yep, removed.




+   err = device_property_read_u32(dev, "beeper-hz",
+  _frequency);
+   if (err < 0)
+   dev_dbg(dev, "Failed to read beeper-hz, using default: %u 
Hz\n",
+   bell_frequency);
+   }
+
+   beeper->bell_frequency = bell_frequency;
+}
+
  static int pwm_beeper_probe(struct platform_device *pdev)
  {
unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
@@ -122,6 +139,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
pwm_apply_args(beeper->pwm);

INIT_WORK(>work, pwm_beeper_work);
+   pwm_beeper_init_bell_frequency(>dev, beeper);

beeper->input = input_allocate_device();
if (!beeper->input) {
--
2.7.4





Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [v2] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello David,

Am 27.02.2017 um 19:11 schrieb David Lechner:

On 02/20/2017 02:37 AM, Heiko Schocher wrote:

From: Guan Ben <ben.g...@cn.bosch.com>

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher <h...@denx.de>
---

Changes in v2:
- add comment from Rob Herring:
  rename property name "bell-frequency" to "beeper-hz"


Is there a separate patch for the devicetree bindings documentation?


No, it is in this patch ... In the meantime I got an
Acked-by from Rob Herring ...


- add comment from Dmitry Torokhov:
  use device_property_read_u32() instead of of_property_read_u32()
- rebased against c470abd4fde40ea6a0846a2beab642a578c0b8cd
  Linux 4.10

 .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++
 drivers/input/misc/pwm-beeper.c| 36 --
 2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..4e4e128 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
 Required properties:
 - compatible: should be "pwm-beeper"
 - pwms: phandle to the physical PWM device
+
+optional properties:
+- beeper-hz:  bell frequency in Hz
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 5f9655d..5ea6fda 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -27,6 +27,7 @@ struct pwm_beeper {
 struct pwm_device *pwm;
 struct work_struct work;
 unsigned long period;
+unsigned int bell_frequency;
 };

 #define HZ_TO_NANOSECONDS(x) (10UL/(x))
@@ -58,20 +59,17 @@ static int pwm_beeper_event(struct input_dev *input,
 if (type != EV_SND || value < 0)
 return -EINVAL;

-switch (code) {
-case SND_BELL:
-value = value ? 1000 : 0;


This would be much simpler if you just changed the single line above:

 value = value ? beeper->bell_frequency : 0;


Ok, I readded the switch statement, and changed this line.


-break;
-case SND_TONE:
-break;
-default:
+if (code != SND_BELL && code != SND_TONE)
 return -EINVAL;
-}

 if (value == 0)
 beeper->period = 0;
-else
+else {
+if (code == SND_BELL)
+value = beeper->bell_frequency;
+
 beeper->period = HZ_TO_NANOSECONDS(value);
+}

 schedule_work(>work);

@@ -93,6 +91,25 @@ static void pwm_beeper_close(struct input_dev *input)
 pwm_beeper_stop(beeper);
 }

+static void pwm_beeper_init_bell_frequency(struct device *dev,
+   struct pwm_beeper *beeper)
+{
+struct device_node *node;
+unsigned int bell_frequency = 1000;
+int err;
+
+if (IS_ENABLED(CONFIG_OF)) {


I don't think the check for CONFIG_OF is needed when using 
device_property_read_u32().


Yes, removed.




+node = dev->of_node;


node variable is never used


Removed.




+err = device_property_read_u32(dev, "beeper-hz",
+   _frequency);


Does the device_property_read_u32() function guarantee that bell_frequency is 
not modified when err
< 0 ?


Yes. This function "ends" in of_property_read_variable_u32_array()
which first searches the property (If not found returns) and if all
checks are fine, fills the "*out_values" with the values from the
property...


+if (err < 0)
+dev_dbg(dev, "Failed to read beeper-hz, using default: %u Hz\n",


"Failed" sounds like an error, but this is a perfectly normal thing to happen. 
Maybe better to say
"'beeper-hz' not specified, using default: %u Hz\n".


Changed.




+bell_frequency);
+}
+
+beeper->bell_frequency = bell_frequency;
+}
+
 static int pwm_beeper_probe(struct platform_device *pdev)
 {
 unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
@@ -122,6 +139,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
 pwm_apply_args(beeper->pwm);

 INIT_WORK(>work, pwm_beeper_work);
+pwm_beeper_init_bell_frequency(>dev, beeper);


This function is so simple, it could just be done inline here.


Indeed ... changed.

Thanks!

bye,
Heiko




 beeper->input = input_allocate_device();
 if (!beeper->input) {





--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [v2] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello David,

Am 27.02.2017 um 19:11 schrieb David Lechner:

On 02/20/2017 02:37 AM, Heiko Schocher wrote:

From: Guan Ben 

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher 
---

Changes in v2:
- add comment from Rob Herring:
  rename property name "bell-frequency" to "beeper-hz"


Is there a separate patch for the devicetree bindings documentation?


No, it is in this patch ... In the meantime I got an
Acked-by from Rob Herring ...


- add comment from Dmitry Torokhov:
  use device_property_read_u32() instead of of_property_read_u32()
- rebased against c470abd4fde40ea6a0846a2beab642a578c0b8cd
  Linux 4.10

 .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++
 drivers/input/misc/pwm-beeper.c| 36 --
 2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..4e4e128 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
 Required properties:
 - compatible: should be "pwm-beeper"
 - pwms: phandle to the physical PWM device
+
+optional properties:
+- beeper-hz:  bell frequency in Hz
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 5f9655d..5ea6fda 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -27,6 +27,7 @@ struct pwm_beeper {
 struct pwm_device *pwm;
 struct work_struct work;
 unsigned long period;
+unsigned int bell_frequency;
 };

 #define HZ_TO_NANOSECONDS(x) (10UL/(x))
@@ -58,20 +59,17 @@ static int pwm_beeper_event(struct input_dev *input,
 if (type != EV_SND || value < 0)
 return -EINVAL;

-switch (code) {
-case SND_BELL:
-value = value ? 1000 : 0;


This would be much simpler if you just changed the single line above:

 value = value ? beeper->bell_frequency : 0;


Ok, I readded the switch statement, and changed this line.


-break;
-case SND_TONE:
-break;
-default:
+if (code != SND_BELL && code != SND_TONE)
 return -EINVAL;
-}

 if (value == 0)
 beeper->period = 0;
-else
+else {
+if (code == SND_BELL)
+value = beeper->bell_frequency;
+
 beeper->period = HZ_TO_NANOSECONDS(value);
+}

 schedule_work(>work);

@@ -93,6 +91,25 @@ static void pwm_beeper_close(struct input_dev *input)
 pwm_beeper_stop(beeper);
 }

+static void pwm_beeper_init_bell_frequency(struct device *dev,
+   struct pwm_beeper *beeper)
+{
+struct device_node *node;
+unsigned int bell_frequency = 1000;
+int err;
+
+if (IS_ENABLED(CONFIG_OF)) {


I don't think the check for CONFIG_OF is needed when using 
device_property_read_u32().


Yes, removed.




+node = dev->of_node;


node variable is never used


Removed.




+err = device_property_read_u32(dev, "beeper-hz",
+   _frequency);


Does the device_property_read_u32() function guarantee that bell_frequency is 
not modified when err
< 0 ?


Yes. This function "ends" in of_property_read_variable_u32_array()
which first searches the property (If not found returns) and if all
checks are fine, fills the "*out_values" with the values from the
property...


+if (err < 0)
+dev_dbg(dev, "Failed to read beeper-hz, using default: %u Hz\n",


"Failed" sounds like an error, but this is a perfectly normal thing to happen. 
Maybe better to say
"'beeper-hz' not specified, using default: %u Hz\n".


Changed.




+bell_frequency);
+}
+
+beeper->bell_frequency = bell_frequency;
+}
+
 static int pwm_beeper_probe(struct platform_device *pdev)
 {
 unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
@@ -122,6 +139,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
 pwm_apply_args(beeper->pwm);

 INIT_WORK(>work, pwm_beeper_work);
+pwm_beeper_init_bell_frequency(>dev, beeper);


This function is so simple, it could just be done inline here.


Indeed ... changed.

Thanks!

bye,
Heiko




 beeper->input = input_allocate_device();
 if (!beeper->input) {





--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[PATCH v2] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

From: Guan Ben <ben.g...@cn.bosch.com>

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher <h...@denx.de>

---

Changes in v2:
- add comment from Rob Herring:
  rename property name "bell-frequency" to "beeper-hz"
- add comment from Dmitry Torokhov:
  use device_property_read_u32() instead of of_property_read_u32()
- rebased against c470abd4fde40ea6a0846a2beab642a578c0b8cd
  Linux 4.10

 .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++
 drivers/input/misc/pwm-beeper.c| 36 --
 2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..4e4e128 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
 Required properties:
 - compatible: should be "pwm-beeper"
 - pwms: phandle to the physical PWM device
+
+optional properties:
+- beeper-hz:  bell frequency in Hz
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 5f9655d..5ea6fda 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -27,6 +27,7 @@ struct pwm_beeper {
struct pwm_device *pwm;
struct work_struct work;
unsigned long period;
+   unsigned int bell_frequency;
 };
 
 #define HZ_TO_NANOSECONDS(x) (10UL/(x))
@@ -58,20 +59,17 @@ static int pwm_beeper_event(struct input_dev *input,
if (type != EV_SND || value < 0)
return -EINVAL;
 
-   switch (code) {
-   case SND_BELL:
-   value = value ? 1000 : 0;
-   break;
-   case SND_TONE:
-   break;
-   default:
+   if (code != SND_BELL && code != SND_TONE)
return -EINVAL;
-   }
 
if (value == 0)
beeper->period = 0;
-   else
+   else {
+   if (code == SND_BELL)
+   value = beeper->bell_frequency;
+
beeper->period = HZ_TO_NANOSECONDS(value);
+   }
 
schedule_work(>work);
 
@@ -93,6 +91,25 @@ static void pwm_beeper_close(struct input_dev *input)
pwm_beeper_stop(beeper);
 }
 
+static void pwm_beeper_init_bell_frequency(struct device *dev,
+  struct pwm_beeper *beeper)
+{
+   struct device_node *node;
+   unsigned int bell_frequency = 1000;
+   int err;
+
+   if (IS_ENABLED(CONFIG_OF)) {
+   node = dev->of_node;
+   err = device_property_read_u32(dev, "beeper-hz",
+  _frequency);
+   if (err < 0)
+   dev_dbg(dev, "Failed to read beeper-hz, using default: 
%u Hz\n",
+   bell_frequency);
+   }
+
+   beeper->bell_frequency = bell_frequency;
+}
+
 static int pwm_beeper_probe(struct platform_device *pdev)
 {
unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
@@ -122,6 +139,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
pwm_apply_args(beeper->pwm);
 
INIT_WORK(>work, pwm_beeper_work);
+   pwm_beeper_init_bell_frequency(>dev, beeper);
 
beeper->input = input_allocate_device();
if (!beeper->input) {
-- 
2.7.4

[PATCH v2] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

From: Guan Ben 

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher 

---

Changes in v2:
- add comment from Rob Herring:
  rename property name "bell-frequency" to "beeper-hz"
- add comment from Dmitry Torokhov:
  use device_property_read_u32() instead of of_property_read_u32()
- rebased against c470abd4fde40ea6a0846a2beab642a578c0b8cd
  Linux 4.10

 .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++
 drivers/input/misc/pwm-beeper.c| 36 --
 2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..4e4e128 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
 Required properties:
 - compatible: should be "pwm-beeper"
 - pwms: phandle to the physical PWM device
+
+optional properties:
+- beeper-hz:  bell frequency in Hz
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 5f9655d..5ea6fda 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -27,6 +27,7 @@ struct pwm_beeper {
struct pwm_device *pwm;
struct work_struct work;
unsigned long period;
+   unsigned int bell_frequency;
 };
 
 #define HZ_TO_NANOSECONDS(x) (10UL/(x))
@@ -58,20 +59,17 @@ static int pwm_beeper_event(struct input_dev *input,
if (type != EV_SND || value < 0)
return -EINVAL;
 
-   switch (code) {
-   case SND_BELL:
-   value = value ? 1000 : 0;
-   break;
-   case SND_TONE:
-   break;
-   default:
+   if (code != SND_BELL && code != SND_TONE)
return -EINVAL;
-   }
 
if (value == 0)
beeper->period = 0;
-   else
+   else {
+   if (code == SND_BELL)
+   value = beeper->bell_frequency;
+
beeper->period = HZ_TO_NANOSECONDS(value);
+   }
 
schedule_work(>work);
 
@@ -93,6 +91,25 @@ static void pwm_beeper_close(struct input_dev *input)
pwm_beeper_stop(beeper);
 }
 
+static void pwm_beeper_init_bell_frequency(struct device *dev,
+  struct pwm_beeper *beeper)
+{
+   struct device_node *node;
+   unsigned int bell_frequency = 1000;
+   int err;
+
+   if (IS_ENABLED(CONFIG_OF)) {
+   node = dev->of_node;
+   err = device_property_read_u32(dev, "beeper-hz",
+  _frequency);
+   if (err < 0)
+   dev_dbg(dev, "Failed to read beeper-hz, using default: 
%u Hz\n",
+   bell_frequency);
+   }
+
+   beeper->bell_frequency = bell_frequency;
+}
+
 static int pwm_beeper_probe(struct platform_device *pdev)
 {
unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
@@ -122,6 +139,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
pwm_apply_args(beeper->pwm);
 
INIT_WORK(>work, pwm_beeper_work);
+   pwm_beeper_init_bell_frequency(>dev, beeper);
 
beeper->input = input_allocate_device();
if (!beeper->input) {
-- 
2.7.4

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

Hello all,

Am 13.02.2017 um 22:31 schrieb Rob Herring:

On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher <h...@denx.de> wrote:

Hello Rob,


Am 10.02.2017 um 16:51 schrieb Rob Herring:


On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:


From: Guan Ben <ben.g...@cn.bosch.com>

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
Signed-off-by: Heiko Schocher <h...@denx.de>

---

   .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
   drivers/nfc/trf7970a.c | 26
--
   2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
   - spi-max-frequency: Maximum SPI frequency (<= 200).
   - interrupt-parent: phandle of parent interrupt handler.
   - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins
on the
+  TRF7970A. EN2 is optional.



Could EN ever be optional/fixed? If so, perhaps deprecate this property
and do 2 properties, one for each pin.



The hardware I have has the EN2 pin fix connected to ground. Looking
into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
selects between Power Down and Sleep Mode ... I see no reason why
this is not possible/allowed ...

Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
property into 2 seperate properties ... but if this would be a reason
for not accepting this patch, I can do this ... How should I name
the 2 new properties?


I guess if this ever happens, then we just add "ti,enable2-gpios" and
ti,enable-gpios continues to point to EN. We don't need to deprecate
anything (or maybe just deprecate having both GPIOs on single
property).

In that case,

Acked-by: Rob Herring <r...@kernel.org>


gentle ping.

Are there any more comments to this patch? Is it acceptable as it
is?

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

Hello all,

Am 13.02.2017 um 22:31 schrieb Rob Herring:

On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher  wrote:

Hello Rob,


Am 10.02.2017 um 16:51 schrieb Rob Herring:


On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:


From: Guan Ben 

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
Signed-off-by: Heiko Schocher 

---

   .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
   drivers/nfc/trf7970a.c | 26
--
   2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
   - spi-max-frequency: Maximum SPI frequency (<= 200).
   - interrupt-parent: phandle of parent interrupt handler.
   - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins
on the
+  TRF7970A. EN2 is optional.



Could EN ever be optional/fixed? If so, perhaps deprecate this property
and do 2 properties, one for each pin.



The hardware I have has the EN2 pin fix connected to ground. Looking
into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
selects between Power Down and Sleep Mode ... I see no reason why
this is not possible/allowed ...

Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
property into 2 seperate properties ... but if this would be a reason
for not accepting this patch, I can do this ... How should I name
the 2 new properties?


I guess if this ever happens, then we just add "ti,enable2-gpios" and
ti,enable-gpios continues to point to EN. We don't need to deprecate
anything (or maybe just deprecate having both GPIOs on single
property).

In that case,

Acked-by: Rob Herring 


gentle ping.

Are there any more comments to this patch? Is it acceptable as it
is?

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello Dmitry,

Am 14.02.2017 um 05:27 schrieb Dmitry Torokhov:

On Wed, Feb 08, 2017 at 10:11:21AM +, Jonas Mark (ST-FIR/ENG1) wrote:

Hello Dmitry,


extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.


No, SND_BELL is literally SND_TONE @1000Hz. There should be no
customizing. If applications want to use different frequency then should
be using SND_TONE.


We are not aiming for an application shortcut here. Instead, changing
the bell frequency shall be a system setting. That is, every
application which wants to make a bell sound shall use the alternative
frequency.

The reason why we are deviating from the default 1000 Hz is that on
our hardware we are using a loudspeaker which is rated for 2.7 kHz.
That is, it will only sound at the specified volume and frequency if
you feed it with a 2.7 kHz square wave. If you deviate from it, e.g.
by using 1000 Hz, the output will be dim and squeaky. Worst case,
SND_BELL would be completely silent on our system. So the only bell
sound we can reliably generate on our system has 2.7 kHz.


OK, fair enough. Please address Rob's comments on binding and resend.


Done already, just waited for more comments before sending v2.


Also I am not sure why you needed to change the switch statement around,
you only need to replace 1000 with value from the attribute.


Hmm.. the resulting code looks cleaner to me ... First we check all
the reasons for returning an error code, after that, we can do
the functions work ... but I can revert this part ... should I ?


Oh, and please use device_property_*() API instead of of_*().


Thanks! Good tip, changed.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello Dmitry,

Am 14.02.2017 um 05:27 schrieb Dmitry Torokhov:

On Wed, Feb 08, 2017 at 10:11:21AM +, Jonas Mark (ST-FIR/ENG1) wrote:

Hello Dmitry,


extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.


No, SND_BELL is literally SND_TONE @1000Hz. There should be no
customizing. If applications want to use different frequency then should
be using SND_TONE.


We are not aiming for an application shortcut here. Instead, changing
the bell frequency shall be a system setting. That is, every
application which wants to make a bell sound shall use the alternative
frequency.

The reason why we are deviating from the default 1000 Hz is that on
our hardware we are using a loudspeaker which is rated for 2.7 kHz.
That is, it will only sound at the specified volume and frequency if
you feed it with a 2.7 kHz square wave. If you deviate from it, e.g.
by using 1000 Hz, the output will be dim and squeaky. Worst case,
SND_BELL would be completely silent on our system. So the only bell
sound we can reliably generate on our system has 2.7 kHz.


OK, fair enough. Please address Rob's comments on binding and resend.


Done already, just waited for more comments before sending v2.


Also I am not sure why you needed to change the switch statement around,
you only need to replace 1000 with value from the attribute.


Hmm.. the resulting code looks cleaner to me ... First we check all
the reasons for returning an error code, after that, we can do
the functions work ... but I can revert this part ... should I ?


Oh, and please use device_property_*() API instead of of_*().


Thanks! Good tip, changed.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

Hello Rob,

Am 10.02.2017 um 16:51 schrieb Rob Herring:

On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:

From: Guan Ben <ben.g...@cn.bosch.com>

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
Signed-off-by: Heiko Schocher <h...@denx.de>

---

  .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
  drivers/nfc/trf7970a.c | 26 --
  2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt 
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
  - spi-max-frequency: Maximum SPI frequency (<= 200).
  - interrupt-parent: phandle of parent interrupt handler.
  - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
+  TRF7970A. EN2 is optional.


Could EN ever be optional/fixed? If so, perhaps deprecate this property
and do 2 properties, one for each pin.


The hardware I have has the EN2 pin fix connected to ground. Looking
into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
selects between Power Down and Sleep Mode ... I see no reason why
this is not possible/allowed ...

Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
property into 2 seperate properties ... but if this would be a reason
for not accepting this patch, I can do this ... How should I name
the 2 new properties?

"ti,pin-enable"  and "ti,pin-enable2" ?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

Hello Rob,

Am 10.02.2017 um 16:51 schrieb Rob Herring:

On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:

From: Guan Ben 

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
Signed-off-by: Heiko Schocher 

---

  .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
  drivers/nfc/trf7970a.c | 26 --
  2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt 
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
  - spi-max-frequency: Maximum SPI frequency (<= 200).
  - interrupt-parent: phandle of parent interrupt handler.
  - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
+  TRF7970A. EN2 is optional.


Could EN ever be optional/fixed? If so, perhaps deprecate this property
and do 2 properties, one for each pin.


The hardware I have has the EN2 pin fix connected to ground. Looking
into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
selects between Power Down and Sleep Mode ... I see no reason why
this is not possible/allowed ...

Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
property into 2 seperate properties ... but if this would be a reason
for not accepting this patch, I can do this ... How should I name
the 2 new properties?

"ti,pin-enable"  and "ti,pin-enable2" ?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello Rob,

Am 10.02.2017 um 16:48 schrieb Rob Herring:

On Tue, Feb 07, 2017 at 06:21:34AM +0100, Heiko Schocher wrote:

From: Guan Ben <ben.g...@cn.bosch.com>

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher <h...@denx.de>

---

  .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++
  drivers/input/misc/pwm-beeper.c| 36 --
  2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..438c6e0 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
  Required properties:
  - compatible: should be "pwm-beeper"
  - pwms: phandle to the physical PWM device
+
+optional properties:
+- bell-frequency:  bell frequency in Hz


Needs a unit suffix:
bell-frequency-hz or just bell-hz as hz implies frequency.

Or maybe beeper-hz would be more consistant.


Ok, I change it to "beeper-hz". Are this all issues with this patch?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello Rob,

Am 10.02.2017 um 16:48 schrieb Rob Herring:

On Tue, Feb 07, 2017 at 06:21:34AM +0100, Heiko Schocher wrote:

From: Guan Ben 

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher 

---

  .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++
  drivers/input/misc/pwm-beeper.c| 36 --
  2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..438c6e0 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
  Required properties:
  - compatible: should be "pwm-beeper"
  - pwms: phandle to the physical PWM device
+
+optional properties:
+- bell-frequency:  bell frequency in Hz


Needs a unit suffix:
bell-frequency-hz or just bell-hz as hz implies frequency.

Or maybe beeper-hz would be more consistant.


Ok, I change it to "beeper-hz". Are this all issues with this patch?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

From: Guan Ben <ben.g...@cn.bosch.com>

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
Signed-off-by: Heiko Schocher <h...@denx.de>

---

 .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
 drivers/nfc/trf7970a.c | 26 --
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt 
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
 - spi-max-frequency: Maximum SPI frequency (<= 200).
 - interrupt-parent: phandle of parent interrupt handler.
 - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
+  TRF7970A. EN2 is optional.
 - vin-supply: Regulator for supply voltage to VIN pin
 
 Optional SoC Specific Properties:
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 26c9dbb..75079fb 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -1885,8 +1885,10 @@ static int trf7970a_power_up(struct trf7970a *trf)
usleep_range(5000, 6000);
 
if (!(trf->quirks & TRF7970A_QUIRK_EN2_MUST_STAY_LOW)) {
-   gpio_set_value(trf->en2_gpio, 1);
-   usleep_range(1000, 2000);
+   if (gpio_is_valid(trf->en2_gpio)) {
+   gpio_set_value(trf->en2_gpio, 1);
+   usleep_range(1000, 2000);
+   }
}
 
gpio_set_value(trf->en_gpio, 1);
@@ -1914,7 +1916,8 @@ static int trf7970a_power_down(struct trf7970a *trf)
}
 
gpio_set_value(trf->en_gpio, 0);
-   gpio_set_value(trf->en2_gpio, 0);
+   if (gpio_is_valid(trf->en2_gpio))
+   gpio_set_value(trf->en2_gpio, 0);
 
ret = regulator_disable(trf->regulator);
if (ret)
@@ -2032,15 +2035,14 @@ static int trf7970a_probe(struct spi_device *spi)
 
trf->en2_gpio = of_get_named_gpio(np, "ti,enable-gpios", 1);
if (!gpio_is_valid(trf->en2_gpio)) {
-   dev_err(trf->dev, "No EN2 GPIO property\n");
-   return trf->en2_gpio;
-   }
-
-   ret = devm_gpio_request_one(trf->dev, trf->en2_gpio,
-   GPIOF_DIR_OUT | GPIOF_INIT_LOW, "trf7970a EN2");
-   if (ret) {
-   dev_err(trf->dev, "Can't request EN2 GPIO: %d\n", ret);
-   return ret;
+   dev_info(trf->dev, "No EN2 GPIO property\n");
+   } else {
+   ret = devm_gpio_request_one(trf->dev, trf->en2_gpio,
+   GPIOF_DIR_OUT | GPIOF_INIT_LOW, "trf7970a EN2");
+   if (ret) {
+   dev_err(trf->dev, "Can't request EN2 GPIO: %d\n", ret);
+   return ret;
+   }
}
 
if (of_property_read_bool(np, "en2-rf-quirk"))
-- 
2.7.4

[PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

From: Guan Ben 

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
Signed-off-by: Heiko Schocher 

---

 .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
 drivers/nfc/trf7970a.c | 26 --
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt 
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
 - spi-max-frequency: Maximum SPI frequency (<= 200).
 - interrupt-parent: phandle of parent interrupt handler.
 - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
+  TRF7970A. EN2 is optional.
 - vin-supply: Regulator for supply voltage to VIN pin
 
 Optional SoC Specific Properties:
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 26c9dbb..75079fb 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -1885,8 +1885,10 @@ static int trf7970a_power_up(struct trf7970a *trf)
usleep_range(5000, 6000);
 
if (!(trf->quirks & TRF7970A_QUIRK_EN2_MUST_STAY_LOW)) {
-   gpio_set_value(trf->en2_gpio, 1);
-   usleep_range(1000, 2000);
+   if (gpio_is_valid(trf->en2_gpio)) {
+   gpio_set_value(trf->en2_gpio, 1);
+   usleep_range(1000, 2000);
+   }
}
 
gpio_set_value(trf->en_gpio, 1);
@@ -1914,7 +1916,8 @@ static int trf7970a_power_down(struct trf7970a *trf)
}
 
gpio_set_value(trf->en_gpio, 0);
-   gpio_set_value(trf->en2_gpio, 0);
+   if (gpio_is_valid(trf->en2_gpio))
+   gpio_set_value(trf->en2_gpio, 0);
 
ret = regulator_disable(trf->regulator);
if (ret)
@@ -2032,15 +2035,14 @@ static int trf7970a_probe(struct spi_device *spi)
 
trf->en2_gpio = of_get_named_gpio(np, "ti,enable-gpios", 1);
if (!gpio_is_valid(trf->en2_gpio)) {
-   dev_err(trf->dev, "No EN2 GPIO property\n");
-   return trf->en2_gpio;
-   }
-
-   ret = devm_gpio_request_one(trf->dev, trf->en2_gpio,
-   GPIOF_DIR_OUT | GPIOF_INIT_LOW, "trf7970a EN2");
-   if (ret) {
-   dev_err(trf->dev, "Can't request EN2 GPIO: %d\n", ret);
-   return ret;
+   dev_info(trf->dev, "No EN2 GPIO property\n");
+   } else {
+   ret = devm_gpio_request_one(trf->dev, trf->en2_gpio,
+   GPIOF_DIR_OUT | GPIOF_INIT_LOW, "trf7970a EN2");
+   if (ret) {
+   dev_err(trf->dev, "Can't request EN2 GPIO: %d\n", ret);
+   return ret;
+   }
}
 
if (of_property_read_bool(np, "en2-rf-quirk"))
-- 
2.7.4

[PATCH] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

From: Guan Ben <ben.g...@cn.bosch.com>

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben <ben.g...@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jo...@de.bosch.com>
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher <h...@denx.de>

---

 .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++
 drivers/input/misc/pwm-beeper.c| 36 --
 2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..438c6e0 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
 Required properties:
 - compatible: should be "pwm-beeper"
 - pwms: phandle to the physical PWM device
+
+optional properties:
+- bell-frequency:  bell frequency in Hz
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 5f9655d..99591d5 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -27,6 +27,7 @@ struct pwm_beeper {
struct pwm_device *pwm;
struct work_struct work;
unsigned long period;
+   unsigned int bell_frequency;
 };
 
 #define HZ_TO_NANOSECONDS(x) (10UL/(x))
@@ -58,20 +59,17 @@ static int pwm_beeper_event(struct input_dev *input,
if (type != EV_SND || value < 0)
return -EINVAL;
 
-   switch (code) {
-   case SND_BELL:
-   value = value ? 1000 : 0;
-   break;
-   case SND_TONE:
-   break;
-   default:
+   if (code != SND_BELL && code != SND_TONE)
return -EINVAL;
-   }
 
if (value == 0)
beeper->period = 0;
-   else
+   else {
+   if (code == SND_BELL)
+   value = beeper->bell_frequency;
+
beeper->period = HZ_TO_NANOSECONDS(value);
+   }
 
schedule_work(>work);
 
@@ -93,6 +91,25 @@ static void pwm_beeper_close(struct input_dev *input)
pwm_beeper_stop(beeper);
 }
 
+static void pwm_beeper_init_bell_frequency(struct device *dev,
+  struct pwm_beeper *beeper)
+{
+   struct device_node *node;
+   unsigned int bell_frequency = 1000;
+   int error;
+
+   if (IS_ENABLED(CONFIG_OF)) {
+   node = dev->of_node;
+   error = of_property_read_u32(node, "bell-frequency",
+_frequency);
+   if (error < 0)
+   dev_dbg(dev, "Failed to read bell-frequency, using 
default: %u Hz\n",
+   bell_frequency);
+   }
+
+   beeper->bell_frequency = bell_frequency;
+}
+
 static int pwm_beeper_probe(struct platform_device *pdev)
 {
unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
@@ -122,6 +139,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
pwm_apply_args(beeper->pwm);
 
INIT_WORK(>work, pwm_beeper_work);
+   pwm_beeper_init_bell_frequency(>dev, beeper);
 
beeper->input = input_allocate_device();
if (!beeper->input) {
-- 
2.7.4

[PATCH] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

From: Guan Ben 

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher 

---

 .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++
 drivers/input/misc/pwm-beeper.c| 36 --
 2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..438c6e0 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
 Required properties:
 - compatible: should be "pwm-beeper"
 - pwms: phandle to the physical PWM device
+
+optional properties:
+- bell-frequency:  bell frequency in Hz
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 5f9655d..99591d5 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -27,6 +27,7 @@ struct pwm_beeper {
struct pwm_device *pwm;
struct work_struct work;
unsigned long period;
+   unsigned int bell_frequency;
 };
 
 #define HZ_TO_NANOSECONDS(x) (10UL/(x))
@@ -58,20 +59,17 @@ static int pwm_beeper_event(struct input_dev *input,
if (type != EV_SND || value < 0)
return -EINVAL;
 
-   switch (code) {
-   case SND_BELL:
-   value = value ? 1000 : 0;
-   break;
-   case SND_TONE:
-   break;
-   default:
+   if (code != SND_BELL && code != SND_TONE)
return -EINVAL;
-   }
 
if (value == 0)
beeper->period = 0;
-   else
+   else {
+   if (code == SND_BELL)
+   value = beeper->bell_frequency;
+
beeper->period = HZ_TO_NANOSECONDS(value);
+   }
 
schedule_work(>work);
 
@@ -93,6 +91,25 @@ static void pwm_beeper_close(struct input_dev *input)
pwm_beeper_stop(beeper);
 }
 
+static void pwm_beeper_init_bell_frequency(struct device *dev,
+  struct pwm_beeper *beeper)
+{
+   struct device_node *node;
+   unsigned int bell_frequency = 1000;
+   int error;
+
+   if (IS_ENABLED(CONFIG_OF)) {
+   node = dev->of_node;
+   error = of_property_read_u32(node, "bell-frequency",
+_frequency);
+   if (error < 0)
+   dev_dbg(dev, "Failed to read bell-frequency, using 
default: %u Hz\n",
+   bell_frequency);
+   }
+
+   beeper->bell_frequency = bell_frequency;
+}
+
 static int pwm_beeper_probe(struct platform_device *pdev)
 {
unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
@@ -122,6 +139,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
pwm_apply_args(beeper->pwm);
 
INIT_WORK(>work, pwm_beeper_work);
+   pwm_beeper_init_bell_frequency(>dev, beeper);
 
beeper->input = input_allocate_device();
if (!beeper->input) {
-- 
2.7.4

Re: [PATCH 01/37] ARM: dts: imx6dl-aristainetos2: Correct license text

[Heiko Schocher]

Hello Alexandre,

Am 15.12.2016 um 00:57 schrieb Alexandre Belloni:

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Dong Aisheng <aisheng.d...@freescale.com>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Heiko Schocher <h...@denx.de>
Cc: Rafał Miłecki <zaj...@gmail.com>
Cc: Ulf Hansson <ulf.hans...@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.bell...@free-electrons.com>
---
  arch/arm/boot/dts/imx6dl-aristainetos2_4.dts | 10 +-
  arch/arm/boot/dts/imx6dl-aristainetos2_7.dts | 10 +-
  arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi | 10 +-
  3 files changed, 15 insertions(+), 15 deletions(-)


Thanks!

Reviewed-by: Heiko Schocher <h...@denx.de>

Hmm.. BTW ... is this copy and paste not boring? Should we not
use "SPDX-License-Identifier" [1] like for example in U-Boot ?

bye,
Heiko
[1] https://spdx.org/licenses/



diff --git a/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts 
b/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts
index bb92f309c191..0677625463d6 100644
--- a/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts
+++ b/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts
@@ -12,17 +12,17 @@
   * modify it under the terms of the GNU General Public License
   * version 2 as published by the Free Software Foundation.
   *
- * This file is distributed in the hope that it will be useful
+ * This file is distributed in the hope that it will be useful,
   * but WITHOUT ANY WARRANTY; without even the implied warranty of
   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   * GNU General Public License for more details.
   *
- * Or, alternatively
+ * Or, alternatively,
   *
   *  b) Permission is hereby granted, free of charge, to any person
   * obtaining a copy of this software and associated documentation
   * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
   * copy, modify, merge, publish, distribute, sublicense, and/or
   * sell copies of the Software, and to permit persons to whom the
   * Software is furnished to do so, subject to the following
@@ -31,11 +31,11 @@
   * The above copyright notice and this permission notice shall be
   * included in all copies or substantial portions of the Software.
   *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
   * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
   * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
   * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
   * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
   * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
   * OTHER DEALINGS IN THE SOFTWARE.
diff --git a/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts 
b/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts
index 3d5ad2cc7e22..805b1318b7f7 100644
--- a/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts
+++ b/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts
@@ -12,17 +12,17 @@
   * modify it under the terms of the GNU General Public License
   * version 2 as published by the Free Software Foundation.
   *
- * This file is distributed in the hope that it will be useful
+ * This file is distributed in the hope that it will be useful,
   * but WITHOUT ANY WARRANTY; without even the implied warranty of
   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   * GNU General Public License for more details.
   *
- * Or, alternatively
+ * Or, alternatively,
   *
   *  b) Permission is hereby granted, free of charge, to any person
   * obtaining a copy of this software and associated documentation
   * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
   * copy, modify, merge, publish, distribute, sublicense, and/or
   * sell copies of the Software, and to permit persons to whom the
   * Software is furnished to do so, subject to the following
@@ -31,11 +31,11 @@
   * The above copyright notice and this permission notice shall be
   * included in all copies or substantial portions of the Software.
   *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
   * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIE

Re: [PATCH 01/37] ARM: dts: imx6dl-aristainetos2: Correct license text

[Heiko Schocher]

Hello Alexandre,

Am 15.12.2016 um 00:57 schrieb Alexandre Belloni:

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Dong Aisheng 
Cc: Geert Uytterhoeven 
Cc: Heiko Schocher 
Cc: Rafał Miłecki 
Cc: Ulf Hansson 
Signed-off-by: Alexandre Belloni 
---
  arch/arm/boot/dts/imx6dl-aristainetos2_4.dts | 10 +-
  arch/arm/boot/dts/imx6dl-aristainetos2_7.dts | 10 +-
  arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi | 10 +-
  3 files changed, 15 insertions(+), 15 deletions(-)


Thanks!

Reviewed-by: Heiko Schocher 

Hmm.. BTW ... is this copy and paste not boring? Should we not
use "SPDX-License-Identifier" [1] like for example in U-Boot ?

bye,
Heiko
[1] https://spdx.org/licenses/



diff --git a/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts 
b/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts
index bb92f309c191..0677625463d6 100644
--- a/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts
+++ b/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts
@@ -12,17 +12,17 @@
   * modify it under the terms of the GNU General Public License
   * version 2 as published by the Free Software Foundation.
   *
- * This file is distributed in the hope that it will be useful
+ * This file is distributed in the hope that it will be useful,
   * but WITHOUT ANY WARRANTY; without even the implied warranty of
   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   * GNU General Public License for more details.
   *
- * Or, alternatively
+ * Or, alternatively,
   *
   *  b) Permission is hereby granted, free of charge, to any person
   * obtaining a copy of this software and associated documentation
   * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
   * copy, modify, merge, publish, distribute, sublicense, and/or
   * sell copies of the Software, and to permit persons to whom the
   * Software is furnished to do so, subject to the following
@@ -31,11 +31,11 @@
   * The above copyright notice and this permission notice shall be
   * included in all copies or substantial portions of the Software.
   *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
   * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
   * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
   * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
   * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
   * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
   * OTHER DEALINGS IN THE SOFTWARE.
diff --git a/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts 
b/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts
index 3d5ad2cc7e22..805b1318b7f7 100644
--- a/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts
+++ b/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts
@@ -12,17 +12,17 @@
   * modify it under the terms of the GNU General Public License
   * version 2 as published by the Free Software Foundation.
   *
- * This file is distributed in the hope that it will be useful
+ * This file is distributed in the hope that it will be useful,
   * but WITHOUT ANY WARRANTY; without even the implied warranty of
   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   * GNU General Public License for more details.
   *
- * Or, alternatively
+ * Or, alternatively,
   *
   *  b) Permission is hereby granted, free of charge, to any person
   * obtaining a copy of this software and associated documentation
   * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
   * copy, modify, merge, publish, distribute, sublicense, and/or
   * sell copies of the Software, and to permit persons to whom the
   * Software is furnished to do so, subject to the following
@@ -31,11 +31,11 @@
   * The above copyright notice and this permission notice shall be
   * included in all copies or substantial portions of the Software.
   *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
   * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
   * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
   * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILIT

Re: [PATCH v2] ubifs: compress lines for immediate return

[Heiko Schocher]

Hello Richard,

Am 05.09.2016 um 15:32 schrieb Richard Weinberger:

On 05.09.2016 15:05, Heiko Schocher wrote:

@Richard: Should we just forget this patch?


Let's drop it for now.
It caused already a way more churn than a trivial style cleanup
patch should...


Yes! It was a too fast shoot ... sorry for the noise!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH v2] ubifs: compress lines for immediate return

[Heiko Schocher]

Hello Richard,

Am 05.09.2016 um 15:32 schrieb Richard Weinberger:

On 05.09.2016 15:05, Heiko Schocher wrote:

@Richard: Should we just forget this patch?


Let's drop it for now.
It caused already a way more churn than a trivial style cleanup
patch should...


Yes! It was a too fast shoot ... sorry for the noise!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH v2] ubifs: compress lines for immediate return

[Heiko Schocher]

Hello Masahiro,

Am 05.09.2016 um 14:44 schrieb Masahiro Yamada:

Hi Heiko, Richard,




2016-09-05 15:54 GMT+09:00 Heiko Schocher <h...@denx.de>:

From: Masahiro Yamada <yamada.masah...@socionext.com>

Cleanup the following code construct:
ret = expression;
if (ret)
 return ret;
return 0;

into a simple form:
return expression;

From: Masahiro Yamada <yamada.masah...@socionext.com>
posted on the U-Boot mailinglist.

Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
Signed-off-by: Heiko Schocher <h...@denx.de>




I am the author of the original patch in the U-Boot ML.

Please notice it has not passed the review in U-Boot ML yet.
Actually, I got some feedback against this patch.

See
http://patchwork.ozlabs.org/patch/665199/

Stephan Warren suggested that
we should not break code uniformity.


After I considered it and took a closer look,
I decided that we should not do these changes.


This patch breaks the code uniformity.
See blow:





  /**
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index 821b348..88cd61d 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -297,10 +297,8 @@ static int sort_nodes(struct ubifs_info *c, struct 
ubifs_scan_leb *sleb,
 err = dbg_check_data_nodes_order(c, >nodes);
 if (err)
 return err;
-   err = dbg_check_nondata_nodes_order(c, nondata);
-   if (err)
-   return err;
-   return 0;
+
+   return dbg_check_nondata_nodes_order(c, nondata);
  }


Original code has uniformity here.


err = dbg_check_data_nodes_order(c, >nodes);
if (err)
return err;
err = dbg_check_nondata_nodes_order(c, nondata);
if (err)
return err;




  /**
diff --git a/fs/ubifs/lpt_commit.c b/fs/ubifs/lpt_commit.c
index ce89bdc..79a8e96 100644
--- a/fs/ubifs/lpt_commit.c
+++ b/fs/ubifs/lpt_commit.c
@@ -313,10 +313,7 @@ static int layout_cnodes(struct ubifs_info *c)
 alen = ALIGN(offs, c->min_io_size);
 upd_ltab(c, lnum, c->leb_size - alen, alen - offs);
 dbg_chk_lpt_sz(c, 4, alen - offs);
-   err = dbg_chk_lpt_sz(c, 3, alen);
-   if (err)
-   return err;
-   return 0;
+   return dbg_chk_lpt_sz(c, 3, alen);



We have dbg_chk_lpt_sz() call just above  (its return value is ignored)

So, returning the value of the last dbg_chk_lpt_sz() call
seems a bit weird.  So, I do not want to touch this.




Heiko,
If you want to post this patch, it is up to you.
But, in that case, could you drop my Author and Signed-off-by,
then send it as your patch, please?

I do not feel comfortable with my authorship
for what I decided to not do.


I will retract my original patch from the U-Boot ML, too.


Oh, then I was a little to fast ... sorry.

@Richard: Should we just forget this patch?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH v2] ubifs: compress lines for immediate return

[Heiko Schocher]

Hello Masahiro,

Am 05.09.2016 um 14:44 schrieb Masahiro Yamada:

Hi Heiko, Richard,




2016-09-05 15:54 GMT+09:00 Heiko Schocher :

From: Masahiro Yamada 

Cleanup the following code construct:
ret = expression;
if (ret)
 return ret;
return 0;

into a simple form:
return expression;

From: Masahiro Yamada 
posted on the U-Boot mailinglist.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Heiko Schocher 




I am the author of the original patch in the U-Boot ML.

Please notice it has not passed the review in U-Boot ML yet.
Actually, I got some feedback against this patch.

See
http://patchwork.ozlabs.org/patch/665199/

Stephan Warren suggested that
we should not break code uniformity.


After I considered it and took a closer look,
I decided that we should not do these changes.


This patch breaks the code uniformity.
See blow:





  /**
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index 821b348..88cd61d 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -297,10 +297,8 @@ static int sort_nodes(struct ubifs_info *c, struct 
ubifs_scan_leb *sleb,
 err = dbg_check_data_nodes_order(c, >nodes);
 if (err)
 return err;
-   err = dbg_check_nondata_nodes_order(c, nondata);
-   if (err)
-   return err;
-   return 0;
+
+   return dbg_check_nondata_nodes_order(c, nondata);
  }


Original code has uniformity here.


err = dbg_check_data_nodes_order(c, >nodes);
if (err)
return err;
err = dbg_check_nondata_nodes_order(c, nondata);
if (err)
return err;




  /**
diff --git a/fs/ubifs/lpt_commit.c b/fs/ubifs/lpt_commit.c
index ce89bdc..79a8e96 100644
--- a/fs/ubifs/lpt_commit.c
+++ b/fs/ubifs/lpt_commit.c
@@ -313,10 +313,7 @@ static int layout_cnodes(struct ubifs_info *c)
 alen = ALIGN(offs, c->min_io_size);
 upd_ltab(c, lnum, c->leb_size - alen, alen - offs);
 dbg_chk_lpt_sz(c, 4, alen - offs);
-   err = dbg_chk_lpt_sz(c, 3, alen);
-   if (err)
-   return err;
-   return 0;
+   return dbg_chk_lpt_sz(c, 3, alen);



We have dbg_chk_lpt_sz() call just above  (its return value is ignored)

So, returning the value of the last dbg_chk_lpt_sz() call
seems a bit weird.  So, I do not want to touch this.




Heiko,
If you want to post this patch, it is up to you.
But, in that case, could you drop my Author and Signed-off-by,
then send it as your patch, please?

I do not feel comfortable with my authorship
for what I decided to not do.


I will retract my original patch from the U-Boot ML, too.


Oh, then I was a little to fast ... sorry.

@Richard: Should we just forget this patch?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[PATCH v2] ubifs: compress lines for immediate return

[Heiko Schocher]

From: Masahiro Yamada <yamada.masah...@socionext.com>

Cleanup the following code construct:
ret = expression;
if (ret)
return ret;
return 0;

into a simple form:
return expression;

From: Masahiro Yamada <yamada.masah...@socionext.com>
posted on the U-Boot mailinglist.

Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
Signed-off-by: Heiko Schocher <h...@denx.de>
---

Changes in v2:
- add comment from Richard Weinberger:
  rephrase commit message
  add Masahiros "Signed-off-by" tag.

 fs/ubifs/budget.c | 7 ++-
 fs/ubifs/gc.c | 6 ++
 fs/ubifs/lpt_commit.c | 5 +
 3 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/fs/ubifs/budget.c b/fs/ubifs/budget.c
index 11a11b3..48d6851 100644
--- a/fs/ubifs/budget.c
+++ b/fs/ubifs/budget.c
@@ -77,7 +77,7 @@ static void shrink_liability(struct ubifs_info *c, int 
nr_to_write)
  */
 static int run_gc(struct ubifs_info *c)
 {
-   int err, lnum;
+   int lnum;
 
/* Make some free space by garbage-collecting dirty space */
down_read(>commit_sem);
@@ -88,10 +88,7 @@ static int run_gc(struct ubifs_info *c)
 
/* GC freed one LEB, return it to lprops */
dbg_budg("GC freed LEB %d", lnum);
-   err = ubifs_return_leb(c, lnum);
-   if (err)
-   return err;
-   return 0;
+   return = ubifs_return_leb(c, lnum);
 }
 
 /**
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index 821b348..88cd61d 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -297,10 +297,8 @@ static int sort_nodes(struct ubifs_info *c, struct 
ubifs_scan_leb *sleb,
err = dbg_check_data_nodes_order(c, >nodes);
if (err)
return err;
-   err = dbg_check_nondata_nodes_order(c, nondata);
-   if (err)
-   return err;
-   return 0;
+
+   return dbg_check_nondata_nodes_order(c, nondata);
 }
 
 /**
diff --git a/fs/ubifs/lpt_commit.c b/fs/ubifs/lpt_commit.c
index ce89bdc..79a8e96 100644
--- a/fs/ubifs/lpt_commit.c
+++ b/fs/ubifs/lpt_commit.c
@@ -313,10 +313,7 @@ static int layout_cnodes(struct ubifs_info *c)
alen = ALIGN(offs, c->min_io_size);
upd_ltab(c, lnum, c->leb_size - alen, alen - offs);
dbg_chk_lpt_sz(c, 4, alen - offs);
-   err = dbg_chk_lpt_sz(c, 3, alen);
-   if (err)
-   return err;
-   return 0;
+   return dbg_chk_lpt_sz(c, 3, alen);
 
 no_space:
ubifs_err(c, "LPT out of space at LEB %d:%d needing %d, done_ltab %d, 
done_lsave %d",
-- 
2.5.5

[PATCH v2] ubifs: compress lines for immediate return

[Heiko Schocher]

From: Masahiro Yamada 

Cleanup the following code construct:
ret = expression;
if (ret)
return ret;
return 0;

into a simple form:
return expression;

From: Masahiro Yamada 
posted on the U-Boot mailinglist.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Heiko Schocher 
---

Changes in v2:
- add comment from Richard Weinberger:
  rephrase commit message
  add Masahiros "Signed-off-by" tag.

 fs/ubifs/budget.c | 7 ++-
 fs/ubifs/gc.c | 6 ++
 fs/ubifs/lpt_commit.c | 5 +
 3 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/fs/ubifs/budget.c b/fs/ubifs/budget.c
index 11a11b3..48d6851 100644
--- a/fs/ubifs/budget.c
+++ b/fs/ubifs/budget.c
@@ -77,7 +77,7 @@ static void shrink_liability(struct ubifs_info *c, int 
nr_to_write)
  */
 static int run_gc(struct ubifs_info *c)
 {
-   int err, lnum;
+   int lnum;
 
/* Make some free space by garbage-collecting dirty space */
down_read(>commit_sem);
@@ -88,10 +88,7 @@ static int run_gc(struct ubifs_info *c)
 
/* GC freed one LEB, return it to lprops */
dbg_budg("GC freed LEB %d", lnum);
-   err = ubifs_return_leb(c, lnum);
-   if (err)
-   return err;
-   return 0;
+   return = ubifs_return_leb(c, lnum);
 }
 
 /**
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index 821b348..88cd61d 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -297,10 +297,8 @@ static int sort_nodes(struct ubifs_info *c, struct 
ubifs_scan_leb *sleb,
err = dbg_check_data_nodes_order(c, >nodes);
if (err)
return err;
-   err = dbg_check_nondata_nodes_order(c, nondata);
-   if (err)
-   return err;
-   return 0;
+
+   return dbg_check_nondata_nodes_order(c, nondata);
 }
 
 /**
diff --git a/fs/ubifs/lpt_commit.c b/fs/ubifs/lpt_commit.c
index ce89bdc..79a8e96 100644
--- a/fs/ubifs/lpt_commit.c
+++ b/fs/ubifs/lpt_commit.c
@@ -313,10 +313,7 @@ static int layout_cnodes(struct ubifs_info *c)
alen = ALIGN(offs, c->min_io_size);
upd_ltab(c, lnum, c->leb_size - alen, alen - offs);
dbg_chk_lpt_sz(c, 4, alen - offs);
-   err = dbg_chk_lpt_sz(c, 3, alen);
-   if (err)
-   return err;
-   return 0;
+   return dbg_chk_lpt_sz(c, 3, alen);
 
 no_space:
ubifs_err(c, "LPT out of space at LEB %d:%d needing %d, done_ltab %d, 
done_lsave %d",
-- 
2.5.5

Re: [PATCH] ubifs: compress lines for immediate return

[Heiko Schocher]

Hello Richard,

Am 05.09.2016 um 08:28 schrieb Richard Weinberger:

Heiko,

On 05.09.2016 06:59, Heiko Schocher wrote:

fix the following code:

-ret = expression;
-if (ret)
-return ret;
-return 0;
+return expression;


"Fix"? ;-)
What was broken?


Ok, fix is to hard spoken ... nothing broken, sorry for confusing!


I agree that we can write the expression in a different way, but is it really 
worth it?


I think yes ...


Is this part of a tree-wide cleanup?


Yes, and I thought it is worth to change this part in linux too.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] ubifs: compress lines for immediate return

[Heiko Schocher]

Hello Richard,

Am 05.09.2016 um 08:28 schrieb Richard Weinberger:

Heiko,

On 05.09.2016 06:59, Heiko Schocher wrote:

fix the following code:

-ret = expression;
-if (ret)
-return ret;
-return 0;
+return expression;


"Fix"? ;-)
What was broken?


Ok, fix is to hard spoken ... nothing broken, sorry for confusing!


I agree that we can write the expression in a different way, but is it really 
worth it?


I think yes ...


Is this part of a tree-wide cleanup?


Yes, and I thought it is worth to change this part in linux too.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[PATCH] ubifs: compress lines for immediate return

[Heiko Schocher]

fix the following code:

-ret = expression;
-if (ret)
-return ret;
-return 0;
+return expression;

From: Masahiro Yamada <yamada.masah...@socionext.com>
posted on the U-Boot mailinglist.

Signed-off-by: Heiko Schocher <h...@denx.de>
---

 fs/ubifs/budget.c | 7 ++-
 fs/ubifs/gc.c | 6 ++
 fs/ubifs/lpt_commit.c | 5 +
 3 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/fs/ubifs/budget.c b/fs/ubifs/budget.c
index 11a11b3..48d6851 100644
--- a/fs/ubifs/budget.c
+++ b/fs/ubifs/budget.c
@@ -77,7 +77,7 @@ static void shrink_liability(struct ubifs_info *c, int 
nr_to_write)
  */
 static int run_gc(struct ubifs_info *c)
 {
-   int err, lnum;
+   int lnum;
 
/* Make some free space by garbage-collecting dirty space */
down_read(>commit_sem);
@@ -88,10 +88,7 @@ static int run_gc(struct ubifs_info *c)
 
/* GC freed one LEB, return it to lprops */
dbg_budg("GC freed LEB %d", lnum);
-   err = ubifs_return_leb(c, lnum);
-   if (err)
-   return err;
-   return 0;
+   return = ubifs_return_leb(c, lnum);
 }
 
 /**
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index 821b348..88cd61d 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -297,10 +297,8 @@ static int sort_nodes(struct ubifs_info *c, struct 
ubifs_scan_leb *sleb,
err = dbg_check_data_nodes_order(c, >nodes);
if (err)
return err;
-   err = dbg_check_nondata_nodes_order(c, nondata);
-   if (err)
-   return err;
-   return 0;
+
+   return dbg_check_nondata_nodes_order(c, nondata);
 }
 
 /**
diff --git a/fs/ubifs/lpt_commit.c b/fs/ubifs/lpt_commit.c
index ce89bdc..79a8e96 100644
--- a/fs/ubifs/lpt_commit.c
+++ b/fs/ubifs/lpt_commit.c
@@ -313,10 +313,7 @@ static int layout_cnodes(struct ubifs_info *c)
alen = ALIGN(offs, c->min_io_size);
upd_ltab(c, lnum, c->leb_size - alen, alen - offs);
dbg_chk_lpt_sz(c, 4, alen - offs);
-   err = dbg_chk_lpt_sz(c, 3, alen);
-   if (err)
-   return err;
-   return 0;
+   return dbg_chk_lpt_sz(c, 3, alen);
 
 no_space:
ubifs_err(c, "LPT out of space at LEB %d:%d needing %d, done_ltab %d, 
done_lsave %d",
-- 
2.5.5

[PATCH] ubifs: compress lines for immediate return

[Heiko Schocher]

fix the following code:

-ret = expression;
-if (ret)
-return ret;
-return 0;
+return expression;

From: Masahiro Yamada 
posted on the U-Boot mailinglist.

Signed-off-by: Heiko Schocher 
---

 fs/ubifs/budget.c | 7 ++-
 fs/ubifs/gc.c | 6 ++
 fs/ubifs/lpt_commit.c | 5 +
 3 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/fs/ubifs/budget.c b/fs/ubifs/budget.c
index 11a11b3..48d6851 100644
--- a/fs/ubifs/budget.c
+++ b/fs/ubifs/budget.c
@@ -77,7 +77,7 @@ static void shrink_liability(struct ubifs_info *c, int 
nr_to_write)
  */
 static int run_gc(struct ubifs_info *c)
 {
-   int err, lnum;
+   int lnum;
 
/* Make some free space by garbage-collecting dirty space */
down_read(>commit_sem);
@@ -88,10 +88,7 @@ static int run_gc(struct ubifs_info *c)
 
/* GC freed one LEB, return it to lprops */
dbg_budg("GC freed LEB %d", lnum);
-   err = ubifs_return_leb(c, lnum);
-   if (err)
-   return err;
-   return 0;
+   return = ubifs_return_leb(c, lnum);
 }
 
 /**
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index 821b348..88cd61d 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -297,10 +297,8 @@ static int sort_nodes(struct ubifs_info *c, struct 
ubifs_scan_leb *sleb,
err = dbg_check_data_nodes_order(c, >nodes);
if (err)
return err;
-   err = dbg_check_nondata_nodes_order(c, nondata);
-   if (err)
-   return err;
-   return 0;
+
+   return dbg_check_nondata_nodes_order(c, nondata);
 }
 
 /**
diff --git a/fs/ubifs/lpt_commit.c b/fs/ubifs/lpt_commit.c
index ce89bdc..79a8e96 100644
--- a/fs/ubifs/lpt_commit.c
+++ b/fs/ubifs/lpt_commit.c
@@ -313,10 +313,7 @@ static int layout_cnodes(struct ubifs_info *c)
alen = ALIGN(offs, c->min_io_size);
upd_ltab(c, lnum, c->leb_size - alen, alen - offs);
dbg_chk_lpt_sz(c, 4, alen - offs);
-   err = dbg_chk_lpt_sz(c, 3, alen);
-   if (err)
-   return err;
-   return 0;
+   return dbg_chk_lpt_sz(c, 3, alen);
 
 no_space:
ubifs_err(c, "LPT out of space at LEB %d:%d needing %d, done_ltab %d, 
done_lsave %d",
-- 
2.5.5

Re: [PATCH] gpu: ipu-v3: display support on the aristainetos2 board broken

[Heiko Schocher]

Hello Fabio,

Am 20.05.2016 um 13:40 schrieb Fabio Estevam:

Hi Heiko,

On Fri, May 20, 2016 at 8:15 AM, Heiko Schocher <h...@denx.de> wrote:

commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
breaks the aristainetos2 board with the "lg,lg4573" panel.

This reverts the above commit.

Signed-off-by: Heiko Schocher <h...@denx.de>

---
Any hint, how to bring back the display on the aristainetos2
board without reverting this commit would be appreciated.


Philipp sent the following patch that fixes the issue:
http://www.spinics.net/lists/dri-devel/msg107524.html


Thanks for the hint! This patch fixes the issue see log:
http://xeidos.ddns.net/buildbot/builders/ari_lx/builds/0/steps/shell/logs/tbotlog

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] gpu: ipu-v3: display support on the aristainetos2 board broken

[Heiko Schocher]

Hello Fabio,

Am 20.05.2016 um 13:40 schrieb Fabio Estevam:

Hi Heiko,

On Fri, May 20, 2016 at 8:15 AM, Heiko Schocher  wrote:

commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
breaks the aristainetos2 board with the "lg,lg4573" panel.

This reverts the above commit.

Signed-off-by: Heiko Schocher 

---
Any hint, how to bring back the display on the aristainetos2
board without reverting this commit would be appreciated.


Philipp sent the following patch that fixes the issue:
http://www.spinics.net/lists/dri-devel/msg107524.html


Thanks for the hint! This patch fixes the issue see log:
http://xeidos.ddns.net/buildbot/builders/ari_lx/builds/0/steps/shell/logs/tbotlog

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[PATCH] gpu: ipu-v3: display support on the aristainetos2 board broken

[Heiko Schocher]

commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
breaks the aristainetos2 board with the "lg,lg4573" panel.

This reverts the above commit.

Signed-off-by: Heiko Schocher <h...@denx.de>

---
Any hint, how to bring back the display on the aristainetos2
board without reverting this commit would be appreciated.

Board DTS:
arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi
arch/arm/boot/dts/imx6dl-aristainetos2_4.dts

see the log of a full automated "git bisect" session with tbot testcase:
https://github.com/hsdenx/tbot/blob/master/src/tc/board/tc_board_aristainetos2_linux_bisect.py
here:
http://xeidos.ddns.net/buildbot/builders/ari_lx_bi/builds/3/steps/shell/logs/tbotlog
for details.

 drivers/gpu/ipu-v3/ipu-common.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index abb98c7..e00db3f 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1068,6 +1068,7 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
goto err_register;
}
 
+   pdev->dev.of_node = of_node;
pdev->dev.parent = dev;
 
ret = platform_device_add_data(pdev, >pdata,
@@ -1078,12 +1079,6 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
platform_device_put(pdev);
goto err_register;
}
-
-   /*
-* Set of_node only after calling platform_device_add. Otherwise
-* the platform:imx-ipuv3-crtc modalias won't be used.
-*/
-   pdev->dev.of_node = of_node;
}
 
return 0;
-- 
2.5.5

[PATCH] gpu: ipu-v3: display support on the aristainetos2 board broken

[Heiko Schocher]

commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
breaks the aristainetos2 board with the "lg,lg4573" panel.

This reverts the above commit.

Signed-off-by: Heiko Schocher 

---
Any hint, how to bring back the display on the aristainetos2
board without reverting this commit would be appreciated.

Board DTS:
arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi
arch/arm/boot/dts/imx6dl-aristainetos2_4.dts

see the log of a full automated "git bisect" session with tbot testcase:
https://github.com/hsdenx/tbot/blob/master/src/tc/board/tc_board_aristainetos2_linux_bisect.py
here:
http://xeidos.ddns.net/buildbot/builders/ari_lx_bi/builds/3/steps/shell/logs/tbotlog
for details.

 drivers/gpu/ipu-v3/ipu-common.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index abb98c7..e00db3f 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1068,6 +1068,7 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
goto err_register;
}
 
+   pdev->dev.of_node = of_node;
pdev->dev.parent = dev;
 
ret = platform_device_add_data(pdev, >pdata,
@@ -1078,12 +1079,6 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
platform_device_put(pdev);
goto err_register;
}
-
-   /*
-* Set of_node only after calling platform_device_add. Otherwise
-* the platform:imx-ipuv3-crtc modalias won't be used.
-*/
-   pdev->dev.of_node = of_node;
}
 
return 0;
-- 
2.5.5

[PATCH] mtd, ubi: set free_count to zero before walking through erase list

[Heiko Schocher]

Set free_count to zero before walking through ai->erase list
in wl_init().

Found in U-Boot as U-Boot has no workqueue/threads, it immediately
calls erase_worker(), which increase for each erased block
free_count. Without this patch, free_count gets after
this initialized to zero in wl_init(), so the free_count
variable always has the maybe wrong value 0 in U-Boot.

Signed-off-by: Heiko Schocher <h...@denx.de>
Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
Detected this behaviour on the dxr2 board, where the
UBI fastmap gets not written when attaching/dettaching
on an empty NAND. It drops instead the error message:

could not find any anchor PEB

With this patch, fastmap gets written on dettach.

corresponding U-Boot Thread:
http://lists.denx.de/pipermail/u-boot/2016-April/252338.html

 drivers/mtd/ubi/wl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 17ec948..959c7b12 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1534,6 +1534,7 @@ int ubi_wl_init(struct ubi_device *ubi, struct 
ubi_attach_info *ai)
INIT_LIST_HEAD(>pq[i]);
ubi->pq_head = 0;
 
+   ubi->free_count = 0;
list_for_each_entry_safe(aeb, tmp, >erase, u.list) {
cond_resched();
 
@@ -1552,7 +1553,6 @@ int ubi_wl_init(struct ubi_device *ubi, struct 
ubi_attach_info *ai)
found_pebs++;
}
 
-   ubi->free_count = 0;
list_for_each_entry(aeb, >free, u.list) {
cond_resched();
 
-- 
2.5.0

[PATCH] mtd, ubi: set free_count to zero before walking through erase list

[Heiko Schocher]

Set free_count to zero before walking through ai->erase list
in wl_init().

Found in U-Boot as U-Boot has no workqueue/threads, it immediately
calls erase_worker(), which increase for each erased block
free_count. Without this patch, free_count gets after
this initialized to zero in wl_init(), so the free_count
variable always has the maybe wrong value 0 in U-Boot.

Signed-off-by: Heiko Schocher 
Reviewed-by: Boris Brezillon 
---
Detected this behaviour on the dxr2 board, where the
UBI fastmap gets not written when attaching/dettaching
on an empty NAND. It drops instead the error message:

could not find any anchor PEB

With this patch, fastmap gets written on dettach.

corresponding U-Boot Thread:
http://lists.denx.de/pipermail/u-boot/2016-April/252338.html

 drivers/mtd/ubi/wl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 17ec948..959c7b12 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1534,6 +1534,7 @@ int ubi_wl_init(struct ubi_device *ubi, struct 
ubi_attach_info *ai)
INIT_LIST_HEAD(>pq[i]);
ubi->pq_head = 0;
 
+   ubi->free_count = 0;
list_for_each_entry_safe(aeb, tmp, >erase, u.list) {
cond_resched();
 
@@ -1552,7 +1553,6 @@ int ubi_wl_init(struct ubi_device *ubi, struct 
ubi_attach_info *ai)
found_pebs++;
}
 
-   ubi->free_count = 0;
list_for_each_entry(aeb, >free, u.list) {
cond_resched();
 
-- 
2.5.0

Re: [PATCH] rtc: pcf8563: Remove CLK_IS_ROOT

[Heiko Schocher]

Hello Stephen,

Am 20.04.2016 um 03:12 schrieb Stephen Boyd:

This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.

Cc: Heiko Schocher <h...@denx.de>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
  drivers/rtc/rtc-pcf8563.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Acked-by: Heiko Schocher <h...@denx.de>

bye,
Heiko


diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index d5e6ed96b748..b9ddbb001283 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -533,7 +533,7 @@ static struct clk *pcf8563_clkout_register_clk(struct 
pcf8563 *pcf8563)

init.name = "pcf8563-clkout";
init.ops = _clkout_ops;
-   init.flags = CLK_IS_ROOT;
+   init.flags = 0;
init.parent_names = NULL;
init.num_parents = 0;
pcf8563->clkout_hw.init = 



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] rtc: pcf8563: Remove CLK_IS_ROOT

[Heiko Schocher]

Hello Stephen,

Am 20.04.2016 um 03:12 schrieb Stephen Boyd:

This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.

Cc: Heiko Schocher 
Signed-off-by: Stephen Boyd 
---
  drivers/rtc/rtc-pcf8563.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Acked-by: Heiko Schocher 

bye,
Heiko


diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index d5e6ed96b748..b9ddbb001283 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -533,7 +533,7 @@ static struct clk *pcf8563_clkout_register_clk(struct 
pcf8563 *pcf8563)

init.name = "pcf8563-clkout";
init.ops = _clkout_ops;
-   init.flags = CLK_IS_ROOT;
+   init.flags = 0;
init.parent_names = NULL;
init.num_parents = 0;
pcf8563->clkout_hw.init = 



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Revert "regulator: tps65217: remove tps65217.dtsi file"

[Heiko Schocher]

Hello Tony, Peter,

Am 19.02.2016 um 18:04 schrieb Tony Lindgren:

* Peter Ujfalusi  [160219 06:14]:

This reverts commit 8e6ebfaa9b384088002baa10f7534efa73a0794e.

Without the patch reverted regulators will not work. This prevents
MMC to be working for example so the boards can not boot to
MMC rootfs.

Tested it on beaglebone white and bisect also points to the
reverted commit.
The issue can be also fixed by adding "regulator-compatible =" to all board
dts file for the regulators.

Signed-off-by: Peter Ujfalusi 
---
Hi,

I have noticed that bbw did not find the MMC with linux-next, but it turns out
that even 4.5-rc4 is behaving the same way.
I have run bisect and with this revert patch I can boot up fine.
To be honest I don't know why the tps65217.dtsi has been deleted in the first
place.


I think initially the only real issue was the naming. The
tps65217.dtsi file should be just renamed to tps65217-am335x.dtsi
to make it clear that this configuration is commonly used for
most am335x boards.

I'll apply this revert into omap-for-v4.5/fixes as it fixes a
regression.


Sorry for breaking ... but I have no bbw hw for testing ...
(This is maybe a reason for having something like an automated
 testsystem, see an example/proposal here:

https://github.com/hsdenx/tbot

see a demo for automated tests (running on a raspberry pi at my home
in hungary, boards are in munich/germany)
http://xeidos.ddns.net/buildbot/tgrid
)

But I removed this file as Mark Brown suggested it, see:

https://lkml.org/lkml/2015/10/21/581

So please introduce a "tps65217-am335x.dtsi" file ... Mark?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Revert "regulator: tps65217: remove tps65217.dtsi file"

[Heiko Schocher]

Hello Tony, Peter,

Am 19.02.2016 um 18:04 schrieb Tony Lindgren:

* Peter Ujfalusi  [160219 06:14]:

This reverts commit 8e6ebfaa9b384088002baa10f7534efa73a0794e.

Without the patch reverted regulators will not work. This prevents
MMC to be working for example so the boards can not boot to
MMC rootfs.

Tested it on beaglebone white and bisect also points to the
reverted commit.
The issue can be also fixed by adding "regulator-compatible =" to all board
dts file for the regulators.

Signed-off-by: Peter Ujfalusi 
---
Hi,

I have noticed that bbw did not find the MMC with linux-next, but it turns out
that even 4.5-rc4 is behaving the same way.
I have run bisect and with this revert patch I can boot up fine.
To be honest I don't know why the tps65217.dtsi has been deleted in the first
place.


I think initially the only real issue was the naming. The
tps65217.dtsi file should be just renamed to tps65217-am335x.dtsi
to make it clear that this configuration is commonly used for
most am335x boards.

I'll apply this revert into omap-for-v4.5/fixes as it fixes a
regression.


Sorry for breaking ... but I have no bbw hw for testing ...
(This is maybe a reason for having something like an automated
 testsystem, see an example/proposal here:

https://github.com/hsdenx/tbot

see a demo for automated tests (running on a raspberry pi at my home
in hungary, boards are in munich/germany)
http://xeidos.ddns.net/buildbot/tgrid
)

But I removed this file as Mark Brown suggested it, see:

https://lkml.org/lkml/2015/10/21/581

So please introduce a "tps65217-am335x.dtsi" file ... Mark?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH for-4.4] mtd: nand: assign reasonable default name for NAND drivers

[Heiko Schocher]

Hello Brian,

Am 04.01.2016 um 20:11 schrieb Brian Norris:

Commits such as commit 853f1c58c4b2 ("mtd: nand: omap2: show parent
device structure in sysfs") attempt to rely on the core MTD code to set
the MTD name based on the parent device. However, nand_base tries to set
a different default name according to the flash name (e.g., extracted
from the ONFI parameter page), which means NAND drivers will never make
use of the MTD defaults. This is not the intention of commit
853f1c58c4b2.

This results in problems when trying to use the cmdline partition
parser, since the MTD name is different than expected. Let's fix this by
providing a default NAND name, where possible.

Note that this is not really a great default name in the long run, since
this means that if there are multiple MTDs attached to the same
controller device, they will have the same name. But that is an existing
issue and requires future work on a better controller vs. flash chip
abstraction to fix properly.

Reported-by: Heiko Schocher 
Signed-off-by: Brian Norris 
Cc: Heiko Schocher 
Cc: Frans Klaver 
---
This patch is needed in additon to commit 472b444eef93 ("mtd: fix cmdlinepart
parser, early naming for auto-filled MTD") to fix Heiko's reported problem. At
this point, I'm not sure if this should be targeted toward late 4.4 or for 4.5.
It's a 4.4 regresssion, but a very small one. And I'm not sure if this will
have wide enough impact that it should be given a longer time to be reviewed
and tested. We can always send it to -stable later, if it's really needed.


Ok... but I wonder if nobody have the same problems as I ...


  drivers/mtd/nand/nand_base.c | 3 +++
  1 file changed, 3 insertions(+)


Thanks!

works for me, so:

Tested-by: Heiko Schocher 

bye,
Heiko


diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ece544efccc3..9f169566fba4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3826,6 +3826,9 @@ static struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
if (!type)
type = nand_flash_ids;

+   if (!mtd->name && mtd->dev.parent)
+   mtd->name = dev_name(mtd->dev.parent);
+
for (; type->name != NULL; type++) {
if (is_full_id_nand(type)) {
if (find_full_id_nand(mtd, chip, type, id_data, ))



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
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/

Re: [PATCH for-4.4] mtd: nand: assign reasonable default name for NAND drivers

[Heiko Schocher]

Hello Brian,

Am 04.01.2016 um 20:11 schrieb Brian Norris:

Commits such as commit 853f1c58c4b2 ("mtd: nand: omap2: show parent
device structure in sysfs") attempt to rely on the core MTD code to set
the MTD name based on the parent device. However, nand_base tries to set
a different default name according to the flash name (e.g., extracted
from the ONFI parameter page), which means NAND drivers will never make
use of the MTD defaults. This is not the intention of commit
853f1c58c4b2.

This results in problems when trying to use the cmdline partition
parser, since the MTD name is different than expected. Let's fix this by
providing a default NAND name, where possible.

Note that this is not really a great default name in the long run, since
this means that if there are multiple MTDs attached to the same
controller device, they will have the same name. But that is an existing
issue and requires future work on a better controller vs. flash chip
abstraction to fix properly.

Reported-by: Heiko Schocher <h...@denx.de>
Signed-off-by: Brian Norris <computersforpe...@gmail.com>
Cc: Heiko Schocher <h...@denx.de>
Cc: Frans Klaver <franskla...@gmail.com>
---
This patch is needed in additon to commit 472b444eef93 ("mtd: fix cmdlinepart
parser, early naming for auto-filled MTD") to fix Heiko's reported problem. At
this point, I'm not sure if this should be targeted toward late 4.4 or for 4.5.
It's a 4.4 regresssion, but a very small one. And I'm not sure if this will
have wide enough impact that it should be given a longer time to be reviewed
and tested. We can always send it to -stable later, if it's really needed.


Ok... but I wonder if nobody have the same problems as I ...


  drivers/mtd/nand/nand_base.c | 3 +++
  1 file changed, 3 insertions(+)


Thanks!

works for me, so:

Tested-by: Heiko Schocher <h...@denx.de>

bye,
Heiko


diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ece544efccc3..9f169566fba4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3826,6 +3826,9 @@ static struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
if (!type)
type = nand_flash_ids;

+   if (!mtd->name && mtd->dev.parent)
+   mtd->name = dev_name(mtd->dev.parent);
+
for (; type->name != NULL; type++) {
if (is_full_id_nand(type)) {
if (find_full_id_nand(mtd, chip, type, id_data, ))



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
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/

Re: [PATCH for-4.4] mtd: fix cmdlinepart parser, early naming for auto-filled MTD

[Heiko Schocher]

Hello Brian,

Am 14.12.2015 um 20:24 schrieb Brian Norris:

On Fri, Dec 11, 2015 at 09:39:18PM -0800, Brian Norris wrote:

On Sat, Dec 12, 2015 at 05:45:21AM +0100, Heiko Schocher wrote:

Am 12.12.2015 um 00:58 schrieb Brian Norris:

Commit 807f16d4db95 ("mtd: core: set some defaults when dev.parent is
set") attempted to provide some default settings for MTDs that
  (a) assign the parent device and
  (b) don't provide their own name or owner

However, this isn't a perfect drop-in replacement for the boilerplate
found in some drivers, because the MTD name is used by partition
parsers like cmdlinepart, but the name isn't set until add_mtd_device(),
after the parsing is completed. This means cmdlinepart sees a NULL name
and therefore will not work properly.

Fix this by moving the default name and owner assignment to be first in
the MTD registration process.

Fixes: 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set")
Reported-by: Heiko Schocher 
Signed-off-by: Brian Norris 
Cc: Heiko Schocher 
Cc: Frans Klaver 
---
Heiko, can you provide testing feedback (e.g., 'Tested-by: ...')?


Sorry, does not work for me:

Based on:
pollux:linux hs [20151212] $ git describe master
v4.4-rc4-135-gb9d8545

and this patch, shows the same problem,


[...]


BTW, can you please include the relevant log snippets when replying in
the future?


Uh, Sorry for that, yes of course ...


Ugh, I see the problem. In nand_base.c, nand_get_flash_type():

if (!mtd->name)
mtd->name = type->name;


Specifically, I think we could hack around this with something like the
following additional patch. Untested:

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ece544efccc3..9f169566fba4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3826,6 +3826,9 @@ static struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
if (!type)
type = nand_flash_ids;

+   if (!mtd->name && mtd->dev.parent)
+   mtd->name = dev_name(mtd->dev.parent);
+
for (; type->name != NULL; type++) {
if (is_full_id_nand(type)) {
if (find_full_id_nand(mtd, chip, type, id_data, ))



Sorry, I had not yet the time to look into the issue deeper, Thanks for
digging into it. I tried therefore your patch (automated with tbot see
below [1]) on linux "v4.4-rc5" and

your patch works!

bye,
Heiko

[1] automated test with tbot [2]
http://xeidos.ddns.net/buildbot/builders/mcx/builds/7/steps/shell/logs/tbotlog

as there is a lot of things done automatically, search for
"Micron MT29F4G16ABADAWP"

All you see in the log is done automatically with tbot. The mcx board
is in munich, while I am doing the test from hungary. In my testsetup
tbot is integrated into buildbot, which is used for the webserver
and triggering builds.

What is done:
- get linux code (if it is not already checked out)
- apply patches
  (I have also a testcase, which download all patches from patchwork,
   which are delegated to me (for u-boot), check them with checkpatch
   and apply it ... very helpful, if this is done in a nightly build,
   you have only to look in the morning, if all is green, and you know
   that all patches are checkpatch clean, apply celan, compile clean
   and do not break the boards you have in your nightly build ... also
   there is a testcase which starts a git bisect test [3] ...)

   As I did not mainlined the board yet, there are a bunch of checkpatch
   errors, so I disabled that the testcase fails, if there are errors.

- compile linux
- copy files to tftpdir
- boot them
- execute testcases
  for example check in dmesg some strings with:
  https://github.com/hsdenx/tbot/blob/master/src/tc/tc_lx_dmesg_grep.py

  So detected our current bug ;-)

  check register settings with devmem2:
  https://github.com/hsdenx/tbot/blob/master/src/tc/tc_lx_check_reg_file.py

  Thats very nice, as you can check for example complete pinmux register.
  see as an example [4]

last but not least, tbot (and buildbot incl. webserver) is running on a
raspberry pi at my home! So no expensive hw costs.

[2] https://github.com/hsdenx/tbot
[3] git bisect automated:
https://github.com/hsdenx/tbot/blob/master/src/tc/tc_board_git_bisect.py
log as an example for U-Boot:

http://xeidos.ddns.net/buildbot/builders/tqm5200s/builds/3/steps/shell/logs/tbotlog
[4] register file
https://github.com/hsdenx/tbot/blob/master/src/files/ccu1_pinmux_scm.reg

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
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/

Re: [PATCH for-4.4] mtd: fix cmdlinepart parser, early naming for auto-filled MTD

[Heiko Schocher]

Hello Brian,

Am 14.12.2015 um 20:24 schrieb Brian Norris:

On Fri, Dec 11, 2015 at 09:39:18PM -0800, Brian Norris wrote:

On Sat, Dec 12, 2015 at 05:45:21AM +0100, Heiko Schocher wrote:

Am 12.12.2015 um 00:58 schrieb Brian Norris:

Commit 807f16d4db95 ("mtd: core: set some defaults when dev.parent is
set") attempted to provide some default settings for MTDs that
  (a) assign the parent device and
  (b) don't provide their own name or owner

However, this isn't a perfect drop-in replacement for the boilerplate
found in some drivers, because the MTD name is used by partition
parsers like cmdlinepart, but the name isn't set until add_mtd_device(),
after the parsing is completed. This means cmdlinepart sees a NULL name
and therefore will not work properly.

Fix this by moving the default name and owner assignment to be first in
the MTD registration process.

Fixes: 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set")
Reported-by: Heiko Schocher <h...@denx.de>
Signed-off-by: Brian Norris <computersforpe...@gmail.com>
Cc: Heiko Schocher <h...@denx.de>
Cc: Frans Klaver <franskla...@gmail.com>
---
Heiko, can you provide testing feedback (e.g., 'Tested-by: ...')?


Sorry, does not work for me:

Based on:
pollux:linux hs [20151212] $ git describe master
v4.4-rc4-135-gb9d8545

and this patch, shows the same problem,


[...]


BTW, can you please include the relevant log snippets when replying in
the future?


Uh, Sorry for that, yes of course ...


Ugh, I see the problem. In nand_base.c, nand_get_flash_type():

if (!mtd->name)
mtd->name = type->name;


Specifically, I think we could hack around this with something like the
following additional patch. Untested:

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ece544efccc3..9f169566fba4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3826,6 +3826,9 @@ static struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
if (!type)
type = nand_flash_ids;

+   if (!mtd->name && mtd->dev.parent)
+   mtd->name = dev_name(mtd->dev.parent);
+
for (; type->name != NULL; type++) {
if (is_full_id_nand(type)) {
if (find_full_id_nand(mtd, chip, type, id_data, ))



Sorry, I had not yet the time to look into the issue deeper, Thanks for
digging into it. I tried therefore your patch (automated with tbot see
below [1]) on linux "v4.4-rc5" and

your patch works!

bye,
Heiko

[1] automated test with tbot [2]
http://xeidos.ddns.net/buildbot/builders/mcx/builds/7/steps/shell/logs/tbotlog

as there is a lot of things done automatically, search for
"Micron MT29F4G16ABADAWP"

All you see in the log is done automatically with tbot. The mcx board
is in munich, while I am doing the test from hungary. In my testsetup
tbot is integrated into buildbot, which is used for the webserver
and triggering builds.

What is done:
- get linux code (if it is not already checked out)
- apply patches
  (I have also a testcase, which download all patches from patchwork,
   which are delegated to me (for u-boot), check them with checkpatch
   and apply it ... very helpful, if this is done in a nightly build,
   you have only to look in the morning, if all is green, and you know
   that all patches are checkpatch clean, apply celan, compile clean
   and do not break the boards you have in your nightly build ... also
   there is a testcase which starts a git bisect test [3] ...)

   As I did not mainlined the board yet, there are a bunch of checkpatch
   errors, so I disabled that the testcase fails, if there are errors.

- compile linux
- copy files to tftpdir
- boot them
- execute testcases
  for example check in dmesg some strings with:
  https://github.com/hsdenx/tbot/blob/master/src/tc/tc_lx_dmesg_grep.py

  So detected our current bug ;-)

  check register settings with devmem2:
  https://github.com/hsdenx/tbot/blob/master/src/tc/tc_lx_check_reg_file.py

  Thats very nice, as you can check for example complete pinmux register.
  see as an example [4]

last but not least, tbot (and buildbot incl. webserver) is running on a
raspberry pi at my home! So no expensive hw costs.

[2] https://github.com/hsdenx/tbot
[3] git bisect automated:
https://github.com/hsdenx/tbot/blob/master/src/tc/tc_board_git_bisect.py
log as an example for U-Boot:

http://xeidos.ddns.net/buildbot/builders/tqm5200s/builds/3/steps/shell/logs/tbotlog
[4] register file
https://github.com/hsdenx/tbot/blob/master/src/files/ccu1_pinmux_scm.reg

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
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/