mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Manjunatha Venkatesh <manjunatha.venkatesh@nxp.com>
Cc: linux-kernel@vger.kernel.org, will@kernel.org, axboe@kernel.dk,
	robh+dt@kernel.org, mb@lightnvm.io,
	ckeepax@opensource.cirrus.com, arnd@arndb.d, mst@redhat.com,
	javier@javigon.com, mikelley@microsoft.com, jasowang@redhat.com,
	sunilmut@microsoft.com, bjorn.andersson@linaro.org,
	krzysztof.kozlowski+dt@linaro.org, devicetree@vger.kernel.org,
	ashish.deshpande@nxp.com, rvmanjumce@gmail.com,
	Kwame Adwere <kwame.adwere@nxp.com>
Subject: Re: [PATCH v6 2/2] misc: nxp-sr1xx: UWB driver support for sr1xx series chip
Date: Wed, 21 Dec 2022 07:12:49 +0100	[thread overview]
Message-ID: <Y6Kj4VlnJFFrzYW9@kroah.com> (raw)
In-Reply-To: <20221220154747.2372597-3-manjunatha.venkatesh@nxp.com>

On Tue, Dec 20, 2022 at 09:17:47PM +0530, Manjunatha Venkatesh wrote:
> Ultra-wideband (UWB) is a short-range wireless communication protocol.
> 
> NXP has SR1XX family of UWB Subsystems (UWBS) devices. SR1XX SOCs
> are FiRa Compliant. SR1XX SOCs are flash less devices and they need
> Firmware Download on every device boot. More details on the SR1XX Family
> can be found at https://www.nxp.com/products/:UWB-TRIMENSION
> 
> The sr1xx driver work the SR1XX Family of UWBS, and uses UWB Controller
> Interface (UCI).  The corresponding details are available in the FiRa
> Consortium Website (https://www.firaconsortium.org/).
> 
> Internally driver will handle two modes of operation.
> 1.HBCI mode (sr1xx BootROM Code Interface)
>   Firmware download uses HBCI ptotocol packet structure which is
>   Nxp proprietary,Firmware File(.bin) stored in user space context
>   and during device init sequence pick the firmware packet in chunk
>   and send it to the driver with write() api call.
> 
>   After the firmware download sequence at the end UWBS will
>   send device status notification and its indication of device entered
>   UCI mode.
>   Here after any command/response/notification will follow
>   UCI packet structure.
> 
> 2.UCI mode (UWB Command interface)
>   Once Firmware download finishes sr1xx will switch to UCI mode.
>   Then driver exchange command/response/notification as per the FIRA UCI
>   standard format between user space and sr1xx device.
>   Any response or notification received from sr1xx through SPI line
>   will convey to user space.
> 
>   Its Interrupt based driver and IO Handshake needed with SR1XX Family of
>   SOCs.
>   This driver needs dts config update as per the sr1xx data sheet.
>   Corresponding document available in Documentation/devicetree/bindings/uwb
> 
> Link: https://lore.kernel.org/r/dfe167cf-5d4e-6fc7-c954-25f719b1e843@nxp.com

Why is this here pointing to an old version of the patch?

> Signed-off-by: Manjunatha Venkatesh <manjunatha.venkatesh@nxp.com>
> Signed-off-by: Kwame Adwere <kwame.adwere@nxp.com>
> ---
> Changes since v5:
>   - Moved ioctl command definitions into header file.
>   - Version 5 patch review comments addressed.
>   - Corporate lawyer sign-off updated.

Again, you are not documenting _WHY_ you want a dual license here, which
is what I asked for yesterday, why ignore that and ask us to review this
again?

> +#define UCI_HEADER_LEN 4
> +#define HBCI_HEADER_LEN 4
> +#define UCI_PAYLOAD_LEN_OFFSET 3
> +
> +#define UCI_EXT_PAYLOAD_LEN_IND_OFFSET 1
> +#define UCI_EXT_PAYLOAD_LEN_IND_OFFSET_MASK 0x80
> +#define UCI_EXT_PAYLOAD_LEN_OFFSET 2
> +#define UCI_MT_MASK 0xE0
> +
> +#define SR1XX_TXBUF_SIZE 4200
> +#define SR1XX_RXBUF_SIZE 4200
> +#define SR1XX_MAX_TX_BUF_SIZE 4200
> +
> +#define MAX_RETRY_COUNT_FOR_IRQ_CHECK 100
> +#define MAX_RETRY_COUNT_FOR_HANDSHAKE 1000

Please use tabs.

> +/* Macro to define SPI clock frequency */
> +#define SR1XX_SPI_CLOCK 16000000L
> +#define WAKEUP_SRC_TIMEOUT (2000)
> +
> +/* Maximum UCI packet size supported from the driver */
> +#define MAX_UCI_PKT_SIZE 4200
> +
> +/* Device specific macro and structure */
> +struct sr1xx_dev {
> +	wait_queue_head_t read_wq; /* Wait queue for read interrupt */
> +	struct spi_device *spi; /* Spi device structure */
> +	struct miscdevice sr1xx_device; /* Char device as misc driver */
> +	unsigned int ce_gpio; /* SW reset gpio */
> +	unsigned int irq_gpio; /* SR1XX will interrupt host for any ntf */
> +	unsigned int spi_handshake_gpio; /* Host ready to read data */
> +	bool irq_enabled; /* Flag to indicate disable/enable irq sequence */
> +	bool irq_received; /* Flag to indicate that irq is received */
> +	spinlock_t irq_enabled_lock; /* Spin lock for read irq */
> +	unsigned char *tx_buffer; /* Transmit buffer */
> +	unsigned char *rx_buffer; /* Receive buffer */
> +	unsigned int write_count; /* Holds nubers of byte written */
> +	unsigned int read_count; /* Hold nubers of byte read */
> +	struct mutex
> +		sr1xx_access_lock; /* Lock used to synchronize read and write */
> +	size_t total_bytes_to_read; /* Total bytes read from the device */
> +	bool is_extended_len_bit_set; /* Variable to check ext payload Len */
> +	bool read_abort_requested; /* Used to indicate read abort request */
> +	bool is_fw_dwnld_enabled; /* Used to indicate fw download mode */
> +	int mode; /* Indicate write or read mode */
> +	long timeout_in_ms; /* Wait event interrupt timeout in ms */

If you want to document a structure (which is a good thing), please do
so in a way we can understand it (i.e. with kernel doc format like we do
everywhere else in the kernel), not like this which is almost impossible
to follow.

> +};
> +
> +enum spi_status_codes {
> +	TRANSCEIVE_SUCCESS,
> +	TRANSCEIVE_FAIL,
> +	IRQ_WAIT_REQUEST,
> +	IRQ_WAIT_TIMEOUT
> +};
> +
> +/* Spi write/read operation mode */
> +enum spi_operation_modes { SR1XX_WRITE_MODE, SR1XX_READ_MODE };

Why is this a global symbol?


> +static int sr1xx_dev_open(struct inode *inode, struct file *filp)
> +{
> +	struct sr1xx_dev *sr1xx_dev = container_of(
> +		filp->private_data, struct sr1xx_dev, sr1xx_device);
> +
> +	filp->private_data = sr1xx_dev;
> +	return 0;
> +}
> +
> +static void sr1xx_disable_irq(struct sr1xx_dev *sr1xx_dev)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&sr1xx_dev->irq_enabled_lock, flags);
> +	if ((sr1xx_dev->irq_enabled)) {
> +		disable_irq_nosync(sr1xx_dev->spi->irq);
> +		sr1xx_dev->irq_received = true;
> +		sr1xx_dev->irq_enabled = false;
> +	}
> +	spin_unlock_irqrestore(&sr1xx_dev->irq_enabled_lock, flags);
> +}
> +
> +static void sr1xx_enable_irq(struct sr1xx_dev *sr1xx_dev)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&sr1xx_dev->irq_enabled_lock, flags);
> +	if (!sr1xx_dev->irq_enabled) {
> +		enable_irq(sr1xx_dev->spi->irq);
> +		sr1xx_dev->irq_enabled = true;
> +		sr1xx_dev->irq_received = false;
> +	}
> +	spin_unlock_irqrestore(&sr1xx_dev->irq_enabled_lock, flags);
> +}
> +
> +static irqreturn_t sr1xx_dev_irq_handler(int irq, void *dev_id)
> +{
> +	struct sr1xx_dev *sr1xx_dev = dev_id;
> +
> +	sr1xx_disable_irq(sr1xx_dev);
> +	/* Wake up waiting readers */
> +	wake_up(&sr1xx_dev->read_wq);
> +	if (device_may_wakeup(&sr1xx_dev->spi->dev))
> +		pm_wakeup_event(&sr1xx_dev->spi->dev, WAKEUP_SRC_TIMEOUT);
> +	return IRQ_HANDLED;
> +}
> +
> +static long sr1xx_dev_ioctl(struct file *filp, unsigned int cmd,
> +			    unsigned long arg)
> +{
> +	long ret = 0;
> +	struct sr1xx_dev *sr1xx_dev = NULL;
> +
> +	sr1xx_dev = filp->private_data;
> +	if (sr1xx_dev == NULL) {
> +		ret = -EINVAL;
> +		pr_err("%s sr1xx_dev is NULL\n", __func__);
> +		return ret;
> +	}
> +	switch (cmd) {
> +	case SR1XX_SET_PWR:
> +		if (arg == PWR_ENABLE) {
> +			gpio_set_value(sr1xx_dev->ce_gpio, 1);
> +			usleep_range(10000, 12000);
> +		} else if (arg == PWR_DISABLE) {
> +			gpio_set_value(sr1xx_dev->ce_gpio, 0);
> +			sr1xx_disable_irq(sr1xx_dev);
> +			usleep_range(10000, 12000);
> +		} else if (arg == ABORT_READ_PENDING) {
> +			sr1xx_dev->read_abort_requested = true;
> +			sr1xx_disable_irq(sr1xx_dev);
> +			/* Wake up waiting readers */
> +			wake_up(&sr1xx_dev->read_wq);
> +		}
> +		break;
> +	case SR1XX_SET_FWD:
> +		if (arg == 1) {
> +			sr1xx_dev->is_fw_dwnld_enabled = true;
> +			sr1xx_dev->read_abort_requested = false;
> +		} else if (arg == 0) {
> +			sr1xx_dev->is_fw_dwnld_enabled = false;
> +		}
> +		break;
> +	default:
> +		dev_err(&sr1xx_dev->spi->dev, " Error case");

So userspace can spam the kernel log by sending your driver invalid
ioctls?  Please never do that.

> +		ret = -EINVAL;

Isn't this the wrong error value for an incorrect ioctl command?

> +	}
> +	return ret;
> +}
> +
> +/**
> + * sr1xx_wait_for_irq_gpio_low
> + *
> + * Function to wait till irq gpio goes low state
> + *
> + */

