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
next prev parent 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