Stephen Clark wrote:
Bill Davidsen wrote:
Stephen Clark wrote:
Bill Davidsen wrote:
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's ->mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I
Stephen Clark wrote:
Bill Davidsen wrote:
Stephen Clark wrote:
Bill Davidsen wrote:
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's -mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I
Bill Davidsen wrote:
Stephen Clark wrote:
Bill Davidsen wrote:
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's ->mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually
Stephen Clark wrote:
Bill Davidsen wrote:
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's ->mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the
Bill Davidsen wrote:
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's ->mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk can be
done
Bill Davidsen wrote:
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's -mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk can be
done
Stephen Clark wrote:
Bill Davidsen wrote:
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's -mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk
Bill Davidsen wrote:
Stephen Clark wrote:
Bill Davidsen wrote:
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's -mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's ->mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk can be
done correctly is for it to be the very
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's -mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk can be
done correctly is for it to be the very last
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's ->mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk can be
done correctly is for it to be the very
> it seems broken to manipulate xfer_mask after returning from the
> driver's ->mode_filter hook.
>
> this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk can be
done correctly is for it to be the very last test
Robert Hancock wrote:
Here's a revised version of my previous patch to warn the user if a
drive's transfer rate is limited because of a 40-wire cable detection.
This one hopefully addresses Alan's previous comments - we now do this
at the very end of the function, and the ugly if condition has
Robert Hancock wrote:
Here's a revised version of my previous patch to warn the user if a
drive's transfer rate is limited because of a 40-wire cable detection.
This one hopefully addresses Alan's previous comments - we now do this
at the very end of the function, and the ugly if condition has
it seems broken to manipulate xfer_mask after returning from the
driver's -mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk can be
done correctly is for it to be the very last test made.
Alan Cox wrote:
it seems broken to manipulate xfer_mask after returning from the
driver's -mode_filter hook.
this patch is more than just a speed-limited warning printk, afaics
I actually suggested that order because the only way the printk can be
done correctly is for it to be the very last
> cleaned up somewhat. Also, it's been inadvertently tested (it seems that
> pata_amd Nvidia cable detection is broken in current -git..)
Yes. The pata_acpi driver fixes that one, but got kicked out as it didn't
match other merges at the same time. It'll be back soon
>
> Signed-off-by: Robert
cleaned up somewhat. Also, it's been inadvertently tested (it seems that
pata_amd Nvidia cable detection is broken in current -git..)
Yes. The pata_acpi driver fixes that one, but got kicked out as it didn't
match other merges at the same time. It'll be back soon
Signed-off-by: Robert
Here's a revised version of my previous patch to warn the user if a
drive's transfer rate is limited because of a 40-wire cable detection.
This one hopefully addresses Alan's previous comments - we now do this
at the very end of the function, and the ugly if condition has been
cleaned up
Here's a revised version of my previous patch to warn the user if a
drive's transfer rate is limited because of a 40-wire cable detection.
This one hopefully addresses Alan's previous comments - we now do this
at the very end of the function, and the ugly if condition has been
cleaned up
20 matches
Mail list logo
