linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Srinivasan Raju <srini.raju@purelifi.com>
Cc: "open list:STAGING SUBSYSTEM" <devel@driverdev.osuosl.org>,
	Rob Herring <robh@kernel.org>, pureLiFi Ltd <info@purelifi.com>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	mostafa.afgani@purelifi.com,
	open list <linux-kernel@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] staging: Initial driver submission for pureLiFi devices
Date: Thu, 24 Sep 2020 22:07:58 +0300	[thread overview]
Message-ID: <20200924190758.GM4282@kadam> (raw)
In-Reply-To: <20200924151910.21693-1-srini.raju@purelifi.com>

On Thu, Sep 24, 2020 at 08:48:51PM +0530, Srinivasan Raju wrote:
> +
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +
> +#include "def.h"
> +#include "chip.h"
> +#include "mac.h"
> +#include "usb.h"
> +#include "log.h"
> +
> +void purelifi_chip_init(struct purelifi_chip *chip,
> +			struct ieee80211_hw *hw,
> +		struct usb_interface *intf
> +		)

There is a bunch of really trivial messiness like this.  It should
look like:

void purelifi_chip_init(struct purelifi_chip *chip,
			struct ieee80211_hw *hw,
			struct usb_interface *intf)


> +{
> +	memset(chip, 0, sizeof(*chip));
> +	mutex_init(&chip->mutex);
> +	purelifi_usb_init(&chip->usb, hw, intf);
> +}
> +
> +void purelifi_chip_clear(struct purelifi_chip *chip)
> +{
> +	PURELIFI_ASSERT(!mutex_is_locked(&chip->mutex));
> +	purelifi_usb_clear(&chip->usb);
> +	mutex_destroy(&chip->mutex);
> +	PURELIFI_MEMCLEAR(chip, sizeof(*chip));

Get rid of the PURELIFI_MEMCLEAR() macro.  The weird thing about
PURELIFI_MEMCLEAR() is that sometimes it's a no-op.  It seems
unnecessary to memset() the struct here.

I'm not a fan of all these tiny functions.  It feels like I have to
jump around a lot to understand the code.  What does "clear" mean in
this context.  Probably "release" is a better name.

> +}
> +
> +static int scnprint_mac_oui(struct purelifi_chip *chip, char *buffer,
> +			    size_t size)
> +{
> +	u8 *addr = purelifi_mac_get_perm_addr(purelifi_chip_to_mac(chip));
> +
> +	return scnprintf(buffer, size, "%02x-%02x-%02x",
> +			addr[0], addr[1], addr[2]);
> +}
> +
> +/* Prints an identifier line, which will support debugging. */
> +static int scnprint_id(struct purelifi_chip *chip, char *buffer, size_t size)

This function name is too vague.  What ID is it printing?

