On Tue, 11 Jun 2013 11:24:49 +0200
Linus Walleij wrote:
>
> Hm a significant portion of this patch set hits code which has not
> been touched since Pierre Ossman wrote the first MMC code.
> E.g. patch 1.
In the spirit of giving credit where credit is due, the MMC code
existed long
#x27;s more or less by convention. ETIMEDOUT is the closest thing we have
to "we expected a response from the card but got bupkis". You can find
some informal definitions here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/mmc/core.h;h=b6718e
guess there's no more testing we can do so I'll merge it?
Sounds reasonable. Although the question is if anyone has -mm on a
system which lacks slot power control. :)
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by FRA, a
Swedish intelligence age
an, valid, end*/
>
> +}
>
> +
>
> desc += 8;
>
>
>
> /*
>
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
>
> index ce5f1d7..2fa8245 100644
>
> --- a/drivers/mmc/host/sdhci.h
>
> +
should all be using the same init sequence. If there isn't a single
frequency where all cards will work, then we'll have to make something
more advanced where the kernel will try the init several times with
different clocking.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence
intermediate value
each time? I.e. halvway between 400 and 100 for now (250). If that is
too fast, then halway between that and 100 (175), and so on.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by FRA, a
Swedish intelligence agency. Make sure your server uses
k, although it would certainly be safer that way.
>
The hardware driver layer can only check if it's the same device being
plugged in, not if someone has done something with it during suspend,
so I see no other way than solving this in the filesystem layer.
Rgds
--
-- Pierre Ossman
that the kernel needs to umount/mount
around suspend in a way that's transparent to users of the filesystem.
Until we have such a system in place then everything will be hacks
which only shift around the problem.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being mo
; enumerated, have a hook for per-card fixups. For the particular
> non-standard card in question, this would then reduce the voltage to 1.8V.
>
In theory. But it would require a bit of redesign of the code as it
would have to restart the whole init again.
Rgds
--
-- Pierre Ossman
WA
vger.kernel.org/msg00386.html) ?
>
Since this is out-of-spec and therefore possibly dangerous behaviour,
I'd like it to be opt-in for the user. And since it's so early in the
init process, we can't automate it based on card id.
Rgds
--
-- Pierre Ossman
WARNING: This
On Tue, 29 Sep 2009 23:10:13 -0700
Philip Langdale wrote:
> On Tue, 29 Sep 2009 23:37:32 +0200
> Pierre Ossman wrote:
>
> > I must have missed that part of discussion. If the voltage fully
> > overlaps with the MMC definition, then I don't see the controllers
el/373855
>
> But no discussions being done on that thread since 2006. Is it because
> of the propitiatory nature or legal issues with the SD Organization?
>
Neither. It simply never got finished with regard to handling SD cards.
Rgds
--
-- Pierre Ossman
WARNING: This corresp
On Wed, 30 Sep 2009 15:23:09 -0700 (PDT)
Albert Herranz wrote:
> Pierre Ossman wrote:
> >
> > Anyway, my ideal solution would be something like this:
> >
> > - We start checking the type field in cistpl_funce. We already know
> >about types 0 and 1 (and n
he kernel? Userspace ABI stuff should be added with great care.
2. I think it's better to not show the attribute when it isn't relevant
rather than return 0xFF.
3. Isn't this a SD 2.0 feature? So you should check the version of the
card before populating/showing this field.
Rgds
-
They'd need to
make sure the card remains powered between inits to fully expose the
bug I saw.
PS. try to clear my @drzeus.cx addresses from your address books. They
will cease to function in the future.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by th
whip some sense into the line handling of your
email client. :)
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
signature.asc
Description: PGP signature
argins
already at the first attempt.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
signature.asc
Description: PGP signature
e can do is
interpret it as being the same as the MMC bit, but then only with an
opt-in configuration as we might be killing hardware with this.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses enc
al version, but this would
be the model that would make blissful. :)
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
signature.asc
Description: PGP signature
#define EXT_CSD_CARD_TYPE 196 /* RO */
> +#define EXT_CSD_STRUCT_REV 194 /* RO */
> #define EXT_CSD_REV192 /* RO */
> #define EXT_CSD_SEC_CNT212 /* RO, 4 bytes */
>
And this is just even more wrong. You're telling the stack to check the
ittle longer for in general.
>
> Signed-off-by: Chris Ball
> Cc: Harald Welte
> ---
Seems reasonable enough to me. The initial limit was completely
arbitrary anyway.
Acked-by: Pierre Ossman
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Sw
It _does_ check the card id when you have UNSAFE_RESUME selected. It
doesn't just hook up whatever card you happen to have in the slot with
your old block device. I may have a lot of opponents when it comes
to my suspend design choices, but I'm not completely crazy. ;)
Rgds
--
-- Pierre
On Mon, 7 Sep 2009 20:55:58 +0200
Michael Buesch wrote:
> On Monday 07 September 2009 20:47:12 Albert Herranz wrote:
> >
> >
>
> Please also submit to the SDIO maintainer.
>
There isn't one anymore, so submitting to this list is the correct
method.
R
nion.
No, as that would violate the spec and possibly misinterpret some cards
as high-capacity.
To handle your card you would have to build some kind of quirks system
so that the kernel can identify that this card is buggy and compensate
for it.
Rgds
--
-- Pierre Ossman
WARNING: This corres
been more threads over the years, but I'm afraid I don't
remember enough about them to find them again.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider us
Silencing a legitimate error.
> + if (ret == -EILSEQ) {
> + /* this tuple is unknown to the core */
Misleading comment, the tuple might be known but malformed.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
signature.asc
Description: PGP signature
struct mmc_host *host)
> +{
It might be clearer if you use the terminology from the spec, so either
sdio_abort() or sdio_reset().
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traf
laim is that doing so can break some filesystem drivers (notably
the journaling ones). There has been several threads and patches about
this in the past.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
7;s also the issue of e.g. having two "identical" wifi cards
but with different MAC addresses).
I think the right way to go is to retain enough power to the card for
it to stay initialised and then poke it at resume to see if it is still
running in the same state we left it.
Rgds
Remove myself as maintainer from the sdhci driver and steer people
towards the new MMC list for discussing it.
Signed-off-by: Pierre Ossman
---
I've noticed that people have already begun sending their sdhci patches
to Andrew, so this is more or less a formality at this point.
I won
oughts?
>
My guess would be that the omap driver doesn't (cannot?) use the
hardware to wait for busy to end, so the system must poll.
Anything better than that guess will require some profiling. :)
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedi
31 matches
Mail list logo
