Hi, On Tue, Jul 31 2012, [email protected] 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 <[email protected]> <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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