> +{
> +	int i = 0;

The initialization is not required.  "i" means "iterator".  This should
be "cnt" instead.

> +
> +	i = scnprintf(buffer, size, "purelifi%s chip ", "");
> +	i += purelifi_usb_scnprint_id(&chip->usb, buffer + i, size - i);
> +	i += scnprintf(buffer + i, size - i, " ");
> +	i += scnprint_mac_oui(chip, buffer + i, size - i);
> +	i += scnprintf(buffer + i, size - i, " ");
> +	return i;

This is an example of how tiny functions obfuscate the code.  It should
be written like this:

static void print_whatever(struct purelifi_chip *chip)
{
	u8 *addr = purelifi_mac_get_perm_addr(purelifi_chip_to_mac(chip));
	struct usb_device *udev = interface_to_usbdev(chip->usb.intf);

	pr_info("purelifi chip 04hx:%04hx v%04hx %s %02x-%02x-%02x\n",
		le16_to_cpu(udev->descriptor.idVendor),
		le16_to_cpu(udev->descriptor.idProduct),
		get_bcd_device(udev),
		speed(udev->speed),
		addr[0], addr[1], addr[2]);
}

> +}
> +
> +static void print_id(struct purelifi_chip *chip)
> +{
> +	char buffer[80];
> +
> +	scnprint_id(chip, buffer, sizeof(buffer));
> +	buffer[sizeof(buffer) - 1] = 0;

snprintf() functions alway put a NUL terminator on the end of the string.

> +	pl_dev_info(purelifi_chip_dev(chip), "%s\n", buffer);
> +}
> +
> +/* MAC address: if custom mac addresses are to be used CR_MAC_ADDR_P1 and
> + *              CR_MAC_ADDR_P2 must be overwritten
> + */
> +int purelifi_write_mac_addr(struct purelifi_chip *chip, const u8 *mac_addr)
> +{
> +	int r;
> +
> +	r = usb_write_req(mac_addr, ETH_ALEN, USB_REQ_MAC_WR);
> +	return r;

Delete the "r" variable.

	return usb_write_req(mac_addr, ETH_ALEN, USB_REQ_MAC_WR);

Again, I'm not a huge fan of one line functions for no reason. Actually,
the function is never called.  Just delete it.

> +}
> +
> +int purelifi_set_beacon_interval(struct purelifi_chip *chip, u16 interval,
> +				 u8 dtim_period, int type)
> +{
> +	int r;
> +
> +	if (!interval || (chip->beacon_set &&
> +			  chip->beacon_interval == interval)) {
> +		return 0;
> +	}
> +
> +	chip->beacon_interval = interval;
> +	chip->beacon_set = true;
> +	r = usb_write_req((const u8 *)&chip->beacon_interval,
> +			  sizeof(chip->beacon_interval),
> +			  USB_REQ_BEACON_INTERVAL_WR);
> +	return r;

Delete the "r" variable.

> +}
> +
> +static int hw_init(struct purelifi_chip *chip)
> +{
> +	return purelifi_set_beacon_interval(chip, 100, 0, 0);
> +}

This is a oneline function which is only called once.  Move it inline.

> +
> +int purelifi_chip_init_hw(struct purelifi_chip *chip)
> +{
> +	int r;
> +
> +	r = hw_init(chip);
> +	if (r)
> +		goto out;

Just return directly.  The little bunny hop doesn't add anything.

> +
> +	print_id(chip);
> +out:
> +	return r;
> +}

Anyway, those are some ideas.

regards,
dan carpenter


  parent reply	other threads:[~2020-09-24 19:10 UTC|newest]

