Hi Oliver, > Am 07.01.2022 um 13:15 schrieb Oliver Hartkopp <socketcan@xxxxxxxxxxxx>: > > Hi Michael, > > On 07.01.22 10:50, Dr. Michael Lauer wrote: >> Forgive me, if that’s a topic that already came up… >> …reading the recent patch sets where hardware CAN capabilities are exposed to userland, >> I wonder why we still don’t have standardized ioctls (or whatever other means) to >> control the hardware arbitration masks that seem to be present in almost all CAN controllers. >> In particular, I’ve stumbled over the https://github.com/craigpeacock/mcp251x, which is a driver >> that exposes the hardware filtering at module load time. Wouldn’t it be helpful to >> have a standardized way to control this? Also the isotp could make use of this. > > In fact we started discussing about a common interface to configure CAN hardware filters in 2018: > > https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/log/?h=can-hw-filter > > But it didn't get further - probably because nobody really pushed this feature. > > I have to take a look on that discussions around 2018-02-20 ... > > https://lore.kernel.org/linux-can/98bcd448-4d2a-bf2f-ae5a-4db7f1eac896@xxxxxxxxx/ > > There were some patches flying around too: > > https://marc.info/?l=linux-can&m=151949929522529 > > https://marc.info/?l=linux-can&m=151949942422563&w=2 > > But these patches are not available in https://lore.kernel.org/linux-can ¯\_(ツ)_/¯ Interesting. That all looks like we’re almost there! What can we do to get the momentum going again? The reason why I’d really love to see this is that we have those tiny Linux-capable SOCs these days which – albeit really powerful compared to a microcontroller – are still kind of challenged when it comes to serving CAN under load. On systems like the Raspberry PI Zero (2), every unnecessary context switch hurts ;-) Best, Michael Lauer.
