Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, patches.audio@intel.com,
	Hardik T Shah <hardik.t.shah@intel.com>,
	Guneshwor Singh <guneshwor.o.singh@intel.com>,
	liam.r.girdwood@linux.intel.com, broonie@kernel.org
Subject: Re: [PATCH v2 1/2] ALSA - hda: Add support for parsing new HDA capabilities
Date: Thu, 21 Jul 2016 09:54:26 +0530	[thread overview]
Message-ID: <20160721042426.GK9681@localhost> (raw)
In-Reply-To: <s5hlh0w98pm.wl-tiwai@suse.de>

On Wed, Jul 20, 2016 at 07:31:17AM +0200, Takashi Iwai wrote:

> > +	unsigned int offset; unsigned int counter = 0;
> 
> Need a line break.

arghh, will fix..

> > +	offset = azx_readl(chip, LLCH);
> > +
> > +	/* Lets walk the linked capabilities list */
> > +	do {
> > +		cur_cap = _snd_hdac_chip_read(l, azx_bus(chip), offset);
> > +
> > +		switch ((cur_cap & CAP_HDR_ID_MASK) >> CAP_HDR_ID_OFF) {
> > +		case GTS_CAP_ID:
> > +			dev_dbg(chip->card->dev, "Found GTS capability");
> > +			chip->gts_present = 1;
> > +			break;
> > +
> > +		default:
> > +			break;
> > +		}
> > +
> > +		counter++;
> > +
> > +		if (counter > AZX_MAX_CAPS) {
> > +			dev_err(chip->card->dev, "We exceeded azx capabilities!!!\n");
> > +			break;
> > +		}
> > +
> > +		/* read the offset of next capabiity */
> > +		offset = cur_cap & CAP_HDR_NXT_PTR_MASK;
> > +
> > +	} while (offset);
> 
> Wouldn't it be safer to use a normal while () {} loop?
> The first LLCH read might be zero, in theory.

Then in that case first read will give error. But yes I see the benifits.

Btw this is same as snd_hdac_ext_bus_parse_capabilities()

Should we move this to hdac and use for both. Ofcourse many new capablities
do not make sense to legacy driver, so we would have to ignore them.

> > +	if (!(chip->gts_present && boot_cpu_has(X86_FEATURE_ART)))
> > +		chip->gts_present = false;
> 
> Need #ifdef CONFIG_X86 guard here, too.
> Also, the inclusion of <asm/cpufeature.h> isn't needed?  (Again
> X86-only.)

This is intel.c :) I did compile it for ARM before sending.

-- 
~Vinod

  reply	other threads:[~2016-07-21  4:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 10:46 [PATCH v2 0/2] ALSA - hda: Add support for link audio time reporting Vinod Koul
2016-07-19 10:46 ` [PATCH v2 1/2] ALSA - hda: Add support for parsing new HDA capabilities Vinod Koul
2016-07-20  5:31   ` Takashi Iwai
2016-07-21  4:24     ` Vinod Koul [this message]
2016-07-21  5:08       ` Takashi Iwai
2016-07-19 10:46 ` [PATCH v2 2/2] ALSA - hda: Add support for link audio time reporting Vinod Koul
2016-07-20  5:36   ` Takashi Iwai
2016-07-21  4:25     ` Vinod Koul

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=20160721042426.GK9681@localhost \
    --to=vinod.koul@intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=guneshwor.o.singh@intel.com \
    --cc=hardik.t.shah@intel.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=patches.audio@intel.com \
    --cc=tiwai@suse.de \
    /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