CODEWITHSUNDEEP
armlinux-device-driverembedded-linuxatmel
Maus
Maus

Reputation: 2766

Linux device model: Same device but different drivers

I'm customising Linux for an ARM9 Atmel AT91SAM960 board.

In the device file Atmel named all the USART the same atmel_usart. Of course with id enumeration:

static struct platform_device at91sam9260_uart0_device = {
        .name           = "atmel_usart",
        .id             = 1,
        .dev            = { ...}
}

According to the Linux Device model, all these devices (5 UARTS on a SAM9260) would be bind to the driver named atmel_usart.

I don't want to set a TTYS driver on all UARTS which will be registerd. I have several own drivers which serve for different specialised purposes (LON, RS-485 etc.) I want the control which driver does serve a certain USART. So what could I do:

What solutions else exist. I want to touch a minimal set of Kernel files but I want all the freedom possible?

Addendum what freedom means to me: I can specify at runtime how the UARTS can be used

It means also, that changes to the kernel source are minimal.

Upvotes: 0

Views: 1419

Answers (2)

sleeves
sleeves

Reputation: 536

Your problem is quite easily solved. The 5 UART devices are presently registered at kernel startup and their function is locked. This is now how it normally works for PCI or USB devices, right? So what you need to do is pull the device registration out of the startup code and register it dynamically. You can even register/unregister as needed.

at91_register_uart() is being called from your board file for every UART that needs registered. at91_add_device_serial() will then platform_device_register all those you what setup. One solution is to let at91_register_uart() be called for all 5 UARTS, but then remove the call to at91_add_device_serial() from your board. You can then make it an exported function that can be called by your loadable drivers. You can even add an argument to it (int) so that instead of looping on all UARTS, you can select which ones to register individually. You can also mirror this function by making one that unregisters the devices.

NOTE: I think you'll need to always leave one UART dedicated as your console, if you are using one that way. You could probably hide that in the exported function by only allowing index 0->3 as in input and then mapping 0->3 to 0-4, skipping the UART that you want to use for console.

Upvotes: 0

Ian Howson
Ian Howson

Reputation: 683

I built my own line discipline drivers. You can build them as kernel modules and attach them to the UARTs at runtime. No changes to the Linux source are necessary.

Any funny timing or control stuff can be done through ioctl(). Specifically, I implemented a timing-sensitive RS-485 protocol in this way.

When I did this (Linux 2.6.17) there was no dynamic registration mechanism, so I overwrote the existing line disciplines. The Linux code is (was) pretty straightforward, and I was satisfied that this would be a safe thing to do.

Upvotes: 2

Related Questions