Dean Matsen wrote: > > Wolfgang Denk wrote: > >> In message <3F0C6C0C.8040306 at earthlink.net> you wrote: >> >> >>>> Solution? What is so difficult about latching your output value in a >>>> variable? >>>> >>>> >>>> >>> What he's saying is that OTHER drivers read the input and then write >>> that value to the output. >>> >>> >> >> I did understand this. >> >> >> >>> In his driver, he can latch the output through a variable, but that >>> won't affect what other >>> >>> >> >> Obviously all drivers that may modify bits in this I/O port will have >> to share the variable used to latch the value. >> >> Yes, this may include modifying existing code in the UART or Ethernet >> or other drivers. >> >> >> >>> Unless there is kernel support to alias the data in a memory variable >>> (and it doesn't sound like >>> there is), then this is going to continue to be a problem. Might I >>> >>> >> >> Don't make it unnecessary complicated. You don't need "kernel support >> to alias the data in a memory variable". This is really not so >> difficult to implement yourself when you need it. >> >> >> Best regards, >> >> Wolfgang Denk >> >> >> > No no, I wasn't suggesting that it be added, I was (subtly) pointing out > that it is not likely to be added because you'd have to review every > other driver in the PPC system. Not gonna happen. > > But I still don't see how you could avoid having other drivers clobber > your output but. I think he has to take one of the two options I > suggested. Adding his own variable can't help in any way I can > imagine. Could you give an example? > > Dean > > > > Ooops, NM on the example -- I didn't read carefully enough. Yes, updating the other drivers would work too, but then he's got to maintain a ton of patches for his version of the kernel.
Dean ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
