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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <920CFF1F-475C-4403-B563-DDD144F7E52D@goldelico.com>
Date:   Thu, 28 Oct 2021 11:43:43 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Jérôme Pouiller <jerome.pouiller@...abs.com>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Avri Altman <avri.altman@....com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bean Huo <beanhuo@...ron.com>, linux-mmc@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, kernel@...a-handheld.com,
        Tony Lindgren <tony@...mide.com>,
        Linux-OMAP <linux-omap@...r.kernel.org>
Subject: Re: [RFC] mmc: core: transplant ti,wl1251 quirks from to be retired
 omap_hsmmc



> Am 28.10.2021 um 11:40 schrieb H. Nikolaus Schaller <hns@...delico.com>:
> 
> Hi Jérôme,
> 
>> Am 28.10.2021 um 10:59 schrieb Jérôme Pouiller <jerome.pouiller@...abs.com>:
>> 
>> Hi Nikolaus,
>> 
>> On Thursday 28 October 2021 09:08:50 CEST H. Nikolaus Schaller wrote:
>> 
>>>> Let me have a closer look - and for sure, I am willing to help if needed.
>> 
>> I confirm it does not have the expected behavior. !mmc_fixup_of_compatible_match()
>> should be mmc_fixup_of_compatible_match(), sorry.
> 
> Ok, I see.
> 
> One more question: how can I specify "ti,wl1251" in some struct mmc_fixup table?
> Does it need another macro like MMC_FIXUP() or SDIO_FIXUP() to set the .name
> field?
> 
>>> 
>>> Combining your suggestions we could do roughly:
>>> 
>>> in mmc_sdio_init_card():
>>> 
>>>       if (host->ops->init_card)
>>>               host->ops->init_card(host, card);
>>>       else
>>>               mmc_fixup_device(host, sdio_prepare_fixups_methods);
>> 
>> I think I mostly agree, but why you don't call mmc_fixup_device() if
>> init_card is defined? (BTW, mmc_fixup_device() takes a card as
>> first parameter)
> 
> Because I want to get rid of init_card. It is host specific and not client
> specific.

Ah, on a second though we can do that independently. Either there is
some init_card - or something in the fixup tables. Why not both...
So the else clause is not needed.

And you are right, the first parameter should be card`.

> 
>> 
>> 
>>> Next we need a location for the sdio_prepare_fixups_methods table and functions.
>>> 
>>> For "ti,wl1251" we would then provide the entry in the table and a function doing
>>> the setup. But where should these be defined? Likely not in a header file like
>>> quirks.h? But there is no quirks.c.
>> 
>> I think you can place your function in drivers/mmc/core/card.h. There are
>> already add_quirk(), add_limit_rate_quirk(), add_quirk_mmc(), etc...
> 
> Ok. Would be some add_wl1251_quirk() then.
> 
> BR and thanks,
> Nikolaus
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