On Tue, Mar 8, 2011 at 2:34 PM, Andrei Warkentin wrote:
> On Tue, Mar 8, 2011 at 2:28 PM, Linus Walleij
> wrote:
>> 2011/3/7 Andrei Warkentin :
>>
>>> 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
>>> generi
On Tue, Mar 8, 2011 at 2:28 PM, Linus Walleij wrote:
> 2011/3/7 Andrei Warkentin :
>
>> 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
>> specif
2011/3/7 Andrei Warkentin :
> 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, s
On Tue, Mar 8, 2011 at 8:42 AM, Arnd Bergmann wrote:
>
> I'm still not comfortable with having the blk_adjust method. I think it
> would be much better to encode that behavior in an abstract way in
> the block driver and set a flag to enable it in the quirks file.
Ok, will encode the behavior abs
On Monday 07 March 2011, Andrei Warkentin wrote:
>
> 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 hwr
> 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).
Feel free to change mmc_fixup.
On Mon, Mar 7, 2011 at 2:39 PM, Andrei Warkentin wrote:
> On Mon, Mar 7, 2011 at 2:16 AM, Andrei Warkentin wrote:
>> On Sun, Mar 6, 2011 at 3:20 PM, Linus Walleij
>> wrote:
>>> 2011/3/6 Linus Walleij :
2011/3/5 Andrei Warkentin :
> Quirks are card-specific workarounds. Usually the
On Mon, Mar 7, 2011 at 2:16 AM, Andrei Warkentin wrote:
> On Sun, Mar 6, 2011 at 3:20 PM, Linus Walleij
> wrote:
>> 2011/3/6 Linus Walleij :
>>> 2011/3/5 Andrei Warkentin :
>>>
Quirks are card-specific workarounds. Usually they involve
tuning mmcblk parameters at mmc_blk_probe time.
>>
On Sun, Mar 6, 2011 at 3:20 PM, Linus Walleij wrote:
> 2011/3/6 Linus Walleij :
>> 2011/3/5 Andrei Warkentin :
>>
>>> 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
>> s
2011/3/6 Linus Walleij :
> 2011/3/5 Andrei Warkentin :
>
>> 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
2011/3/5 Andrei Warkentin :
> 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
11 matches
Mail list logo