[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8f9d6e07-6549-9b2e-a45b-f262b59bfe5f@linaro.org>
Date: Mon, 23 Jan 2023 08:55:40 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>,
linux-renesas-soc@...r.kernel.org,
Prabhakar <prabhakar.csengg@...il.com>,
Sergey Shtylyov <s.shtylyov@....ru>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] memory: renesas-rpc-if: Fix PHYCNT.STRTIM setting
On 23/01/2023 07:58, Wolfram Sang wrote:
> Hi Krzysztof,
>
>>> +static const struct soc_device_attribute rpcif_info_match[] = {
>>> + { .soc_id = "r8a7795", .revision = "ES1.*", .data = &rpcif_info_r8a7795_es1 },
>>> + { .soc_id = "r8a7796", .revision = "ES1.*", .data = &rpcif_info_r8a7796_es1 },
>>
>> Why do you need soc match? Can't this be inferred from device
>> compatible? Maybe the device compatible is not specific enough? Devices
>> should not be interested in which SoC they are running - it does not
>> matter for them, because the device difference is in the device itself,
>> not in the SoC (different SoCs come with different devices).
>
> I need it because of ".revision". This only applies to "ES1.*",
> there are "ES2.*" and "ES3.*" around which have the same SoC number.
> Also, there is usually no version numbering for the IP core. We need to
> use this scheme in a number of other places already, sadly.
I did not get whether this is runtime characteristics or it can be
customized with compatible (just you did not do it)?
Best regards,
Krzysztof
Powered by blists - more mailing lists