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]
Message-ID: <CAPDyKFr3oh9HcExn4Sx0Cd2e0oBTsxz+L4tDvypRFP8=hQP=cg@mail.gmail.com>
Date:   Thu, 31 Oct 2019 17:23:40 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     BenoƮt Cousson <bcousson@...libre.com>,
        Tony Lindgren <tony@...mide.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Russell King <linux@...linux.org.uk>,
        Kalle Valo <kvalo@...eaurora.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        David Sterba <dsterba@...e.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Petr Mladek <pmladek@...e.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Kefeng Wang <wangkefeng.wang@...wei.com>,
        Yangtao Li <tiny.windzz@...il.com>,
        Alexios Zavras <alexios.zavras@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Allison Randal <allison@...utok.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        John Stultz <john.stultz@...aro.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        linux-omap <linux-omap@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, kernel@...a-handheld.com,
        "# 4.0+" <stable@...r.kernel.org>
Subject: Re: [PATCH v2 04/11] mmc: host: omap_hsmmc: add code for special init
 of wl1251 to get rid of pandora_wl1251_init_card

On Wed, 30 Oct 2019 at 18:25, H. Nikolaus Schaller <hns@...delico.com> wrote:
>
> Hi Ulf,
>
> > Am 30.10.2019 um 16:51 schrieb Ulf Hansson <ulf.hansson@...aro.org>:
> >
> >> +
> >> +               np = of_get_compatible_child(np, "ti,wl1251");
> >> +               if (np) {
> >> +                       /*
> >> +                        * We have TI wl1251 attached to MMC3. Pass this information to
> >> +                        * SDIO core because it can't be probed by normal methods.
> >> +                        */
> >> +
> >> +                       dev_info(host->dev, "found wl1251\n");
> >> +                       card->quirks |= MMC_QUIRK_NONSTD_SDIO;
> >> +                       card->cccr.wide_bus = 1;
> >> +                       card->cis.vendor = 0x104c;
> >> +                       card->cis.device = 0x9066;
> >> +                       card->cis.blksize = 512;
> >> +                       card->cis.max_dtr = 24000000;
> >> +                       card->ocr = 0x80;
> >
> > These things should really be figured out by the mmc core during SDIO
> > card initialization itself, not via the host ops ->init_card()
> > callback. That is just poor hack, which in the long run should go
> > away.
>
> Yes, I agree.
>
> But I am just the poor guy who is trying to fix really broken code with
> as low effort as possible.

I see. Thanks for looking at this mess!

In general, as long as we improve the code, I am happy to move forward.

However, my main concern at this point, is to make sure we get the DT
bindings and the DTS files updated correctly. We don't want to come
back to this again.

>
> I don't even have a significant clue what this code is exactly doing and what
> the magic values mean. They were setup by pandora_wl1251_init_card() in the
> same way so that I have just moved the code here and make it called in (almost)
> the same situation.

Okay!

>
> > Moreover, I think we should add a subnode to the host node in the DT,
> > to describe the embedded SDIO card, rather than parsing the subnode
> > for the SDIO func - as that seems wrong to me.
>
> You mean a second subnode?
>
> The wl1251 is the child node of the mmc node and describes the SDIO card.
> We just check if it is a wl1251 or e.g. wl1837 or something else or even
> no child.

The reason why I brought this up, was because there are sometimes
cases where an SDIO card is shared between more than one SDIO func.
WiFi+Bluetooth for example, but if I am correct, that is not the case
for wl1251?

That said, I am happy to continue with your approach.

>
> > To add a subnode for the SDIO card, we already have a binding that I
> > think we should extend. Please have a look at
> > Documentation/devicetree/bindings/mmc/mmc-card.txt.
> >
> > If you want an example of how to implement this for your case, do a
> > git grep "broken-hpi" in the driver/mmc/core/, I think it will tell
> > you more of what I have in mind.
>
> So while I agree that it should be improved in the long run, we should
> IMHO fix the hack first (broken since v4.9!), even if it remains a hack
> for now. Improving this part seems to be quite independent and focussed
> on the mmc subsystem, while the other patches involve other subsystems.

I agree.

>
> Maybe should we make a REVISIT note in the code? Or add something to
> the commit message about the idea how it should be done right?

Just add a note that we should move this DT parsing of the subnode to
the mmc core, but that we are leaving that as a future improvement.
That's good enough. Then I can have a look as a second step, and when
I get some time, to move this to the mmc core.

However, there is one thing I would like you to add to the series. That is:

In the struct omap_hsmmc_platform_data, there is an ->init_card()
callback. Beyond the changes of this series, there is no longer any
users of that, unless I am mistaken. Going forward, let's make sure it
doesn't get used again, so can you please remove it!?

[...]

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