linux-kernel - Re: [RFC PATCH v3 1/3] mmc: sprd: Add MMC host driver for Spreadtrum SoC

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: <CAPDyKFp2o=RAnizGrWgt080kYqWkBabh6NsCR11q3SPVCfaBAw@mail.gmail.com>
Date:	Thu, 8 Oct 2015 15:54:42 +0200
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Hongtao Wu <wuht06@...il.com>
Cc:	linux-mmc <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Paweł Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Shawn Lin <shawn.lin@...k-chips.com>,
	"Orson.Zhai@...eadtrum.com" <Orson.Zhai@...eadtrum.com>,
	"Chunyan.Zhang@...eadtrum.com" <Chunyan.Zhang@...eadtrum.com>,
	"Jason.Wu@...eadtrum.com" <Jason.Wu@...eadtrum.com>,
	Russell King <rmk+kernel@....linux.org.uk>
Subject: Re: [RFC PATCH v3 1/3] mmc: sprd: Add MMC host driver for Spreadtrum SoC

[...]

>> Thanks for clarifying!
>>
>> You have some differences towards the "standard" sdhci variant, but
>> that doesn't mean you should go off and implement a new driver from
>> scratch, instead you should create a new sdhci variant and re-use code
>> from the generic sdhci driver.
>>
>> The current problem with such approach, is that the sdhci driver isn't
>> designed as a library but instead a driver consisting of too many
>> quirks and callbacks. While you start to adopt your driver towards
>> sdhci, you will need to add yet another bunch of new quirks and
>> callbacks to suite your hw.
>>
>> Now, as the number of callbacks and quirks continues to increase I
>> will sooner or later give up maintaining it, as each line of code will
>> depend on a quirk. So, we need to start turning sdhci into a library
>> *right now*! Russell King, has pointed out this several times as well,
>> but unfortunate I haven't yet seen anyone willing to help out in this
>> field.
>>
>> I would of course be very happy if you would like to have a look at
>> that, but I realize it's a difficult task, So, unless you are happy
>> with taking on such a challenge, I suggest you go for an intermediate
>> step, which thus means convert your driver to a sdhci variant driver
>> and add the quirks/callbacks you need to suite your hw.
>>
>> [...]
>>
>> Kind regards
>> Uffe
>
> Thanks for kindly suggestion!
> I think it's a good idea to turn sdhci into a library. But for me it's
> too difficult to
> take on such a challenge. However, I will try my best to support you to do
> it.

Yes, I totally understand and thanks for your support.

>
> As you suggested, I will consider converting our eMMC host driver to a
> sdhci variant driver. However, our controller has some features, which
> differentiate it from standard sd host controller. For example, our controller
> doesn't have such functions as follows: tuning or re-tuning, Power Control
> Register, PIO or ADMA transfer mode, UHS-II and so on. So, if we use sdchi
> variant driver right now, I think it has a litter redundancy.

I realize that, but I would very much appreciate if you give it try -
I think it should be doable.

Of course, you will need to change the "sdhci core" to suite your
needs and normally people do that via adding callbacks and quirks.
Perhaps you can keep my request in mind of turning sdhci into a
library and thus limit the number of added quirks and callbacks...

>
> Now our sdio team are discussing improving  our eMMC host controller, we are
> making it more standardized. But you know, changing a IP block is a long
> process. Maybe it will take us about one or two years. So what do you think
> if we use ourself eMMC host driver right now, and convert it when our new host
> controller is ready.
>

Well, that won't help the current HW so I would encourage you to do
the "sdhci variant" work anyway. Likely it will also benefit you when
you try to upstream the next variant of the driver to cope with your
new HW.

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/