On Mon, Mar 7, 2011 at 2:39 PM, Andrei Warkentin <andr...@motorola.com> wrote: > On Mon, Mar 7, 2011 at 2:16 AM, Andrei Warkentin <andr...@motorola.com> wrote: >> On Sun, Mar 6, 2011 at 3:20 PM, Linus Walleij <linus.wall...@linaro.org> >> wrote: >>> 2011/3/6 Linus Walleij <linus.wall...@linaro.org>: >>>> 2011/3/5 Andrei Warkentin <andr...@motorola.com>: >>>> >>>>> Quirks are card-specific workarounds. Usually they involve >>>>> tuning mmcblk parameters at mmc_blk_probe time. >>>> >>>> Can't you just drop off all the *block* and *blk* pre- and >>>> suffixes off filenames and functions? >>>> >>>> It's inevitably going to be used for all kind of card quirks >>>> soon enough, not just those relating to block issues >>>> (could be power quirks etc) won't it? >>>> >>>> "Card quirks" is more intuitive to me. >>> >>> Or rather - if you check out Chris latest tree or the next >>> tree - you will find the new quirks.c file that Pierre Tardy >>> created for some SDIO quirks. >>> >>> Can you re-use this infrastructure and refactor/expand >>> with the quirks you need for the block stuff? >>> >>> Yours, >>> Linus Walleij >>> >> >> I'll check it out. I wish I looked earlier :-). >> >> A >> > > I took a look at quirks.c in linux-next. It's a bit sdio-specific... I > would extend mmc_fixup to contain card type (to know if cis > vendor/device should be checked) as well as name/manfid/oemid and rev > id (which is just a combination of hwrev, fwrev and date). > > Vendor_fixup would be the top-level card fixup. > I would add blk_fixup (so block specific information like desired > write align size can be kept inside mmc_blk_data instead of polluting > mmc_card). > > ...and to support part reliability workarounds for Toshiba cards, will > add a blk_adjust method to be invoked inside blk req handling. > > Arnd, what do you think? > > Pierre, what do you think about my above ideas of extending the > current quirks.c? Please see the following patches, which were my > original submissions... > http://article.gmane.org/gmane.linux.kernel.mmc/6468/match= > http://article.gmane.org/gmane.linux.kernel.mmc/6467/match= > http://article.gmane.org/gmane.linux.kernel.mmc/6469/match= > http://article.gmane.org/gmane.linux.kernel.mmc/6470/match= > http://article.gmane.org/gmane.linux.kernel.mmc/6466/match= > > Thanks, > A >
The other real issue I see is that it's kind of nasty to put block-related workarounds into core/quirks.c. The later seems more of generic card interface workarounds, rather than workarounds for specific functionality. It would be like putting workarounds for, say, sdio_uart into core/quirk.c, IMHO block workarounds are still function-level workarounds, and so should be dealt with at the function-level under mmc/card. Thoughts? Keep in mind also that for various emmc brokeness (from writing to erasing), there is an express need to be able to modify actual mmc commands during request processing, or base behavior on per-card tunables (which are block specific and shouldn't be in struct mmc_card). Can't get away with just setting a quirk flag... A -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
