netdev - Re: [PATCH 3/3] can: at91_can: make can

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D2C4E2D.7050309@pengutronix.de>
Date:	Tue, 11 Jan 2011 13:33:49 +0100
From:	Marc Kleine-Budde <mkl@...gutronix.de>
To:	Wolfgang Grandegger <wg@...ndegger.com>
CC:	Socketcan-core@...ts.berlios.de, netdev@...r.kernel.org
Subject: Re: [PATCH 3/3] can: at91_can: make can_id of mailbox 0 configurable

On 01/11/2011 01:27 PM, Wolfgang Grandegger wrote:
> On 01/11/2011 12:56 PM, Marc Kleine-Budde wrote:
>> On 01/11/2011 12:45 PM, Wolfgang Grandegger wrote:
>>> On 01/11/2011 11:28 AM, Marc Kleine-Budde wrote:
>>>> Due to a chip bug (errata 50.2.6.3 & 50.3.5.3 in
>>>> "AT91SAM9263 Preliminary 6249H-ATARM-27-Jul-09") the contents of mailbox
>>>> 0 may be send under certain conditions (even if disabled or in rx mode).
>>>>
>>>> The workaround in the errata suggests not to use the mailbox and load it
>>>> with a unused identifier.
>>>>
>>>> This patch implements the second part of the workaround. A sysfs entry
>>>> "mb0_id" is introduced. While the interface is down it can be used to
>>>> configure the can_id of mailbox 0. The default value id 0x7ff.
>>>>
>>>> In order to use an extended can_id add the CAN_EFF_FLAG (0x80000000U)
>>>> to the can_id. Example:
>>>>
>>>> - standard id 0x7ff:
>>>> echo 0x7ff      > /sys/class/net/can0/mb0_id
>>>>
>>>> - extended if 0x1fffffff:
>>               ^^
>> I've fixed the typo on my git repo. I'll send an updated series later.
>>
>>>> echo 0x9fffffff > /sys/class/net/can0/mb0_id
>>>
>>> As this is a device specific property, I think it should go into
>>> /sys/class/net/can0/device/.
>>
>> The attribute goes autoamtically to /sys/class/net/can0 if you add it to
>> the driver via:
>>
>> +       dev->sysfs_groups[0] = &at91_sysfs_attr_group;
>>
>> I've copied this from the janz-ican3 driver[1].
> 
> Oh, I missed that. And also the Softing driver does it that way :-(. The
> member has the comment:
> 
>   /* space for optional device, statistics, and wireless sysfs groups */
>   const struct attribute_group *sysfs_groups[4];
> 
> Therefore it seems to be legal to use it for device specific properties.

I'm not really happy with these sysfs approach, but it's quick
implemented. Is device specific rtnetlink an option here?

cheers, Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


Download attachment "signature.asc" of type "application/pgp-signature" (263 bytes)