Odd commenting style, please either use the correct kerneldoc format, or
a simpler one, or nothing at all.  Please do not make up your own format
style just for a single driver as that is unmaintainable, right?

Also, I see no justification here for why this has to be a kernel
driver, OR where the userspace code is that controls this.

I've stopped here :(

greg k-h

  parent reply	other threads:[~2022-12-21  6:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-20 15:47 [PATCH v6 0/2]Uwb: Nxp: Driver for SR1XX SOCs Patch Series Manjunatha Venkatesh
2022-12-20 15:47 ` [PATCH v6 1/2] dt-bindings: uwb: Device tree information for Nxp SR1XX SOCs Manjunatha Venkatesh
2022-12-20 15:56   ` Krzysztof Kozlowski
2022-12-20 16:40   ` Rob Herring
2022-12-20 15:47 ` [PATCH v6 2/2] misc: nxp-sr1xx: UWB driver support for sr1xx series chip Manjunatha Venkatesh
2022-12-20 15:58   ` Krzysztof Kozlowski
2022-12-21  6:12   ` Greg KH [this message]
2023-09-25 13:51     ` Guenter Roeck

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=Y6Kj4VlnJFFrzYW9@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.d \
    --cc=ashish.deshpande@nxp.com \
    --cc=axboe@kernel.dk \
    --cc=bjorn.andersson@linaro.org \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jasowang@redhat.com \
    --cc=javier@javigon.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kwame.adwere@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manjunatha.venkatesh@nxp.com \
    --cc=mb@lightnvm.io \
    --cc=mikelley@microsoft.com \
    --cc=mst@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=rvmanjumce@gmail.com \
    --cc=sunilmut@microsoft.com \
    --cc=will@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

all inboxes | Powered by JetHome®