lkml.org 
[lkml]   [2018]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH anybus v3 6/6] misc: support HMS Profinet IRT industrial controller
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

\
 
 \ /
  Last update: 2018-11-08 15:21    [W:0.261 / U:1.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site