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.

Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core

Reply via email to