Thread (28 messages) 28 messages, 7 authors, 2012-06-12

Re: [PATCH RFC] c_can_pci: generic module for c_can on PCI

From: Alessandro Rubini <hidden>
Date: 2012-06-11 14:23:35
Also in: lkml, netdev

quoted
In my opinion, it would be much better to have one less layer and no
exports at all. The core driver should be a platform driver, and the
pci driver would just build platform data and register the platform
device.
Do you have examples for that approach? Not sure yet if it really saves
code and makes it more readable.
Maybe the physmap mtd driver is a good example. Everybody's using it
(but not from PCI). I found drivers/pcmcia/bcm63xx_pcmcia.c that
registers a platform driver from a pci probe function, but I'm sure
there are other ones.

OTOH, I have another example of how not to do stuff, but I won't point
fingers now (it's not a CAN thing).

I just think the platform bus is there just for this reason: to provide
data to a generic driver, without module dependencies and such stuff. 
I would suggest to provide the c_can_pci driver using the *current* API,
even if it's not optimal. Federicos patch then already looks quite good.
It should use the new register access methods introduced by the D_CAN
support patch, though.
Great. When it's in I'll show my proposal as an RFC patch, as time permits,
so we'll see if it's better or not.
Any further improvements to the device abstraction and a more consistent
handling of the platform data are welcome.
Good to know, thanks a lot

/alessandro
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help