From: Greg KH <gregkh@linuxfoundation.org>
To: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com>
Cc: arnd@arndb.de, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, UNGLinuxDriver@microchip.com
Subject: Re: [PATCH v4 char-misc-next] misc: microchip: pci1xxxx: Add OTP/EEPROM driver for the pci1xxxx switch
Date: Thu, 9 Feb 2023 09:55:02 +0100 [thread overview]
Message-ID: <Y+S05tQ5e5pE9/v0@kroah.com> (raw)
In-Reply-To: <20230209044237.3927293-1-tharunkumar.pasumarthi@microchip.com>
On Thu, Feb 09, 2023 at 10:12:37AM +0530, Tharun Kumar P wrote:
> +static int e2p_device_write_byte(struct pci1xxxx_otp_e2p_device *priv,
> + unsigned long byte_offset, u8 value)
> +{
> + u32 data;
> +
> + /* Write the value into EEPROM_DATA_REG register */
> + writel(value, priv->reg_base + MMAP_EEPROM_OFFSET(EEPROM_DATA_REG));
> + data = EEPROM_CMD_EPC_TIMEOUT_BIT | EEPROM_CMD_EPC_WRITE | byte_offset;
> +
> + /* Write the data into EEPROM_CMD_REG register */
> + writel(data, priv->reg_base + MMAP_EEPROM_OFFSET(EEPROM_CMD_REG));
> +
> + /* Set the EPC_BUSY bit of EEPROM_CMD_REG register */
> + writel(EEPROM_CMD_EPC_BUSY_BIT | data, priv->reg_base +
> + MMAP_EEPROM_OFFSET(EEPROM_CMD_REG));
> +
> + /* Wait for the EPC_BUSY bit to get cleared */
> + do {
> + data = readl(priv->reg_base + MMAP_EEPROM_OFFSET(EEPROM_CMD_REG));
> + } while (data & EEPROM_CMD_EPC_BUSY_BIT);
That's a very busy "sit and spin" loop here, what happens if the read of
the bit never actually succeeds? You just locked up the system with no
way to interrupt it :(
Please provide some sort of timeout, or way to break out of this.
> +
> + if (data & EEPROM_CMD_EPC_TIMEOUT_BIT) {
> + dev_err(&priv->pdev->dev, "EEPROM write timed out\n");
How can the timeout bit happen if the busy bit was still set?
And what can userspace do about this if it is reported?
> + return -EFAULT;
This return value is ONLY for when we have memory faults from reading
to/from userspace and the kernel. It's not a valid return value for a
device error, sorry. -EIO maybe?
You return this error in a number of other places in the driver that
shouldn't, please fix this up.
Also the loop issue is in your read_byte call and the same review
comments apply there.
thanks,
greg k-h
next prev parent reply other threads:[~2023-02-09 8:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-09 4:42 Tharun Kumar P
2023-02-09 8:55 ` Greg KH [this message]
2023-02-11 5:07 ` Tharunkumar.Pasumarthi
2023-02-11 8:44 ` Greg KH
2023-02-11 13:43 ` Tharunkumar.Pasumarthi
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=Y+S05tQ5e5pE9/v0@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=UNGLinuxDriver@microchip.com \
--cc=arnd@arndb.de \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tharunkumar.pasumarthi@microchip.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
all inboxes | Powered by JetHome®