linux-kernel - [PATCH v2 0/6] can: slcan: extend supported features (step 2)

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-next>] [day] [month] [year] [list]

Message-Id: <20220725065419.3005015-1-dario.binacchi@amarulasolutions.com>
Date:   Mon, 25 Jul 2022 08:54:13 +0200
From:   Dario Binacchi <dario.binacchi@...rulasolutions.com>
To:     linux-kernel@...r.kernel.org
Cc:     michael@...rulasolutions.com,
        Amarula patchwork <linux-amarula@...rulasolutions.com>,
        Jeroen Hofstee <jhofstee@...tronenergy.com>,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        Dario Binacchi <dario.binacchi@...rulasolutions.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        Paolo Abeni <pabeni@...hat.com>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        linux-can@...r.kernel.org, netdev@...r.kernel.org
Subject: [PATCH v2 0/6] can: slcan: extend supported features (step 2)

With this series I try to finish the task, started with the series [1],
of completely removing the dependency of the slcan driver from the
userspace slcand/slcan_attach applications.

The series, however, still lacks a patch for sending the bitrate setting
command to the adapter:

slcan_attach -b <btr> <dev>

Without at least this patch the task cannot be considered truly completed.

The idea I got is that this can only happen through the ethtool API.
Among the various operations made available by this interface I would
have used the set_regs (but only the get_regs has been developed), or,
the set_eeprom, even if the setting would not be stored in an eeprom.
IMHO it would take a set_regs operation with a `struct ethtool_wregs'
parameter similar to `struct ethtool_eeprom' without the magic field:

struct ethtool_wregs {
	__u32	cmd;
	__u32	offset;
	__u32	len;
	__u8	data[0];
};

But I am not the expert and if there was an alternative solution already
usable, it would be welcome.

The series also contains patches that remove the legacy stuff (slcan_devs,
SLCAN_MAGIC, ...) and do some module cleanup.

The series has been created on top of the patches:

can: slcan: convert comments to network style comments
can: slcan: slcan_init() convert printk(LEVEL ...) to pr_level()
can: slcan: fix whitespace issues
can: slcan: convert comparison to NULL into !val
can: slcan: clean up if/else
can: slcan: use scnprintf() as a hardening measure
can: slcan: do not report txerr and rxerr during bus-off
can: slcan: do not sleep with a spin lock held

applied to linux-next.

[1] https://lore.kernel.org/all/20220628163137.413025-1-dario.binacchi@amarulasolutions.com/

Changes in v2:
- Re-add headers that export at least one symbol used by the module.
- Update the commit description.
- Drop the old "slcan" name to use the standard canX interface naming.
- Remove comment on listen-only command.
- Update the commit subject and description.
- Add the patch "MAINTAINERS: Add myself as maintainer of the SLCAN driver"
  to the series.

Dario Binacchi (6):
  can: slcan: remove useless header inclusions
  can: slcan: remove legacy infrastructure
  can: slcan: change every `slc' occurrence in `slcan'
  can: slcan: use the generic can_change_mtu()
  can: slcan: add support for listen-only mode
  MAINTAINERS: Add maintainer for the slcan driver

 MAINTAINERS                        |   6 +
 drivers/net/can/slcan/slcan-core.c | 451 +++++++++--------------------
 2 files changed, 139 insertions(+), 318 deletions(-)

-- 
2.32.0