alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: "Viorel Suman (OSS)" <viorel.suman@oss.nxp.com>
To: Mark Brown <broonie@kernel.org>,
	"Viorel Suman (OSS)" <viorel.suman@oss.nxp.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Matthias Schiffer <matthias.schiffer@ew.tq-group.com>,
	Timur Tabi <timur@kernel.org>, Xiubo Li <Xiubo.Lee@gmail.com>,
	Shengjiu Wang <shengjiu.wang@gmail.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Takashi Iwai <tiwai@suse.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Nicolin Chen <nicoleotsuka@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Viorel Suman <viorel.suman@gmail.com>,
	Cosmin-Gabriel Samoila <cosmin.samoila@nxp.com>,
	Fabio Estevam <festevam@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
Date: Fri, 18 Sep 2020 15:02:39 +0000	[thread overview]
Message-ID: <VI1PR0401MB22726CC099099547A0502C27923F0@VI1PR0401MB2272.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20200917135306.GF4755@sirena.org.uk>

Hi Mark,

Thank you for your review.
 
> On Wed, Sep 16, 2020 at 12:17:55PM +0300, Viorel Suman (OSS) wrote:
> > +static int fsl_xcvr_load_firmware(struct fsl_xcvr *xcvr) {
> > +	struct device *dev = &xcvr->pdev->dev;
> > +	const struct firmware *fw;
> > +	int ret = 0, rem, off, out, page = 0, size = FSL_XCVR_REG_OFFSET;
> > +	u32 mask, val;
> > +
> > +	ret = request_firmware(&fw, xcvr->fw_name, dev);
> > +	if (ret) {
> > +		dev_err(dev, "failed to request firmware.\n");
> > +		return ret;
> > +	}
> > +
> > +	rem = fw->size;
> 
> It would be good to see some explicit validation of the image size, at least
> printing an error message if the image is bigger than can be loaded.  The code
> should be safe in that it won't overflow the device region it's writing to but it
> feels like it'd be better to tell people if we spot a problem rather than just silently
> truncating the file.

Make sense, will improve this part in the next version.

> > +static irqreturn_t irq0_isr(int irq, void *devid) {
> > +	struct fsl_xcvr *xcvr = (struct fsl_xcvr *)devid;
> > +	struct device *dev = &xcvr->pdev->dev;
> > +	struct regmap *regmap = xcvr->regmap;
> > +	void __iomem *reg_ctrl, *reg_buff;
> > +	u32 isr, val, i;
> > +
> > +	regmap_read(regmap, FSL_XCVR_EXT_ISR, &isr);
> > +	regmap_write(regmap, FSL_XCVR_EXT_ISR_CLR, isr);
> 
> This will unconditionally clear any interrupts, even those we don't understand - it
> might be better to only clear bits that are supported so the IRQ core can
> complain if there's something unexpected showing up.

The ARM core registers itself in "fsl_xcvr_prepare" (the code below) just for a subset of all supported interrupts: 
=====
	ret = regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_IER0,
				 FSL_XCVR_IRQ_EARC_ALL, FSL_XCVR_IRQ_EARC_ALL);
=====
FSL_XCVR_IRQ_EARC_ALL - this mask represents all the interrupts we are interested in and we handle in interrupt handler,
But this is just a subset of all interrupts the M0+ core is able to assert. Not very intuitive, I think I need to reword it somehow.

> > +	if (isr & FSL_XCVR_IRQ_FIFO_UOFL_ERR)
> > +		dev_dbg(dev, "RX/TX FIFO full/empty\n");
> 
> Should this be dev_err()?

The interrupt may be asserted right before DMA starts to fill the TX FIFO if I recall correctly.
I've added it just to debug the IP behavior, will check and change it to err it in next version if it is the case.

> > +static irqreturn_t irq1_isr(int irq, void *devid) {
> > +	struct fsl_xcvr *xcvr = (struct fsl_xcvr *)devid;
> > +	struct device *dev = &xcvr->pdev->dev;
> > +
> > +	dev_dbg(dev, "irq[1]: %d\n", irq);
> > +
> > +	return IRQ_HANDLED;
> > +}
> 
> Is there any value in even requesting this and irq2 given the lack of meaningful
> handling?

No, will remove it in v2.

Thank you,
Viorel


  reply	other threads:[~2020-09-18 15:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16  9:17 [PATCH 0/2] DAI driver for new XCVR IP Viorel Suman (OSS)
2020-09-16  9:17 ` [PATCH 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver Viorel Suman (OSS)
2020-09-17  7:14   ` Nicolin Chen
2020-09-18 14:21     ` Viorel Suman (OSS)
2020-09-18 16:06       ` Timur Tabi
2020-09-17 13:53   ` Mark Brown
2020-09-18 15:02     ` Viorel Suman (OSS) [this message]
2020-09-18 15:20       ` Mark Brown
2020-09-18 15:33         ` Viorel Suman (OSS)
2020-09-16  9:17 ` [PATCH 2/2] ASoC: dt-bindings: fsl_xcvr: Add document for XCVR Viorel Suman (OSS)
2020-09-18 17:23   ` Rob Herring

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=VI1PR0401MB22726CC099099547A0502C27923F0@VI1PR0401MB2272.eurprd04.prod.outlook.com \
    --to=viorel.suman@oss.nxp.com \
    --cc=Xiubo.Lee@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cosmin.samoila@nxp.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=matthias.schiffer@ew.tq-group.com \
    --cc=nicoleotsuka@gmail.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=shengjiu.wang@gmail.com \
    --cc=timur@kernel.org \
    --cc=tiwai@suse.com \
    --cc=viorel.suman@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).