linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Mark Brown <broonie@kernel.org>
Cc: linux-can@vger.kernel.org, manivannan.sadhasivam@linaro.org,
	dev.kurt@vandijck-laurijssen.be
Subject: Re: [PATCH v53 2/6] can: mcp25xxfd: add regmap infrastructure
Date: Tue, 22 Sep 2020 07:57:49 +0200	[thread overview]
Message-ID: <1ae4a116-c741-fcb6-7ef7-110fd0c8c771@pengutronix.de> (raw)
In-Reply-To: <20200921193302.GA45062@sirena.org.uk>


[-- Attachment #1.1: Type: text/plain, Size: 2407 bytes --]

On 9/21/20 9:33 PM, Mark Brown wrote:
> On Fri, Sep 18, 2020 at 07:25:32PM +0200, Marc Kleine-Budde wrote:
> 
>> +static int
>> +mcp25xxfd_regmap_nocrc_update_bits(void *context, unsigned int reg,
>> +				   unsigned int mask, unsigned int val)
>> +{
> 
> This doesn't look like the hardware has an update_bits() operation so
> why is there a driver specific implementation?

It's an optimization.

The registers of the device are 32 bits in general, but support 8 bit read/write
operations. So if only bits in the e.g. 2nd 8 bit are changed, both in the read
and write operation we can save 3 bytes.

Further in some registers the driver only changes all writeable bits in the
respective 8bit part of the register at the same time. This means we can skip
the read completely.

>> +static int
>> +mcp25xxfd_regmap_init_nocrc(struct mcp25xxfd_priv *priv)
>> +{
>> +	if (!priv->map_nocrc) {
>> +		struct regmap *map;
>> +
>> +		map = devm_regmap_init(&priv->spi->dev, &mcp25xxfd_bus_nocrc,
>> +				       priv->spi, &mcp25xxfd_regmap_nocrc);
> 
> Why all these checks to see if things might already be allocated?
> 
>> +static void mcp25xxfd_regmap_destroy_nocrc(struct mcp25xxfd_priv *priv)
>> +{
>> +	if (priv->map_buf_nocrc_rx) {
>> +		devm_kfree(&priv->spi->dev, priv->map_buf_nocrc_rx);
>> +		priv->map_buf_nocrc_rx = NULL;
>> +	}
> 
> Why explicitly free managed allocations like this?

The driver covers two chips, the mcp2517fd and the mcp2518fd. Due to erratas we
need different quirks for these variants. Further you can configure if regmap
should use transfers with or without CRC checks (separately for register access,
RAM access in RX and TX path).

It's possible to distinguish between chip variants by reading/writing a
register, so we first init the regmap with CRC mode, autodetect the chip
variant, and then re-init the regmap with the quirks of that detected variant.

The mcp25xxfd regmap init is written so that resources that are allocated first,
but not needed due to different quirks are then freed (both regmap and the
buffers for rx/tx).

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-09-22  5:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-18 17:25 [PATCH v53 1/6] mcp25xxfd: initial driver support Marc Kleine-Budde
2020-09-18 17:25 ` [PATCH v53 1/6] dt-binding: can: mcp25xxfd: document device tree bindings Marc Kleine-Budde
2020-09-18 17:25 ` [PATCH v53 2/6] can: mcp25xxfd: add regmap infrastructure Marc Kleine-Budde
2020-09-21 19:33   ` Mark Brown
2020-09-22  5:57     ` Marc Kleine-Budde [this message]
2020-09-22 12:13       ` Mark Brown
2020-09-22 13:56         ` Marc Kleine-Budde
2020-09-22 14:23           ` Mark Brown
2020-09-18 17:25 ` [PATCH v53 3/6] can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN Marc Kleine-Budde
2020-09-18 17:25 ` [PATCH v53 4/6] can: mcp25xxfd: add listen-only mode Marc Kleine-Budde
2020-09-18 17:25 ` [PATCH v53 5/6] MAINTAINERS: Add entry for Microchip MCP25XXFD SPI-CAN network driver Marc Kleine-Budde
2020-09-18 17:25 ` [PATCH v53 6/6] MAINTAINERS: Add reviewer entry for microchip mcp25xxfd " Marc Kleine-Budde

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=1ae4a116-c741-fcb6-7ef7-110fd0c8c771@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=broonie@kernel.org \
    --cc=dev.kurt@vandijck-laurijssen.be \
    --cc=linux-can@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.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).