BTW, for a solution to be complete, we need to halt all work on all
other ports, when issuing SET FEATURES - XFER MODE. On SiI and Promise
controllers, possibly others, the command is snooped and side effects
such as register setting occur.
Long standing to-do. Currently we hack around this
Alan wrote:
> O> Wouldn't it be better to have ->determine_xfer_mask() and
>> ->set_specific_mode() than having two somewhat overlapping callbacks?
>> Or is there some problem that can't be handled that way?
>
> I'm not sure I follow what you are suggesting - can you explain further.
>
> Right no
O> Wouldn't it be better to have ->determine_xfer_mask() and
> ->set_specific_mode() than having two somewhat overlapping callbacks?
> Or is there some problem that can't be handled that way?
I'm not sure I follow what you are suggesting - can you explain further.
Right now ->set_mode does all th
Alan wrote:
> I'm currently hacking on the speed handling code a bit
>
> I'd like to do the following unless anyone has any objections
>
> - Remove post_set_mode and make drivers wrap the guts of the existing
> set_mode() function. This allows a driver to wrap and see success/failure
> while remo
I'm currently hacking on the speed handling code a bit
I'd like to do the following unless anyone has any objections
- Remove post_set_mode and make drivers wrap the guts of the existing
set_mode() function. This allows a driver to wrap and see success/failure
while removing a callback, and also
5 matches
Mail list logo
