linux-kernel - Re: [PATCH 09/11] mmc: sdhci-cadence: Add Pensando Elba SoC support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 7 Apr 2022 10:13:21 +0300
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Arnd Bergmann <arnd@...db.de>, Brad Larson <brad@...sando.io>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Mark Brown <broonie@...nel.org>,
        Serge Semin <fancer.lancer@...il.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Olof Johansson <olof@...om.net>, dac2@...sando.io,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 09/11] mmc: sdhci-cadence: Add Pensando Elba SoC support

On 07/04/2022 9.45, Arnd Bergmann wrote:
> On Thu, Apr 7, 2022 at 1:36 AM Brad Larson <brad@...sando.io> wrote:
>> @@ -350,7 +461,7 @@ static void sdhci_cdns_hs400_enhanced_strobe(struct mmc_host *mmc,
>>  static int sdhci_cdns_probe(struct platform_device *pdev)
>>  {
>>         struct sdhci_host *host;
>> -       const struct sdhci_pltfm_data *data;
>> +       const struct sdhci_cdns_drv_data *data;
>>         struct sdhci_pltfm_host *pltfm_host;
>>         struct sdhci_cdns_priv *priv;
>>         struct clk *clk;
>> @@ -369,10 +480,10 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
>>
>>         data = of_device_get_match_data(dev);
>>         if (!data)
>> -               data = &sdhci_cdns_pltfm_data;
>> +               data = &sdhci_cdns_drv_data;
>>
>>         nr_phy_params = sdhci_cdns_phy_param_count(dev->of_node);
>> -       host = sdhci_pltfm_init(pdev, data,
>> +       host = sdhci_pltfm_init(pdev, &data->pltfm_data,
>>                                 struct_size(priv, phy_params, nr_phy_params));
>>         if (IS_ERR(host)) {
>>                 ret = PTR_ERR(host);
>> @@ -389,6 +500,11 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
>>         host->ioaddr += SDHCI_CDNS_SRS_BASE;
>>         host->mmc_host_ops.hs400_enhanced_strobe =
>>                                 sdhci_cdns_hs400_enhanced_strobe;
>> +       if (data->init) {
>> +               ret = data->init(pdev);
>> +               if (ret)
>> +                       goto free;
>> +       }
>>         sdhci_enable_v4_mode(host);
>>         __sdhci_read_caps(host, &version, NULL, NULL);
> 
> I'm not sure about the abstraction here. The approach of having a single
> driver with some platform specific quirks like you do here works fine if the
> differences between hardware implementations are fairly minor, but if there
> are a larger number of variants, or the differences become too big, the
> better approach is to have separate top-level driver instances that call
> into a more generic driver, continuing the call chain
> 
> elba_drv_init()
>  -> sdhci_cdns_probe()
>      -> sdhci_pltfm_init()
>          -> sdhci_add_host()
>              -> mmc_add_host()
> 
> with each one being a more specific version of the one below it.
> At the moment, it doesn't quite require having a custom driver,
> but I fear that it it would get hard to rework if it continues to grow
> other front-ends. It may be better to do the abstraction right away,
> even if the elba driver becomes rather trivial.
> 
> Ulf, any preferences?
> 

What is the relationship between cadence and pensando elba?