All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Marek Vasut <marex@denx.de>
Cc: netdev <netdev@vger.kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Tristram Ha <Tristram.Ha@microchip.com>,
	Woojung Huh <Woojung.Huh@microchip.com>
Subject: Re: [PATCH V3 07/10] net: dsa: microchip: Initial SPI regmap support
Date: Tue, 25 Jun 2019 15:40:53 +0300	[thread overview]
Message-ID: <CA+h21hot0TMh7G_BZ15DNXKTaxVv88B-8O7XpXPuqpNiQD5bxA@mail.gmail.com> (raw)
In-Reply-To: <f1dfe749-4bfa-17f7-ede7-f9bc38afa0d4@denx.de>

On Tue, 25 Jun 2019 at 15:06, Marek Vasut <marex@denx.de> wrote:
>
> On 6/25/19 1:59 AM, Vladimir Oltean wrote:
> > On Tue, 25 Jun 2019 at 01:17, Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 6/24/19 12:35 AM, Marek Vasut wrote:
> >>> Add basic SPI regmap support into the driver.
> >>>
> >>> Previous patches unconver that ksz_spi_write() is always ever called
> >>> with len = 1, 2 or 4. We can thus drop the if (len > SPI_TX_BUF_LEN)
> >>> check and we can also drop the allocation of the txbuf which is part
> >>> of the driver data and wastes 256 bytes for no reason. Regmap covers
> >>> the whole thing now.
> >>>
> >>> Signed-off-by: Marek Vasut <marex@denx.de>
> >>> Cc: Andrew Lunn <andrew@lunn.ch>
> >>> Cc: Florian Fainelli <f.fainelli@gmail.com>
> >>> Cc: Tristram Ha <Tristram.Ha@microchip.com>
> >>> Cc: Woojung Huh <Woojung.Huh@microchip.com>
> >>
> >> [...]
> >>
> >>> +#define KS_SPIOP_FLAG_MASK(opcode)           \
> >>> +     cpu_to_be32((opcode) << (SPI_ADDR_SHIFT + SPI_TURNAROUND_SHIFT))
> >>
> >> So the robot is complaining about this. I believe this is correct, as
> >> the mask should be in native endianness on the register and NOT the
> >> native endianness of the CPU.
> >>
> >> I think a cast would help here, e.g.:
> >> -       cpu_to_be32((opcode) << (SPI_ADDR_SHIFT + SPI_TURNAROUND_SHIFT))
> >> -       (__force unsigned long)cpu_to_be32((opcode) << (SPI_ADDR_SHIFT +
> >> SPI_TURNAROUND_SHIFT))
> >>
> >> Does this make sense ?
> >>
> >>> +#define KSZ_REGMAP_COMMON(width)                                     \
> >>> +     {                                                               \
> >>> +             .val_bits = (width),                                    \
> >>> +             .reg_stride = (width) / 8,                              \
> >>> +             .reg_bits = SPI_ADDR_SHIFT + SPI_ADDR_ALIGN,            \
> >>> +             .pad_bits = SPI_TURNAROUND_SHIFT,                       \
> >>> +             .max_register = BIT(SPI_ADDR_SHIFT) - 1,                \
> >>> +             .cache_type = REGCACHE_NONE,                            \
> >>> +             .read_flag_mask = KS_SPIOP_FLAG_MASK(KS_SPIOP_RD),      \
> >>> +             .write_flag_mask = KS_SPIOP_FLAG_MASK(KS_SPIOP_WR),     \
> >>
> >> [...]
> >>
> >> --
> >> Best regards,
> >> Marek Vasut
> >
> > Hi Marek,
> >
> > I saw SPI buffers and endianness and got triggered :)
> > Would it make sense to take a look at CONFIG_PACKING for the KSZ9477 driver?
> > I don't know how bad the field alignment issue is on that hardware,
> > but on SJA1105 it was such a disaster that I couldn't have managed it
> > any other way.
>
> How does that help me here ? All I really need is a static constant mask
> for the register/flags , 32bit for KSZ9xxx and 16bit for KSZ87xx. I
> don't need any dynamic stuff, luckily.
>

Ok. I was thinking *instead of* regmap.
On the SJA1105 I couldn't use a spi regmap because:
* the enum regmap_endian wasn't enough to describe the hardware's bit
layout (it is big endian, but high-order and low-order 32 bit words
are swapped)
* it doesn't really expose a well-defined register map, but rather,
you're supposed to dynamically construct a TLV-type buffer and write
it starting with a fixed address.
I just thought you were facing some of these problems as well with
regmap. If not, that's perfectly fine!

> But I'm glad to see TJA1105 driver mainline :)
>
> --
> Best regards,
> Marek Vasut

Regards,
-Vladimir

  reply	other threads:[~2019-06-25 12:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-23 22:34 [PATCH V3 00/10] net: dsa: microchip: Convert to regmap Marek Vasut
2019-06-23 22:34 ` [PATCH V3 01/10] net: dsa: microchip: Remove ksz_{read,write}24() Marek Vasut
2019-06-24  3:11   ` Andrew Lunn
2019-06-23 22:35 ` [PATCH V3 02/10] net: dsa: microchip: Remove ksz_{get,set}() Marek Vasut
2019-06-24  3:12   ` Andrew Lunn
2019-06-23 22:35 ` [PATCH V3 03/10] net: dsa: microchip: Inline ksz_spi.h Marek Vasut
2019-06-24  3:16   ` Andrew Lunn
2019-06-23 22:35 ` [PATCH V3 04/10] net: dsa: microchip: Move ksz_cfg and ksz_port_cfg to ksz9477.c Marek Vasut
2019-06-24  3:17   ` Andrew Lunn
2019-06-23 22:35 ` [PATCH V3 05/10] net: dsa: microchip: Use PORT_CTRL_ADDR() instead of indirect function call Marek Vasut
2019-06-24  3:20   ` Andrew Lunn
2019-06-24 22:12     ` Marek Vasut
2019-06-23 22:35 ` [PATCH V3 06/10] net: dsa: microchip: Factor out register access opcode generation Marek Vasut
2019-06-24  3:22   ` Andrew Lunn
2019-06-23 22:35 ` [PATCH V3 07/10] net: dsa: microchip: Initial SPI regmap support Marek Vasut
2019-06-24 19:39   ` kbuild test robot
2019-06-24 22:03   ` Marek Vasut
2019-06-24 23:59     ` Vladimir Oltean
2019-06-25 12:06       ` Marek Vasut
2019-06-25 12:40         ` Vladimir Oltean [this message]
2019-06-25 15:18           ` Marek Vasut
2019-06-25 10:03   ` kbuild test robot
2019-06-23 22:35 ` [PATCH V3 08/10] net: dsa: microchip: Dispose of ksz_io_ops Marek Vasut
2019-06-23 22:35 ` [PATCH V3 09/10] net: dsa: microchip: Factor out regmap config generation into common header Marek Vasut
2019-06-23 22:35 ` [PATCH V3 10/10] net: dsa: microchip: Replace ad-hoc bit manipulation with regmap Marek Vasut

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=CA+h21hot0TMh7G_BZ15DNXKTaxVv88B-8O7XpXPuqpNiQD5bxA@mail.gmail.com \
    --to=olteanv@gmail.com \
    --cc=Tristram.Ha@microchip.com \
    --cc=Woojung.Huh@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=marex@denx.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.