From: "Bjørn Mork" <bjorn@mork.no>
To: Igor Russkikh <Igor.Russkikh@aquantia.com>
Cc: "David S . Miller" <davem@davemloft.net>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Dmitry Bezrukov <Dmitry.Bezrukov@aquantia.com>
Subject: [net-next,03/19] net: usb: aqc111: Add implementation of read and write commands
Date: Tue, 09 Oct 2018 15:33:25 +0200 [thread overview]
Message-ID: <87d0sj9rdm.fsf@miraculix.mork.no> (raw)
Igor Russkikh <Igor.Russkikh@aquantia.com> writes:
> +static int __aqc111_read_cmd(struct usbnet *dev, u8 cmd, u16 value,
> + u16 index, u16 size, void *data, int nopm)
> +{
> + int ret;
> + int (*fn)(struct usbnet *dev, u8 cmd, u8 reqtype, u16 value,
> + u16 index, void *data, u16 size);
> +
> + if (nopm)
> + fn = usbnet_read_cmd_nopm;
> + else
> + fn = usbnet_read_cmd;
> +
> + ret = fn(dev, cmd, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
> + value, index, data, size);
> + if (size == 2)
> + le16_to_cpus(data);
> +
> + if (unlikely(ret < 0))
> + netdev_warn(dev->net,
> + "Failed to read(0x%x) reg index 0x%04x: %d\n",
> + cmd, index, ret);
> + return ret;
> +}
> +
> +static int aqc111_read_cmd_nopm(struct usbnet *dev, u8 cmd, u16 value,
> + u16 index, u16 size, void *data)
> +{
> + return __aqc111_read_cmd(dev, cmd, value, index, size, data, 1);
> +}
> +
> +static int aqc111_read_cmd(struct usbnet *dev, u8 cmd, u16 value,
> + u16 index, u16 size, void *data)
> +{
> + return __aqc111_read_cmd(dev, cmd, value, index, size, data, 0);
> +}
> +
Why would you want to do something like this instead of simply
implementing aqc111_read_cmd_nopm() and aqc111_read_cmd() as separate
functions? The function pointer stuff is incredibly ugly, as Oliver
pointed out. It wasn't done like that in usbnet.c, so why should we do
it like that here?
And the "if (size == 2) le16_to_cpus(data)" looks like something that
will come back and haunt you. Will this code never read larger
integers? Maybe add some sanity checks then, just in case...
Or simply add more helpers. An additional pair of helpers for reading
16bit integers might simplify your code quite a bit.
Bjørn
next reply other threads:[~2018-10-09 13:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-09 13:33 Bjørn Mork [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-10-08 13:44 [net-next,03/19] net: usb: aqc111: Add implementation of read and write commands Oliver Neukum
2018-10-05 17:40 David Miller
2018-10-05 10:24 Igor Russkikh
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=87d0sj9rdm.fsf@miraculix.mork.no \
--to=bjorn@mork.no \
--cc=Dmitry.Bezrukov@aquantia.com \
--cc=Igor.Russkikh@aquantia.com \
--cc=davem@davemloft.net \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).