linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: thesven73@gmail.com
Cc: svendev@arcx.com, "Rob Herring" <robh+dt@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Thierry Reding" <treding@nvidia.com>,
	"David Lechner" <david@lechnology.com>,
	noralf@tronnes.org, "Johan Hovold" <johan@kernel.org>,
	"Michal Simek" <monstr@monstr.eu>,
	michal.vokac@ysoft.com, gregkh <gregkh@linuxfoundation.org>,
	"John Garry" <john.garry@huawei.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Paul Gortmaker" <paul.gortmaker@windriver.com>,
	"Sebastien Bourdelin" <sebastien.bourdelin@savoirfairelinux.com>,
	"Icenowy Zheng" <icenowy@aosc.io>,
	"Stuart Yoder" <stuyoder@gmail.com>,
	"Maxime Ripard" <maxime.ripard@bootlin.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>
Subject: Re: [PATCH anybus v3 6/6] misc: support HMS Profinet IRT industrial controller
Date: Thu, 8 Nov 2018 15:20:29 +0100	[thread overview]
Message-ID: <CAK8P3a3apbxNa2FpADvdLCe-GzV+2xv2kO1_tosOZrUpY6xWtA@mail.gmail.com> (raw)
In-Reply-To: <20181104155501.14767-7-TheSven73@googlemail.com>

On Sun, Nov 4, 2018 at 4:55 PM <thesven73@gmail.com> wrote:

> +
> +struct msgEthConfig {
> +       u32 ip_addr, subnet_msk, gateway_addr;
> +} __packed;

The __packed attribute makes it slower to access but doesn't
change the layout, so better drop it.

> +struct msgMacAddr {
> +       u8 addr[6];
> +} __packed;
> +
> +struct msgStr {
> +       char    s[128];
> +} __packed;
> +
> +struct msgShortStr {
> +       char    s[64];
> +} __packed;
> +
> +struct msgHicp {
> +       char    enable;
> +} __packed;

The __packed on these ones has no effect, and can just be dropped
for readability.

> +static ssize_t mac_addr_show(struct device *dev,
> +                               struct device_attribute *attr,
> +                               char *buf)
> +{
> +       struct profi_priv *priv = dev_get_drvdata(dev);
> +       struct msgMacAddr response;
> +       int ret;
> +
> +       ret = anybuss_recv_msg(priv->client, 0x0010, &response,
> +                                               sizeof(response));
> +       if (ret)
> +               return ret;
> +       return snprintf(buf, PAGE_SIZE, "%02X:%02X:%02X:%02X:%02X:%02X\n",
> +               response.addr[0], response.addr[1],
> +               response.addr[2], response.addr[3],
> +               response.addr[4], response.addr[5]);
> +}
> +
> +static DEVICE_ATTR_RO(mac_addr);

> +static ssize_t ip_addr_show(struct device *dev,
> +                               struct device_attribute *attr,
> +                               char *buf)
> +{

I don't understand much about field bus, but I have a general feeling
that if you configure a mac address and IP address, this should
be connect ed to the network layer in some form, possibly being
exposed as a network device and manipulated using netlink
instead of sysfs or ioctl.

Can you explain how this fits together and why you got the the
sysfs interface?

> +struct ProfinetConfig {

The CamelCase naming seems odd here.

> +       struct {
> +               /* addresses IN NETWORK ORDER! */
> +               __u32 ip_addr;
> +               __u32 subnet_msk;
> +               __u32 gateway_addr;
> +               __u8  is_valid:1;
> +       } eth;

This is where packing might make sense, since you have
padding fields in a user space structure ;-) . It would be better
to just avoid the implicit padding though and name all fields.

Overall, this structure feels too complex for an ioctl interface,
with the nested structures. If we end up keeping that
ioctl, maybe at least make it a flat structure without padding,
or alternatively make it a set of separate ioctls.

      Arnd

  reply	other threads:[~2018-11-08 14:20 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-04 15:54 [PATCH anybus v3 0/6] Support HMS Profinet Card over Anybus thesven73
2018-11-04 15:54 ` [PATCH anybus v3 1/6] misc: support the Arcx anybus bridge thesven73
2018-11-05 21:20   ` Rob Herring
2018-11-05 21:50     ` Sven Van Asbroeck
2018-11-06 13:58       ` Rob Herring
2018-11-06 14:45         ` Sven Van Asbroeck
2018-11-06 18:30           ` Rob Herring
2018-11-06 20:05             ` Sven Van Asbroeck
2018-11-08 13:40               ` Arnd Bergmann
2018-11-04 15:54 ` [PATCH anybus v3 2/6] dt-bindings: Add vendor prefix for arcx / Archronix thesven73
2018-11-04 15:57   ` Andreas Färber
2018-11-05 20:44   ` Rob Herring
2018-11-04 15:54 ` [PATCH anybus v3 3/6] dt-bindings: anybus-bridge: document devicetree binding thesven73
2018-11-05 20:45   ` Rob Herring
2018-11-04 15:54 ` [PATCH anybus v3 4/6] bus: support HMS Anybus-S bus thesven73
2018-11-08 14:07   ` Arnd Bergmann
2018-11-08 15:47     ` Sven Van Asbroeck
2018-11-08 16:54       ` Arnd Bergmann
2018-11-09 16:25     ` Sven Van Asbroeck
2018-11-09 21:03       ` Arnd Bergmann
2018-11-10 10:55         ` Geert Uytterhoeven
2018-11-12 16:23     ` Sven Van Asbroeck
2018-11-04 15:55 ` [PATCH anybus v3 5/6] dt-bindings: anybuss-host: document devicetree binding thesven73
2018-11-08 14:11   ` Arnd Bergmann
2018-11-08 14:21     ` Sven Van Asbroeck
2018-11-08 14:27       ` Arnd Bergmann
2018-11-12 18:05         ` Sven Van Asbroeck
2018-11-04 15:55 ` [PATCH anybus v3 6/6] misc: support HMS Profinet IRT industrial controller thesven73
2018-11-08 14:20   ` Arnd Bergmann [this message]
2018-11-08 15:35     ` Sven Van Asbroeck
2018-11-08 16:52       ` Arnd Bergmann
2018-11-09 16:02 ` [PATCH anybus v3 0/6] Support HMS Profinet Card over Anybus Sven Van Asbroeck
2018-11-09 21:22   ` Arnd Bergmann
2018-11-09 21:46     ` Sven Van Asbroeck
2018-11-09 22:32       ` Arnd Bergmann

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=CAK8P3a3apbxNa2FpADvdLCe-GzV+2xv2kO1_tosOZrUpY6xWtA@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=afaerber@suse.de \
    --cc=david@lechnology.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=icenowy@aosc.io \
    --cc=johan@kernel.org \
    --cc=john.garry@huawei.com \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=michal.vokac@ysoft.com \
    --cc=monstr@monstr.eu \
    --cc=noralf@tronnes.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sebastien.bourdelin@savoirfairelinux.com \
    --cc=stuyoder@gmail.com \
    --cc=svendev@arcx.com \
    --cc=thesven73@gmail.com \
    --cc=treding@nvidia.com \
    /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;
as well as URLs for NNTP newsgroup(s).