Wolfgang Grandegger wrote:
> Matthias Fuchs wrote:
>> Hi Wolfgang,
>> On Tuesday 12 September 2006 14:22, Wolfgang Grandegger wrote:
>>> What about using request_mem_region()? While looking to the driver I now 
>> ... will be added, of course.
>>> realize, that it's mainly duplicated code. Does it not make more
>>> sense to make a combined io/mem driver. If io address < 32K it's an
>>> io driver
>>> else a mem driver.
>> Yes, that's possible. We can also decide on the used module parameter
>> (mem or io) what is to do. Passing both results in an error.
>> You are right that its duplicated code. But the driver is very simple.
>> It nearly does nothing but mapping, implementing register access
>> callbacks, registering and cleanup when unloading. But the driver
>> differs in all these points from the isa/io colleague. I like shot an
>> simple drivers, so that you do not have to care about breaking the
>> isa/io part when modifying the mem part.
>>>> There's one thing a I am not very satisfied with :-) Why passing
>>>> half of 
>> the
>>>> external clock frequency to the module. Because of compatiblity
>>>> reasons I kept this behavior of the clock paramter from the ISA driver.
>>> The attached patch fixes this and replaces the module parameter "isa"
>>> with "io". I also tend to rename the driver into rtcan_io instead
>>> rtcan_isa if we keep it.
>> Sounds good.
> Jan, could you apply this patch to avoid further confusion? The real CAN
> clock frequency listed also in the proc file system is half of the
> oscillator clock. Some more doc might help to avoid further confusion.

Done (with minor modification to avoid compiler warning).


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to