Thread overview: 118+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 15:18 [PATCH] staging: Initial driver submission for pureLiFi devices Srinivasan Raju
2020-09-24 15:36 ` Greg Kroah-Hartman
2020-09-24 17:24   ` Srinivasan Raju
2020-09-24 17:29     ` Greg Kroah-Hartman
2020-09-28 10:25       ` Srinivasan Raju
2020-09-24 15:37 ` Greg Kroah-Hartman
2020-09-24 18:28 ` Randy Dunlap
2020-09-28 10:27   ` Srinivasan Raju
2020-09-24 19:07 ` Dan Carpenter [this message]
2020-09-28 10:26   ` Srinivasan Raju
2020-09-28 10:19 ` [PATCH] [v2] wireless: " Srinivasan Raju
2020-09-28 12:07   ` Joe Perches
2020-09-28 12:53     ` Srinivasan Raju
2020-09-30  5:16   ` Leon Romanovsky
2020-09-30  5:29     ` Srinivasan Raju
2020-09-30  8:01     ` Kalle Valo
2020-09-30  9:55       ` Leon Romanovsky
2020-09-30 10:11         ` Johannes Berg
2020-09-30 10:44           ` Leon Romanovsky
2020-10-16  8:23             ` Kalle Valo
2020-09-30  8:05     ` Kalle Valo
2020-09-30 10:04       ` Leon Romanovsky
2020-10-14  6:19   ` [PATCH] [PATCH] [v3] wireless: Initial driver submission for pureLiFi STA devices Srinivasan Raju
2020-10-14 10:17     ` kernel test robot
2020-10-15 22:35     ` Joe Perches
2020-10-16  6:36       ` Srinivasan Raju
2020-10-16  6:34   ` [PATCH] [v4] " Srinivasan Raju
2020-10-16  8:58     ` Joe Perches
2020-10-16 10:13       ` Srinivasan Raju
2020-10-19  3:17     ` [PATCH] [v5] " Srinivasan Raju
2020-10-19  4:55       ` Joe Perches
2020-10-19  6:05         ` Srinivasan Raju
2020-10-19  8:38       ` [PATCH] [v6] " Srinivasan Raju
2020-10-19 16:07         ` Krishna Chaitanya
2020-10-19 16:40           ` Srinivasan Raju
2020-10-19 16:54             ` Joe Perches
2020-10-19 17:05               ` Srinivasan Raju
2020-11-16  9:22     ` [PATCH] [v7] " Srinivasan Raju
2020-11-16 20:45       ` Joe Perches
2020-11-18  3:24         ` Srinivasan Raju
2020-11-24 14:44       ` Kalle Valo
     [not found]       ` <20201124144448.4E95EC43460@smtp.codeaurora.org>
2020-11-26  5:01         ` Srinivasan Raju
2020-12-03  4:43           ` Srinivasan Raju
2020-12-03 15:58             ` Kalle Valo
2020-12-03 16:50               ` Srinivasan Raju
2020-12-19 13:15                 ` Kalle Valo
2020-12-03  4:38   ` [PATCH] [v8] " Srinivasan Raju
2020-12-03  5:09   ` [PATCH] [v9] " Srinivasan Raju
2020-12-03  7:53     ` Joe Perches
2020-12-08  5:53   ` [PATCH] [v10] " Srinivasan Raju
2020-12-08 11:57   ` [PATCH] [v11] " Srinivasan Raju
2020-12-08 14:37     ` Kalle Valo
2020-12-19 12:51     ` Kalle Valo
2020-12-19 13:06     ` Kalle Valo
2020-12-19 13:14     ` Kalle Valo
2020-12-21  5:52       ` Srinivasan Raju
2020-12-21  5:57         ` Kalle Valo
2021-01-15 12:13           ` Srinivasan Raju
2021-01-05 13:19   ` [PATCH] [PATCH] [v12] " Srinivasan Raju
2021-02-12 11:49   ` [PATCH] [v13] " Srinivasan Raju
2021-02-12 13:44     ` Johannes Berg
2021-02-17 10:05       ` Kalle Valo
2021-02-19  5:15       ` Srinivasan Raju
2021-02-19  8:25         ` Johannes Berg
2021-02-24 10:41           ` Srinivasan Raju
2021-02-12 15:06     ` kernel test robot
2021-02-12 17:57     ` kernel test robot
2021-02-17 10:02     ` Kalle Valo
2021-02-17 10:13       ` Kalle Valo
2021-02-17 10:16         ` Srinivasan Raju
2021-02-17 10:09     ` Kalle Valo
2021-02-17 10:19     ` Kalle Valo
2021-02-24 10:44       ` Srinivasan Raju
2021-02-26 13:07   ` [PATCH] [v14] " Srinivasan Raju
2021-04-19 11:52     ` Srinivasan Raju
2021-08-10 13:02       ` Srinivasan Raju
2021-08-21 13:42         ` Kalle Valo
2021-08-18 14:13     ` [PATCH] [v15] " Srinivasan Raju
2021-09-20 13:05       ` Kalle Valo
     [not found]         ` <CWLP265MB3217BB5AA5F102629A3AD204E0A19@CWLP265MB3217.GBRP265.PROD.OUTLOOK.COM>
