From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kurt Van Dijck Subject: Re: Framework for hardware filter support? Date: Fri, 16 Feb 2018 00:03:58 +0100 Message-ID: <3BDADFD0-AACB-45F6-A8EA-72D1C9EA5DDF@vandijck-laurijssen.be> References: <98bcd448-4d2a-bf2f-ae5a-4db7f1eac896@pobox.com> <6c112388-5dcb-2dca-06c6-eac56d470fbb@pobox.com> <20180213194203.GA15640@airbook.vandijck-laurijssen.be> <55e3a0ef-82ea-b62d-34f7-ca7518b9d534@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Return-path: Received: from relay-b01.edpnet.be ([212.71.1.221]:46090 "EHLO relay-b01.edpnet.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756361AbeBOXEE (ORCPT ); Thu, 15 Feb 2018 18:04:04 -0500 In-Reply-To: <55e3a0ef-82ea-b62d-34f7-ca7518b9d534@pobox.com> Sender: linux-can-owner@vger.kernel.org List-ID: To: Daniel Santos Cc: Oliver Hartkopp , linux-can On 14 February 2018 23:40:19 CET, Daniel Santos wrote: >Thanks for your response, Kurt. > > >On 02/13/2018 01:42 PM, Kurt Van Dijck wrote: >> On zo, 11 feb 2018 16:33:43 -0600, Daniel Santos wrote: >>>> where the CAN_RAW filter design would easily fit. >>> This is what I mean by a framework.  So the driver should inform the >>> core CAN driver what it's filtering capabilities are -- again, I >would >>> have to study a number of devices to design this sanely.  It would >seem >>> that iproute2 would be the best userland mechanism to specify them, >and >>> it could pass an array of struct can_filter objects.  Then based >upon >>> the hardware, it can apply or reject them.  It would also be nice >for >>> iproute2 to query the driver and be able to report those >capabilities. >> I remember this discussion has passed a few times already. >> The end result has always been to: >> 1. give the kernel/driver a list of id/masks. >> 2. The driver does no aggregation, the root operator should know >> what to do. > >I don't understand what driver aggregation means.  But yes, this makes >good sense. I meant with aggregation: any form of accumulation across different calls >> Maybe some day this will become limited for hardware that can do >special >> tricks, like having a random list of identifiers. >> This can most probable be addressed in some clever way that is >specific >> for the driver (like adding a list of id/masks where mask is always >> 0x7ff for a random canid list). >> Due to the driver doing smart things, the driver may not be capable >of >> informing filtering capabilities in a static way. I would start >without >> it. >> >> The support of hardware filters is hardware specific anyway, and >> intersects the multi-user principle. The only justification is .... >> that the root operator knows the hardware and the application. > >Yes, perfect! > >> What matters for a generic implementation is that the API is simple, >> clear and usable. That is where the id/mask list pops in. >> Operators that don't understand the id/mask list will probably fail >> anyway to use hardware filters on CAN. No framework can prevent that. >> >> Kurt >> > >Yes, this makes great sense. And the driver (I presume) can always >reject the filter configuration if it can't do what is asked.  In the Yep, that's it >case of the MCP2210, however, there is one small hole; it has a bit >that >decides rather or not to rollover messages from it's first rx buffer to >it's second (and it only has two).  I'm wondering about some free-form, >driver specific configuration string to handle any loose ends of the >device?  Too ugly? > >Then again, it supports 6 filters.  Perhaps a 7th filter could be >passed >to specify the rollover configuration.  Uglier still? :) > >And actually, the device has bits to en/disable filtering for each rx >buffer that can be changed (along with the rollover) while the link is >up.  I'm probably *really* reaching here.  I can't think of many >reasons >to have to change this while the link is up and rather or not they are >enabled can be implied by the filter/mask array. A driver, and for sure an API, does not necessarily export all dirty bits to userspace. There will be things that are possible in hardware that simply cannot be exported in a comprehensible way. The need for hardware filters does not imply a need to modify them in runtime. Roll-over and other silicon magic is IMHO best preset to a default that makes most sense, or addressed in sysfs attributes, if you think that it must be accessible. > >Thanks, >Daniel Kurt