From: Oliver Hartkopp <socketcan@hartkopp.net>
To: s.grosjean@peak-system.com
Cc: Sam Ravnborg <sam.ravnborg@gmail.com>,
"Maidhof, Michael" <m.maidhof@peak-system.com>,
linux-can@vger.kernel.org,
"Uwe Wilhelm (PEAK-System)" <u.wilhelm@peak-system.com>
Subject: Re: WG: PCAN-USB: new socketCAN driver available
Date: Wed, 07 Dec 2011 12:15:04 +0100 [thread overview]
Message-ID: <4EDF4AB8.6060502@hartkopp.net> (raw)
In-Reply-To: <4EDF3FF3.80302@peak-system.com>
On 07.12.2011 11:29, Grosjean Stephane wrote:
> Hi,
>
> First of all, thank you for your time and all your comments.
>
> Le 06/12/2011 22:24, Oliver Hartkopp a écrit :
>> On 06.12.2011 21:47, Sam Ravnborg wrote:
>>
>>> Today it is really recommended to do:
>>>
>>> obj-$(CONFIG_CAN_PEAK_USB) += peak_usb.o
>>> peak_usb-y := pcan_usb_core.o pcan_usb.o
>>>
>>> obj-$(CONFIG_CAN_PEAK_USB_PRO) += peak_usb_pro.o
>>> peak_usb_pro-y := pcan_usb_core.o pcan_usb_pro.o
>>>
>>> Both solutions will work - but the latter allows for some nice
>>> "kbuild" assignments to conditional stuff.
>>>
>
> right...
>
>> I just tried out the suggestion myself ...
>>
>> As my idea was to link the common functions directly to the module binary this
>> may double the needed size. Maybe your approach is really better 8-)
>>
>> But the fact that the select should be omitted is still true.
>>
>> Better you define a
>>
>> config CAN_PEAK_USB
>> tristate "PEAK System USB adapters"
>>
>> and then
>>
>> config CAN_PCAN_USB
>> tristate "PEAK PCAN USB adapter"
>> depends on CAN_PEAK_USB
>>
>>
>> config CAN_PCAN_USB_PRO
>> tristate "PEAK PCAN USB Pro adapter"
>> depends on CAN_PEAK_USB
>>
>> ...
>>
>> Regards,
>> Oliver
>
> I thought this was better for memory size and also for easier handling of
> (any) further PEAK USB adapter, never know...
> But, what next? According to your below Kconfig and Sam's Kbuild, and if I
> understand well your suggestions, the Kbuild file always builds 2 module
> files, while I wanted to build only a single one, capable of handling one or
> both adapters.
Ah, ok. I formerly thought that you plan to have three separated kernel
modules (core, usb, usbpro) - but i just checked that you only create a
peak_usb.ko which is perfectly fine.
> Please, confirm that a mainline kernel driver should (must?) handle one and
> only one kind of device.
No. If your driver supports "PEAK PCAN USB / USB Pro adapters" you can put
this into a single Kconfig entry and build a single peak_usb.ko if you like.
I don't know whether it's worth the effort to build separate drivers and
kernel modules. The current code has some space for improvements and cleanups :-)
When you're finished your work with the USB Pro it's time to post it on
linux-can ML and the we can discuss together how the sources and the driver
should be packaged best.
Post early & often :-)
> If it should (must), I will modify the Kbuild file as proposed by Sam, in
> order to build a peak_usb.ko and/or a peak_usb_pro.ko file.
This was just a suggestion.
>
> But in that case, I wonder why the Kernel API offers some data structures like
> "struct usb_driver.id_table" which are supposed to describe more than one
> device id.
Yes you can do that also (as written above).
Regards,
Oliver
prev parent reply other threads:[~2011-12-07 11:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4E400A36.5050303@hartkopp.net>
[not found] ` <A46279271E5345AC9BFA91C73DF57228@DA310MM05>
[not found] ` <4E415AB2.5030102@hartkopp.net>
[not found] ` <2CD045C79786404EA0A81CED1E59763D@DA310MM05>
[not found] ` <4E4BFF24.2010508@hartkopp.net>
[not found] ` <33575A72304940CE9103338BA3660CEA@DA310MM05>
[not found] ` <26B4E6A46012A1469B4EB3BC2A7CAAEC01266CCC@vwagwox00084.vw.vwg>
[not found] ` <4EC6597A.8040704@peak-system.com>
[not found] ` <4EC6B080.8090808@hartkopp.net>
[not found] ` <4ECB65D8.7050207@peak-system.com>
[not found] ` <4ECB8E75.7@volkswagen.de>
[not found] ` <4ECBAAFB.8080204@peak-system.com>
[not found] ` <4ECBAE4E.8000502@volkswagen.de>
[not found] ` <4ECBB49A.2020508@volkswagen.de>
[not found] ` <4ED3B355.70209@peak-system.com>
[not found] ` <26B4E6A46012A1469B4EB3BC2A7CAAECE55502@vwagwox00084.vw.vwg>
[not found] ` <4ED3CC05.6060606@hartkopp.net>
[not found] ` <4ED4AF93.8060309@peak-system.com>
2011-11-29 10:39 ` WG: PCAN-USB: new socketCAN driver available Wolfgang Grandegger
2011-11-29 10:43 ` Marc Kleine-Budde
2011-12-06 19:49 ` Oliver Hartkopp
2011-12-06 20:40 ` Oliver Hartkopp
2011-12-09 13:47 ` PEAK CAN USB driver v0.4.0 Grosjean Stephane
2011-12-06 20:47 ` WG: PCAN-USB: new socketCAN driver available Sam Ravnborg
2011-12-06 21:24 ` Oliver Hartkopp
2011-12-07 10:29 ` Grosjean Stephane
2011-12-07 11:15 ` Oliver Hartkopp [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EDF4AB8.6060502@hartkopp.net \
--to=socketcan@hartkopp.net \
--cc=linux-can@vger.kernel.org \
--cc=m.maidhof@peak-system.com \
--cc=s.grosjean@peak-system.com \
--cc=sam.ravnborg@gmail.com \
--cc=u.wilhelm@peak-system.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.