public inbox for linux-serial@vger.kernel.org
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Rodolfo Zitellini" <rwz@xhero.org>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jiri Slaby" <jirislaby@kernel.org>
Cc: Netdev <netdev@vger.kernel.org>,
	linux-doc@vger.kernel.org, linux-serial@vger.kernel.org,
	linux-kernel@vger.kernel.org, "Doug Brown" <doug@schmorgal.com>
Subject: Re: [PATCH net-next 2/2] appletalk: tashtalk: Add LocalTalk line discipline driver for AppleTalk using a TashTalk adapter
Date: Mon, 19 Aug 2024 11:44:18 +0200	[thread overview]
Message-ID: <f1c86ed3-9306-459d-acb5-97730bfeb265@app.fastmail.com> (raw)
In-Reply-To: <20240817093316.9239-1-rwz@xhero.org>

On Sat, Aug 17, 2024, at 11:33, Rodolfo Zitellini wrote:
> This is the TashTalk driver, it perits for a modern machine to
> participate in a Apple LocalTalk network and is compatibile with
> Netatalk.
>
> Please see the included documentation for details:
> Documentation/networking/device_drivers/appletalk/index.rst
>
> Signed-off-by: Rodolfo Zitellini <rwz@xhero.org>

Hi Rodolfo,

Nice to see you got this into a working state! I vaguely
remember discussing this in the past, and suggesting you
try a user space solution, so it would be good if you can
add in the patch description why you ended up with a kernel
driver after all.

My main concern at this point is the usage of .ndo_do_ioctl.
I had previously sent patches to completely remove that
from the kernel, but never got around to send a new version
after the previous review. I still have them in my tree
and should be able to send them again, but that will obviously
conflict with your added use.

> +static struct net_device **tashtalk_devs;
> +
> +static int tash_maxdev = TASH_MAX_CHAN;
> +module_param(tash_maxdev, int, 0);
> +MODULE_PARM_DESC(tash_maxdev, "Maximum number of tashtalk devices");

You should not need to keep a list of the devices
or a module parameter to limit the number. I'm fairly sure
the devices are already tracked by the network stack in a
way that lets you enumerate them later.

> +static void tashtalk_send_ctrl_packet(struct tashtalk *tt, unsigned 
> char dst,
> +				      unsigned char src, unsigned char type);
> +
> +static unsigned char tt_arbitrate_addr_blocking(struct tashtalk *tt, 
> unsigned char addr);

Please try to avoid forward declations and instead reorder the
functions to put the callers after the calles.

> +static void tash_setbits(struct tashtalk *tt, unsigned char addr)
> +{
> +	unsigned char bits[33];
> +	unsigned int byte, pos;
> +
> +	/* 0, 255 and anything else are invalid */
> +	if (addr == 0 || addr >= 255)
> +		return;
> +
> +	memset(bits, 0, sizeof(bits));
> +
> +	/* in theory we can respond to many addresses */
> +	byte = addr / 8 + 1; /* skip initial command byte */
> +	pos = (addr % 8);
> +	bits[byte] = (1 << pos);

This is basically set_bit_le(), so you could use that
for clarity and use an array of 'unsigned long' words.

> +	set_bit(TTY_DO_WRITE_WAKEUP, &tt->tty->flags);
> +	tt->tty->ops->write(tt->tty, bits, sizeof(bits));
> +}

> +
> +static u16 tt_crc_ccitt_update(u16 crc, u8 data)
> +{
> +	data ^= (u8)(crc) & (u8)(0xFF);
> +	data ^= data << 4;
> +	return ((((u16)data << 8) | ((crc & 0xFF00) >> 8)) ^ (u8)(data >> 4) ^
> +		((u16)data << 3));
> +}

Can you use the global crc_ccitt() function instead of implementing
your own?

> +static int tt_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> +{
> +	struct sockaddr_at *sa = (struct sockaddr_at *)&ifr->ifr_addr;
> +	struct tashtalk *tt = netdev_priv(dev);
> +	struct atalk_addr *aa = &tt->node_addr;
> +
> +	switch (cmd) {
> +	case SIOCSIFADDR:
> +
> +		sa->sat_addr.s_node =
> +			tt_arbitrate_addr_blocking(tt, sa->sat_addr.s_node);
> +
> +		aa->s_net = sa->sat_addr.s_net;
> +		aa->s_node = sa->sat_addr.s_node;
> +
> +		/* Set broadcast address. */
> +		dev->broadcast[0] = 0xFF;
> +
> +		/* Set hardware address. */
> +		dev->addr_len = 1;
> +		dev_addr_set(dev, &aa->s_node);
> +
> +		/* Setup tashtalk to respond to that addr */
> +		tash_setbits(tt, aa->s_node);
> +
> +		return 0;
> +
> +	case SIOCGIFADDR:
> +		sa->sat_addr.s_net = aa->s_net;
> +		sa->sat_addr.s_node = aa->s_node;
> +
> +		return 0;

As we discussed in the past, I think this really should
not use ndo_do_ioctl(), which instead should just disappear.

Please change the caller to use some other method of
setting the address in the driver.

> +static int tashtalk_ioctl(struct tty_struct *tty, unsigned int cmd,
> +			  unsigned long arg)
> +{
> +	struct tashtalk *tt = tty->disc_data;
> +	int __user *p = (int __user *)arg;
> +	unsigned int tmp;
> +
> +	/* First make sure we're connected. */
> +	if (!tt || tt->magic != TASH_MAGIC)
> +		return -EINVAL;
> +
> +	switch (cmd) {
> +	case SIOCGIFNAME:
> +		tmp = strlen(tt->dev->name) + 1;
> +		if (copy_to_user((void __user *)arg, tt->dev->name, tmp))
> +			return -EFAULT;
> +		return 0;
> +
> +	case SIOCGIFENCAP:
> +		if (put_user(tt->mode, p))
> +			return -EFAULT;
> +		return 0;
> +
> +	case SIOCSIFENCAP:
> +		if (get_user(tmp, p))
> +			return -EFAULT;
> +		tt->mode = tmp;
> +		return 0;
> +
> +	case SIOCSIFHWADDR:
> +		return -EINVAL;
> +
> +	default:
> +		return tty_mode_ioctl(tty, cmd, arg);
> +	}

I'm also not a bit fan of using the SIOC* command codes
in a tty device with incompatible argument types. I do
see that slip and x25 do the same, but it would be nice
to find a better interface for these. I have not looked
at all the other line disciplines, but maybe you can
find a better example to copy.

     Arnd

  reply	other threads:[~2024-08-19  9:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-17  9:33 [PATCH net-next 2/2] appletalk: tashtalk: Add LocalTalk line discipline driver for AppleTalk using a TashTalk adapter Rodolfo Zitellini
2024-08-19  9:44 ` Arnd Bergmann [this message]
2024-08-19 12:39   ` Rodolfo Zitellini
2024-08-19  9:47 ` Simon Horman
2024-08-19  9:55 ` Jiri Slaby
2024-08-19 14:28 ` Jeff Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f1c86ed3-9306-459d-acb5-97730bfeb265@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=doug@schmorgal.com \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rwz@xhero.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox