linux-kernel - Re: [RFC][PATCH] MMC: Use write timeout value as read from CSR

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-next>] [day] [month] [year] [list]

Message-ID: <5ff4a1e50809150224o600fd9fhb29e986bdb618464@mail.gmail.com>
Date:	Mon, 15 Sep 2008 10:24:22 +0100
From:	"Matt Fleming" <mattjfleming@...glemail.com>
To:	"Pierre Ossman" <drzeus-mmc@...eus.cx>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] MMC: Use write timeout value as read from CSR

2008/9/15 Pierre Ossman <drzeus-mmc@...eus.cx>:
> On Mon, 15 Sep 2008 09:03:41 +0100
> "Matt Fleming" <mattjfleming@...glemail.com> wrote:
>
>> Yeah it does, but the card pointer isn't copied to host->card. That
>> was the point I was trying to make above.
>
> I understood that, but you shouldn't be using host->card to begin with.
> Host drivers shouldn't be concerned with card specifics at all as the
> logic can sometimes be quite complex. All information the host drivers
> need should be in the request structure. If it isn't, then we need to
> fix the request structure, not change the drivers to start poking
> deeper into the MMC stack.
>

OK, I can see your point here. However, this is a completely different
change to my original patch. Would it not make more sense to queue my
original patch and then for me to write some patches to move all the
timeout info into the request structure?

> Looking further at the specs, this needs to be handled int the caller
> (i.e. mmc_send_cid() and mmc_send_csd()). The specs specify the
> timeouts used for those commands and they are actually different from
> the timeouts used elsewhere. IOW this could not be properly handled in
> some generic helper.
>

Again, this is a good idea but a different change to the patch I wrote
originally.

So, what I propose is this. Could you please queue my bug fix (I can
send the two patches again) and then I will begin working on the
generic patches to fix the issues that you've raised in this thread?
How does that sound?
--
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/