All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gabriel L. Somlo" <gsomlo@gmail.com>
To: Stafford Horne <shorne@gmail.com>
Cc: linux-kernel@vger.kernel.org, kgugala@antmicro.com,
	mholenko@antmicro.com, pczarnecki@internships.antmicro.com,
	davidgow@google.com, florent@enjoy-digital.fr, joel@jms.id.au
Subject: Re: [PATCH] drivers/soc/litex: remove 8-bit subregister option
Date: Wed, 26 May 2021 06:47:31 -0400	[thread overview]
Message-ID: <YK4nQ9lnJXrKAWSE@errol.ini.cmu.edu> (raw)
In-Reply-To: <YKhF4x/vOTmGTnB9@antec>

On Sat, May 22, 2021 at 08:44:35AM +0900, Stafford Horne wrote:
> On Fri, May 21, 2021 at 02:36:21PM -0400, Gabriel Somlo wrote:
> > Since upstream LiteX recommends that Linux support be limited to
> > designs configured with 32-bit CSR subregisters (see commit a2b71fde
> > in upstream LiteX, https://github.com/enjoy-digital/litex), remove
> > the option to select 8-bit subregisters, significantly reducing the
> > complexity of LiteX CSR (MMIO register) accessor methods.
> > 
> > NOTE: for details on the underlying mechanics of LiteX CSR registers,
> > see https://github.com/enjoy-digital/litex/wiki/CSR-Bus or the original
> > LiteX accessors (litex/soc/software/include/hw/common.h in the upstream
> > repository).
> > 
> > Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
> > Cc: Stafford Horne <shorne@gmail.com>
> > Cc: Florent Kermarrec <florent@enjoy-digital.fr>
> > Cc: Mateusz Holenko <mholenko@antmicro.com>
> > Cc: Joel Stanley <joel@jms.id.au>
> > 
> > ---
> >  drivers/soc/litex/Kconfig |  12 -----
> >  include/linux/litex.h     | 100 +++++++-------------------------------
> >  2 files changed, 17 insertions(+), 95 deletions(-)
> 
> ...
> 
> >  static inline void litex_write64(void __iomem *reg, u64 val)
> >  {
> > -	_litex_set_reg(reg, sizeof(u64), val);
> > +	_write_litex_subregister(val >> LITEX_SUBREG_SIZE_BIT, reg);
> > +	_write_litex_subregister(val, reg + LITEX_SUBREG_ALIGN);
> >  }
> 
> I wonder if it would be more clear to remove the macros and just write as:
> 
> static inline void litex_write64(void __iomem *reg, u64 val)
> {
> 	_litex_set_reg(reg, sizeof(u64), val);
> 	_write_litex_subregister(val >> 32, reg);
> 	_write_litex_subregister(val, reg + 0x4);
> }
> 
> >  static inline u8 litex_read8(void __iomem *reg)
> >  {
> > -	return _litex_get_reg(reg, sizeof(u8));
> > +	return _read_litex_subregister(reg);
> >  }
> >  
> >  static inline u16 litex_read16(void __iomem *reg)
> >  {
> > -	return _litex_get_reg(reg, sizeof(u16));
> > +	return _read_litex_subregister(reg);
> >  }
> >  
> >  static inline u32 litex_read32(void __iomem *reg)
> >  {
> > -	return _litex_get_reg(reg, sizeof(u32));
> > +	return _read_litex_subregister(reg);
> >  }
> >  
> >  static inline u64 litex_read64(void __iomem *reg)
> >  {
> > -	return _litex_get_reg(reg, sizeof(u64));
> > +	return ((u64)_read_litex_subregister(reg) << LITEX_SUBREG_SIZE_BIT) |
> > +		_read_litex_subregister(reg + LITEX_SUBREG_ALIGN);
> >  }
> 
> Same here.
> 
> This all looks good to me.  Just a bit of style preference/question for
> discussion, for me it's easier to read without the macro's but it just may be
> me.  The macro's make sense when they could change, but now it's just something
> to double check when reading the code.
> 
> Though they are used here in the init code which we could remove too now:
> 
>         pr_info("LiteX SoC Controller driver initialized: subreg:%d, align:%d",
>                 LITEX_SUBREG_SIZE, LITEX_SUBREG_ALIGN);

Since nobody else seems to have any strong feelings on the topic, I'll
just send out a v2 with the changes suggested above in a few minutes.

Thanks,
--Gabriel

      reply	other threads:[~2021-05-26 10:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 18:36 [PATCH] drivers/soc/litex: remove 8-bit subregister option Gabriel Somlo
2021-05-21 23:44 ` Stafford Horne
2021-05-26 10:47   ` Gabriel L. Somlo [this message]

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=YK4nQ9lnJXrKAWSE@errol.ini.cmu.edu \
    --to=gsomlo@gmail.com \
    --cc=davidgow@google.com \
    --cc=florent@enjoy-digital.fr \
    --cc=joel@jms.id.au \
    --cc=kgugala@antmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mholenko@antmicro.com \
    --cc=pczarnecki@internships.antmicro.com \
    --cc=shorne@gmail.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 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.