2021-09-21 12:30           ` [EXTERNAL] " Kalle Valo
2021-09-22  7:33             ` Johannes Berg
2021-09-24 13:27               ` [EXTERNAL] " Srinivasan Raju
2021-09-20 14:11       ` Kalle Valo
2021-09-24 11:11       ` Kalle Valo
2021-09-24 13:26   ` [PATCH] [v16] wireless: Initial driver submission for pureLiFi LiFi Station Srinivasan Raju
2021-09-24 13:40     ` Kalle Valo
2021-10-05 11:22   ` [PATCH] [v17] wireless: Initial driver submission for pureLiFi STA devices Srinivasan Raju
2021-10-05 11:26     ` Johannes Berg
2021-10-05 12:30   ` [PATCH] [v18 1/2] nl80211: Add LC placeholder band definition to enum nl80211_band Srinivasan Raju
2021-10-05 12:31   ` [PATCH] [v18 2/2] wireless: Initial driver submission for pureLiFi STA devices Srinivasan Raju
2021-10-05 22:09     ` Jeff Johnson
2021-10-06 10:04   ` [PATCH] [v19 " Srinivasan Raju
2021-10-11  6:16     ` Kalle Valo
2021-10-12 12:50   ` [PATCH 0/2] wireless: New Driver " Srinivasan Raju
2021-10-12 12:50     ` [PATCH 1/2] [v19 1/2] nl80211: Add LC placeholder band definition to enum nl80211_band Srinivasan Raju
2021-10-12 12:50     ` [PATCH 2/2] [v19 2/2] wireless: Initial driver submission for pureLiFi STA devices Srinivasan Raju
2021-10-14  6:03       ` kernel test robot
2021-10-24 17:58       ` kernel test robot
2021-10-18 10:00   ` [PATCH v20 0/2] wireless: New Driver " Srinivasan Raju
2021-10-18 10:00     ` [PATCH v20 1/2] nl80211: Add LC placeholder band definition to nl80211_band Srinivasan Raju
2021-10-18 10:00     ` [PATCH v20 2/2] wireless: Initial driver submission for pureLiFi STA devices Srinivasan Raju
2021-10-25  9:59       ` Kari Argillander
     [not found]         ` <CWLP265MB321780AB502EF147F6AAF197E0839@CWLP265MB3217.GBRP265.PROD.OUTLOOK.COM>
2021-10-25 12:17           ` [EXTERNAL] " Kalle Valo
2021-10-27 11:34       ` kernel test robot
2021-10-27 12:38       ` Kari Argillander
2021-10-28  7:24         ` Kalle Valo
2021-10-31 13:10   ` [PATCH v21 0/2] wireless: New Driver " Srinivasan Raju
2021-10-31 13:10     ` [PATCH 1/2] nl80211: Add LC placeholder band definition to nl80211_band Srinivasan Raju
2021-10-31 13:10     ` [PATCH 2/2] wireless: Initial driver submission for pureLiFi STA devices Srinivasan Raju
2021-12-20 19:13       ` Kalle Valo
2022-02-24 15:35       ` Kalle Valo
2022-02-24 18:20   ` [PATCH v22 0/2] wireless: New Driver " Srinivasan Raju
2022-02-24 18:20     ` [PATCH v22 1/2] nl80211: Add LC placeholder band definition to nl80211_band Srinivasan Raju
2022-02-25  9:52       ` Kalle Valo
2022-02-24 18:20     ` [PATCH v22 1/2] wireless: Initial driver submission for pureLiFi STA devices Srinivasan Raju
2022-04-25 13:06       ` Kalle Valo
     [not found]         ` <CWLP265MB32173F6188304F6B2CB90C79E0F89@CWLP265MB3217.GBRP265.PROD.OUTLOOK.COM>
2022-04-26  4:17           ` [EXTERNAL] " Kalle Valo
2022-04-27  4:55       ` Kalle Valo

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=20200924190758.GM4282@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=davem@davemloft.net \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=info@purelifi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=mostafa.afgani@purelifi.com \
    --cc=robh@kernel.org \
    --cc=srini.raju@purelifi.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).