Skip to contentSkip to conversation

IDE code

DISCUSSION Ian Molton 2 participants 2 messages Jan 14, 2002

lore
Share & tools
lore

Ian Molton

author
#0 lore raw

Hi.

in the ide code the functions ide_[input|output]_data() seem to have become polluted by a test for a 'helper function' to be used to read data instead of inb() and friends.

It is my opinion that the functions should not have the test and subroutine, as it violates the 'layering' in that they no longer just 'get the data' but now also test for ... etc. blah blah.

I propose that we should be using the already existing function pointers to allow the CALLERS of ide_[input|output]_data() to perform the condition, and branch if appropriate to a driver provided alternative function.

This would mean replacing the handful (literally) of ide_input_data() and ide_output_data() calls with a macro (say, IDE_INPUT_DATA()) which performs the condition, or, if not needed, can be defined away as a straight call to ide_input_data() etc.

As the writer of an ide card driver that needs this functionality (it uses a multiply mapped register concept on ARM hardware to take advantage of its multiple load/store instructions for PIO (the hardware cannot do DMA, its 15 years old :)), I would appreciate input on wether or not anyone else feels this change should / should not be made?

#1 lore raw
Quoted 3 lines · Ian Molton

in the ide code the functions ide_[input|output]_data() seem to have become polluted by a test for a 'helper function' to be used to read data instead of inb() and friends.

I made that change, and I thought about letting the caller check it, but this was a much cleaner way to fix it overall given that it needed to go in the 2.4 stable series. Actually, the caller having to check driver details is not very nice at all. It has to do this for the dmaproc because the DMA and PIO modes are fundamentally different, but in this case it's probably better if the caller does not have to bother.

Now, what is lacking in the current implementation is that the caller should use the hw ptr directly instead of first calling the ide_xx_data which subsequently checks for an override, and ide_xx_data could be put as default in that ptr. But that would require changing in a lot of places in a very mission critical piece of code - it can be fixed during 2.5 of course.

Quoted 5 lines

As the writer of an ide card driver that needs this functionality (it uses a multiply mapped register concept on ARM hardware to take advantage of its multiple load/store instructions for PIO (the hardware cannot do DMA, its 15 years old :)), I would appreciate input on wether or not anyone else feels this change should / should not be made?

In what way, exactly, does the current mechanism stop you from doing this?

/BW