linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-mtd@lists.infradead.org, "Rafał Miłecki" <zajec5@gmail.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"Brian Norris" <computersforpeace@gmail.com>,
	"Kamal Dasu" <kdasu.kdev@gmail.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Cai Huoqing" <caihuoqing@baidu.com>,
	"Colin Ian King" <colin.king@intel.com>,
	"open list" <linux-kernel@vger.kernel.org>,
	"open list:BROADCOM SPECIFIC AMBA DRIVER (BCMA)"
	<linux-wireless@vger.kernel.org>,
	"open list:BROADCOM STB NAND FLASH DRIVER"
	<bcm-kernel-feedback-list@broadcom.com>
Subject: Re: [PATCH 1/9] mtd: rawnand: brcmnand: Allow SoC to provide I/O operations
Date: Tue, 4 Jan 2022 09:32:21 +0100	[thread overview]
Message-ID: <20220104093221.6414aab9@xps13> (raw)
In-Reply-To: <299bf6ed-80e6-ad15-8dc7-5ededaca15c5@gmail.com>

Hi Florian,

f.fainelli@gmail.com wrote on Mon, 3 Jan 2022 09:24:26 -0800:

> On 1/3/2022 8:49 AM, Miquel Raynal wrote:
> > Hi Florian,
> > 
> > f.fainelli@gmail.com wrote on Wed, 22 Dec 2021 16:22:17 -0800:
> >   
> >> Allow a brcmnand_soc instance to provide a custom set of I/O operations
> >> which we will require when using this driver on a BCMA bus which is not
> >> directly memory mapped I/O. Update the nand_{read,write}_reg accordingly
> >> to use the SoC operations if provided.
> >>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> ---
> >>   drivers/mtd/nand/raw/brcmnand/brcmnand.c | 14 ++++++++++++--
> >>   drivers/mtd/nand/raw/brcmnand/brcmnand.h | 23 +++++++++++++++++++++++
> >>   2 files changed, 35 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> index f75929783b94..7a1673b1b1af 100644
> >> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> @@ -594,13 +594,18 @@ enum {  
> >>   >>   static inline u32 nand_readreg(struct brcmnand_controller *ctrl, u32 offs)  
> >>   {
> >> +	if (brcmnand_soc_has_ops(ctrl->soc))
> >> +		return brcmnand_soc_read(ctrl->soc, offs);
> >>   	return brcmnand_readl(ctrl->nand_base + offs);
> >>   }  
> >>   >>   static inline void nand_writereg(struct brcmnand_controller *ctrl, u32 offs,  
> >>   				 u32 val)
> >>   {
> >> -	brcmnand_writel(val, ctrl->nand_base + offs);
> >> +	if (brcmnand_soc_has_ops(ctrl->soc))
> >> +		brcmnand_soc_write(ctrl->soc, val, offs);
> >> +	else
> >> +		brcmnand_writel(val, ctrl->nand_base + offs);
> >>   }  
> >>   >>   static int brcmnand_revision_init(struct brcmnand_controller *ctrl)  
> >> @@ -766,13 +771,18 @@ static inline void brcmnand_rmw_reg(struct brcmnand_controller *ctrl,  
> >>   >>   static inline u32 brcmnand_read_fc(struct brcmnand_controller *ctrl, int word)  
> >>   {
> >> +	if (brcmnand_soc_has_ops(ctrl->soc))
> >> +		return brcmnand_soc_read(ctrl->soc, ~0);
> >>   	return __raw_readl(ctrl->nand_fc + word * 4);
> >>   }  
> >>   >>   static inline void brcmnand_write_fc(struct brcmnand_controller *ctrl,  
> >>   				     int word, u32 val)
> >>   {
> >> -	__raw_writel(val, ctrl->nand_fc + word * 4);
> >> +	if (brcmnand_soc_has_ops(ctrl->soc))
> >> +		brcmnand_soc_write(ctrl->soc, val, ~0);
> >> +	else
> >> +		__raw_writel(val, ctrl->nand_fc + word * 4);
> >>   }  
> >>   >>   static inline void edu_writel(struct brcmnand_controller *ctrl,  
> >> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.h b/drivers/mtd/nand/raw/brcmnand/brcmnand.h
> >> index eb498fbe505e..a3f2ad5f6572 100644
> >> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.h
> >> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.h
> >> @@ -11,12 +11,19 @@  
> >>   >>   struct platform_device;  
> >>   struct dev_pm_ops;
> >> +struct brcmnand_io_ops;  
> >>   >>   struct brcmnand_soc {  
> >>   	bool (*ctlrdy_ack)(struct brcmnand_soc *soc);
> >>   	void (*ctlrdy_set_enabled)(struct brcmnand_soc *soc, bool en);
> >>   	void (*prepare_data_bus)(struct brcmnand_soc *soc, bool prepare,
> >>   				 bool is_param);
> >> +	const struct brcmnand_io_ops *ops;
> >> +};
> >> +
> >> +struct brcmnand_io_ops {
> >> +	u32 (*read_reg)(struct brcmnand_soc *soc, u32 offset);
> >> +	void (*write_reg)(struct brcmnand_soc *soc, u32 val, u32 offset);
> >>   };  
> >>   >>   static inline void brcmnand_soc_data_bus_prepare(struct brcmnand_soc *soc,  
> >> @@ -58,6 +65,22 @@ static inline void brcmnand_writel(u32 val, void __iomem *addr)
> >>   		writel_relaxed(val, addr);
> >>   }  
> >>   >> +static inline bool brcmnand_soc_has_ops(struct brcmnand_soc *soc)  
> >> +{
> >> +	return soc && soc->ops && soc->ops->read_reg && soc->ops->write_reg;
> >> +}
> >> +
> >> +static inline u32 brcmnand_soc_read(struct brcmnand_soc *soc, u32 offset)
> >> +{
> >> +	return soc->ops->read_reg(soc, offset);
> >> +}
> >> +
> >> +static inline void brcmnand_soc_write(struct brcmnand_soc *soc, u32 val,
> >> +				      u32 offset)
> >> +{
> >> +	soc->ops->write_reg(soc, val, offset);
> >> +}
> >> +  
> > 
> > It might be worth looking into more optimized ways to do these checks,
> > in particular the read/write_reg ones because you're checking against
> > some static data which cannot be optimized out by the compiler but
> > won't change in the lifetime of the kernel.  
> 
> I suppose I could add an addition if IS_ENABLED(CONFIG_MTD_NAND_BRCMNAND_BCMA) at the front of brcmnand_soc_has_ops(), would that address your concern or you have something else in mind?

I don't like much the #ifdef solution, instead you might think of
static keys, or even better using a regmap. Regmap implementation is
free, you can use either one way or the other and for almost no
overhead compared to the bunch of functions you have here.

Thanks,
Miquèl

  reply	other threads:[~2022-01-04  8:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-23  0:22 [PATCH 0/9] BCMA support for brcmnand Florian Fainelli
2021-12-23  0:22 ` [PATCH 1/9] mtd: rawnand: brcmnand: Allow SoC to provide I/O operations Florian Fainelli
2022-01-03 16:49   ` Miquel Raynal
2022-01-03 17:24     ` Florian Fainelli
2022-01-04  8:32       ` Miquel Raynal [this message]
2022-01-04  8:57         ` Miquel Raynal
2022-01-04 18:34           ` Florian Fainelli
2022-01-04 18:37             ` Miquel Raynal
2021-12-23  0:22 ` [PATCH 2/9] mtd: rawnand: brcmnand: Assign soc as early as possible Florian Fainelli
2021-12-23  0:22 ` [PATCH 3/9] mtd: rawnand: brcmnand: Avoid pdev in brcmnand_init_cs() Florian Fainelli
2021-12-23  0:22 ` [PATCH 4/9] mtd: rawnand: brcmnand: Move OF operations out of brcmnand_init_cs() Florian Fainelli
2022-01-03 16:56   ` Miquel Raynal
2022-01-03 17:27     ` Florian Fainelli
2022-01-04  8:30       ` Miquel Raynal
2021-12-23  0:22 ` [PATCH 5/9] mtd: rawnand: brcmnand: Allow working without interrupts Florian Fainelli
2021-12-25 17:45   ` Andy Shevchenko
2021-12-27 17:05     ` Florian Fainelli
2021-12-23  0:22 ` [PATCH 6/9] mtd: rawnand: brcmnand: Add platform data structure for BCMA Florian Fainelli
2021-12-23  0:22 ` [PATCH 7/9] mtd: rawnand: brcmnand: Allow platform data instantation Florian Fainelli
2021-12-23  0:22 ` [PATCH 8/9] mtd: rawnand: brcmnand: BCMA controller uses command shift of 0 Florian Fainelli
2021-12-23  0:22 ` [PATCH 9/9] mtd: rawnand: brcmnand: Add BCMA shim Florian Fainelli
2022-01-03 17:06   ` Miquel Raynal
2022-01-03 17:28     ` Florian Fainelli
2022-01-03 17:12   ` Miquel Raynal
2022-01-03 17:28     ` Florian Fainelli

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=20220104093221.6414aab9@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=caihuoqing@baidu.com \
    --cc=colin.king@intel.com \
    --cc=computersforpeace@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=kdasu.kdev@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    --cc=zajec5@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 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).