Hi,
On Tue, Jul 31 2012, merez@xxxxxxxxxxxxxx wrote:
>>> 512 byte stack? Isn't it really a problem?
>> How about this?
>>
>> +int mmc_read_bkops_status(struct mmc_card *card)
>> +{
>> + int err;
>> + u8 *ext_csd;
>> +
>> + ext_csd = kmalloc(512, GFP_KERNEL);
>> + if (!ext_csd) {
>> + pr_err("%s: could not allocate a buffer to "
>> + "receive the ext_csd.\n", mmc_hostname(card->host));
>> + return -ENOMEM;
>> + }
>> +
>> + mmc_claim_host(card->host);
>> + err = mmc_send_ext_csd(card, ext_csd);
>> + mmc_release_host(card->host);
>> + if (err)
>> + goto out;
>> +
>> + card->ext_csd.raw_bkops_status = ext_csd[EXT_CSD_BKOPS_STATUS];
>> + card->ext_csd.raw_exception_status = ext_csd[EXT_CSD_EXP_EVENTS_STATUS];
>> +out:
>> + kfree(ext_csd);
>> + return err;
>> +}
>> +EXPORT_SYMBOL(mmc_read_bkops_status);
>
> I'm not sure it would be a good idea to allocate the buffer every time the
> ext_csd is read since with the periodic BKOPs we might do it more often to
> see if there is a need for BKOPs.
> How about keeping the buffer in the card structure?
It's a little large for that, but it would be worth it if we really do
use it regularly. Perhaps go with the kmalloc option for now, add a
comment explaining that we should consider storing the entire ext_csd
in mmc_card later, and revisit it when the periodic bkops support is
submitted and we know how often we need to read the status?
Thanks,
- Chris.
--
Chris Ball <cjb@xxxxxxxxxx> <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
