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]

Date:	Tue, 11 Jan 2011 14:28:36 +0100
From:	Wolfgang Grandegger <wg@...ndegger.com>
To:	Marc Kleine-Budde <mkl@...gutronix.de>
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:33 PM, Marc Kleine-Budde wrote:
> 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?

That's toooooooo heavy, I think. I personally would just use
device_create_file for that purpose. But let's keep using sysfs_groups[]
if nobody else complains.

Wolfgang.

Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html