2020-11-20 23:41:49

by Jeremy Linton

[permalink] [raw]
Subject: [PATCH] mmc: sdhci: Update firmware interface API

The device_* calls were added a few years ago to abstract
DT/ACPI/fwnode firmware interfaces. Lets convert the two
sdhci caps fields to use the generic calls rather than the OF
specific ones. This has the side effect of allowing
ACPI based devices to quirk themselves when the caps field
is broken.

Signed-off-by: Jeremy Linton <[email protected]>
---
drivers/mmc/host/sdhci.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 592a55a34b58..feba64fbde16 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3992,10 +3992,10 @@ void __sdhci_read_caps(struct sdhci_host *host, const u16 *ver,
if (host->v4_mode)
sdhci_do_enable_v4_mode(host);

- of_property_read_u64(mmc_dev(host->mmc)->of_node,
- "sdhci-caps-mask", &dt_caps_mask);
- of_property_read_u64(mmc_dev(host->mmc)->of_node,
- "sdhci-caps", &dt_caps);
+ device_property_read_u64_array(mmc_dev(host->mmc),
+ "sdhci-caps-mask", &dt_caps_mask, 1);
+ device_property_read_u64_array(mmc_dev(host->mmc),
+ "sdhci-caps", &dt_caps, 1);

v = ver ? *ver : sdhci_readw(host, SDHCI_HOST_VERSION);
host->version = (v & SDHCI_SPEC_VER_MASK) >> SDHCI_SPEC_VER_SHIFT;
--
2.26.2


2020-11-24 23:04:11

by Adrian Hunter

[permalink] [raw]
Subject: Re: [PATCH] mmc: sdhci: Update firmware interface API

On 24/11/20 4:25 pm, Ulf Hansson wrote:
> On Sat, 21 Nov 2020 at 00:39, Jeremy Linton <[email protected]> wrote:
>>
>> The device_* calls were added a few years ago to abstract
>> DT/ACPI/fwnode firmware interfaces. Lets convert the two
>> sdhci caps fields to use the generic calls rather than the OF
>> specific ones. This has the side effect of allowing
>> ACPI based devices to quirk themselves when the caps field
>> is broken.
>>
>> Signed-off-by: Jeremy Linton <[email protected]>
>
> Applied for next, thanks!
>
> Kind regards
> Uffe
>
>
>> ---
>> drivers/mmc/host/sdhci.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 592a55a34b58..feba64fbde16 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -3992,10 +3992,10 @@ void __sdhci_read_caps(struct sdhci_host *host, const u16 *ver,
>> if (host->v4_mode)
>> sdhci_do_enable_v4_mode(host);
>>
>> - of_property_read_u64(mmc_dev(host->mmc)->of_node,
>> - "sdhci-caps-mask", &dt_caps_mask);
>> - of_property_read_u64(mmc_dev(host->mmc)->of_node,
>> - "sdhci-caps", &dt_caps);
>> + device_property_read_u64_array(mmc_dev(host->mmc),
>> + "sdhci-caps-mask", &dt_caps_mask, 1);
>> + device_property_read_u64_array(mmc_dev(host->mmc),
>> + "sdhci-caps", &dt_caps, 1);

But why not use device_property_read_u64()?

>>
>> v = ver ? *ver : sdhci_readw(host, SDHCI_HOST_VERSION);
>> host->version = (v & SDHCI_SPEC_VER_MASK) >> SDHCI_SPEC_VER_SHIFT;
>> --
>> 2.26.2
>>

2020-11-25 02:08:53

by Ulf Hansson

[permalink] [raw]
Subject: Re: [PATCH] mmc: sdhci: Update firmware interface API

On Sat, 21 Nov 2020 at 00:39, Jeremy Linton <[email protected]> wrote:
>
> The device_* calls were added a few years ago to abstract
> DT/ACPI/fwnode firmware interfaces. Lets convert the two
> sdhci caps fields to use the generic calls rather than the OF
> specific ones. This has the side effect of allowing
> ACPI based devices to quirk themselves when the caps field
> is broken.
>
> Signed-off-by: Jeremy Linton <[email protected]>

Applied for next, thanks!

Kind regards
Uffe


> ---
> drivers/mmc/host/sdhci.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 592a55a34b58..feba64fbde16 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -3992,10 +3992,10 @@ void __sdhci_read_caps(struct sdhci_host *host, const u16 *ver,
> if (host->v4_mode)
> sdhci_do_enable_v4_mode(host);
>
> - of_property_read_u64(mmc_dev(host->mmc)->of_node,
> - "sdhci-caps-mask", &dt_caps_mask);
> - of_property_read_u64(mmc_dev(host->mmc)->of_node,
> - "sdhci-caps", &dt_caps);
> + device_property_read_u64_array(mmc_dev(host->mmc),
> + "sdhci-caps-mask", &dt_caps_mask, 1);
> + device_property_read_u64_array(mmc_dev(host->mmc),
> + "sdhci-caps", &dt_caps, 1);
>
> v = ver ? *ver : sdhci_readw(host, SDHCI_HOST_VERSION);
> host->version = (v & SDHCI_SPEC_VER_MASK) >> SDHCI_SPEC_VER_SHIFT;
> --
> 2.26.2
>

2020-11-25 04:03:58

by Jeremy Linton

[permalink] [raw]
Subject: Re: [PATCH] mmc: sdhci: Update firmware interface API

Hi,

On 11/24/20 8:51 AM, Adrian Hunter wrote:
> On 24/11/20 4:25 pm, Ulf Hansson wrote:
>> On Sat, 21 Nov 2020 at 00:39, Jeremy Linton <[email protected]> wrote:
>>>
>>> The device_* calls were added a few years ago to abstract
>>> DT/ACPI/fwnode firmware interfaces. Lets convert the two
>>> sdhci caps fields to use the generic calls rather than the OF
>>> specific ones. This has the side effect of allowing
>>> ACPI based devices to quirk themselves when the caps field
>>> is broken.
>>>
>>> Signed-off-by: Jeremy Linton <[email protected]>
>>
>> Applied for next, thanks!
>>
>> Kind regards
>> Uffe
>>
>>
>>> ---
>>> drivers/mmc/host/sdhci.c | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index 592a55a34b58..feba64fbde16 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -3992,10 +3992,10 @@ void __sdhci_read_caps(struct sdhci_host *host, const u16 *ver,
>>> if (host->v4_mode)
>>> sdhci_do_enable_v4_mode(host);
>>>
>>> - of_property_read_u64(mmc_dev(host->mmc)->of_node,
>>> - "sdhci-caps-mask", &dt_caps_mask);
>>> - of_property_read_u64(mmc_dev(host->mmc)->of_node,
>>> - "sdhci-caps", &dt_caps);
>>> + device_property_read_u64_array(mmc_dev(host->mmc),
>>> + "sdhci-caps-mask", &dt_caps_mask, 1);
>>> + device_property_read_u64_array(mmc_dev(host->mmc),
>>> + "sdhci-caps", &dt_caps, 1);
>
> But why not use device_property_read_u64()?

That would be more concise in this case.

I will post and update.

Thanks,