All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Chris Morgan <macroalpha82@gmail.com>
Cc: alsa-devel@alsa-project.org, lgirdwood@gmail.com,
	pierre-louis.bossart@linux.intel.com, tiwai@suse.com,
	heiko@sntech.de, lee.jones@linaro.org, robh+dt@kernel.org,
	perex@perex.cz, jbx6244@gmail.com, devicetree@vger.kernel.org,
	linux-rockchip@lists.infradead.org, maccraft123mc@gmail.com,
	Chris Morgan <macromorgan@hotmail.com>
Subject: Re: [PATCH v10 2/4] ASoC: Add Rockchip rk817 audio CODEC support
Date: Fri, 14 May 2021 20:58:35 +0100	[thread overview]
Message-ID: <20210514195835.GD6516@sirena.org.uk> (raw)
In-Reply-To: <20210514183324.GA20917@wintermute.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

On Fri, May 14, 2021 at 01:33:24PM -0500, Chris Morgan wrote:
> On Fri, May 14, 2021 at 06:49:58PM +0100, Mark Brown wrote:

> > > +	if (!node) {
> > > +		dev_err(dev, "%s() dev->parent->of_node is NULL\n",
> > > +			__func__);

> > There's no need to fail the probe here, you won't be able to read any DT
> > properties but that shouldn't stop the driver binding.

> If I'm not mistaken this is actually telling us to fail if the parent
> device (the PMIC itself) isn't present. I think I'll remove this as not
> necessary since if the parent node isn't present the mfd driver will
> never load, meaning this driver will never load either.

So it is - I edited incorrectly when I went to reply.

> Below this line however we're failing if the codec node isn't present.
> Are you telling me we want to bind the driver if the node isn't present
> (such as in the edge case where the driver is present and the PMIC is a
> rk817, but the CODEC is not in use)? I will remove the return code if

Yes.

> you think that is what needs to be done. My concern there though is if
> we do that we'll either be in a position to again report a bunch of
> errors for the edge case of users who want to use the PMIC but not the
> codec (in this case missing clocks and whatnot) if we try to bind the

Why would there be any errors?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Chris Morgan <macroalpha82@gmail.com>
Cc: pierre-louis.bossart@linux.intel.com,
	alsa-devel@alsa-project.org, heiko@sntech.de,
	devicetree@vger.kernel.org, tiwai@suse.com, lgirdwood@gmail.com,
	linux-rockchip@lists.infradead.org, robh+dt@kernel.org,
	Chris Morgan <macromorgan@hotmail.com>,
	jbx6244@gmail.com, lee.jones@linaro.org, maccraft123mc@gmail.com
Subject: Re: [PATCH v10 2/4] ASoC: Add Rockchip rk817 audio CODEC support
Date: Fri, 14 May 2021 20:58:35 +0100	[thread overview]
Message-ID: <20210514195835.GD6516@sirena.org.uk> (raw)
In-Reply-To: <20210514183324.GA20917@wintermute.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

On Fri, May 14, 2021 at 01:33:24PM -0500, Chris Morgan wrote:
> On Fri, May 14, 2021 at 06:49:58PM +0100, Mark Brown wrote:

> > > +	if (!node) {
> > > +		dev_err(dev, "%s() dev->parent->of_node is NULL\n",
> > > +			__func__);

> > There's no need to fail the probe here, you won't be able to read any DT
> > properties but that shouldn't stop the driver binding.

> If I'm not mistaken this is actually telling us to fail if the parent
> device (the PMIC itself) isn't present. I think I'll remove this as not
> necessary since if the parent node isn't present the mfd driver will
> never load, meaning this driver will never load either.

So it is - I edited incorrectly when I went to reply.

> Below this line however we're failing if the codec node isn't present.
> Are you telling me we want to bind the driver if the node isn't present
> (such as in the edge case where the driver is present and the PMIC is a
> rk817, but the CODEC is not in use)? I will remove the return code if

Yes.

> you think that is what needs to be done. My concern there though is if
> we do that we'll either be in a position to again report a bunch of
> errors for the edge case of users who want to use the PMIC but not the
> codec (in this case missing clocks and whatnot) if we try to bind the

Why would there be any errors?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Chris Morgan <macroalpha82@gmail.com>
Cc: alsa-devel@alsa-project.org, lgirdwood@gmail.com,
	pierre-louis.bossart@linux.intel.com, tiwai@suse.com,
	heiko@sntech.de, lee.jones@linaro.org, robh+dt@kernel.org,
	perex@perex.cz, jbx6244@gmail.com, devicetree@vger.kernel.org,
	linux-rockchip@lists.infradead.org, maccraft123mc@gmail.com,
	Chris Morgan <macromorgan@hotmail.com>
Subject: Re: [PATCH v10 2/4] ASoC: Add Rockchip rk817 audio CODEC support
Date: Fri, 14 May 2021 20:58:35 +0100	[thread overview]
Message-ID: <20210514195835.GD6516@sirena.org.uk> (raw)
In-Reply-To: <20210514183324.GA20917@wintermute.localdomain>


[-- Attachment #1.1: Type: text/plain, Size: 1317 bytes --]

On Fri, May 14, 2021 at 01:33:24PM -0500, Chris Morgan wrote:
> On Fri, May 14, 2021 at 06:49:58PM +0100, Mark Brown wrote:

> > > +	if (!node) {
> > > +		dev_err(dev, "%s() dev->parent->of_node is NULL\n",
> > > +			__func__);

> > There's no need to fail the probe here, you won't be able to read any DT
> > properties but that shouldn't stop the driver binding.

> If I'm not mistaken this is actually telling us to fail if the parent
> device (the PMIC itself) isn't present. I think I'll remove this as not
> necessary since if the parent node isn't present the mfd driver will
> never load, meaning this driver will never load either.

So it is - I edited incorrectly when I went to reply.

> Below this line however we're failing if the codec node isn't present.
> Are you telling me we want to bind the driver if the node isn't present
> (such as in the edge case where the driver is present and the PMIC is a
> rk817, but the CODEC is not in use)? I will remove the return code if

Yes.

> you think that is what needs to be done. My concern there though is if
> we do that we'll either be in a position to again report a bunch of
> errors for the edge case of users who want to use the PMIC but not the
> codec (in this case missing clocks and whatnot) if we try to bind the

Why would there be any errors?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2021-05-14 19:59 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14 17:19 [PATCH v10 0/4] ASoC: codecs: add rk817 support Chris Morgan
2021-05-14 17:19 ` Chris Morgan
2021-05-14 17:19 ` Chris Morgan
2021-05-14 17:19 ` [PATCH v10 1/4] mfd: Add Rockchip rk817 audio CODEC support Chris Morgan
2021-05-14 17:19   ` Chris Morgan
2021-05-14 17:19   ` Chris Morgan
2021-05-14 17:19 ` [PATCH v10 2/4] ASoC: " Chris Morgan
2021-05-14 17:19   ` Chris Morgan
2021-05-14 17:19   ` Chris Morgan
2021-05-14 17:49   ` Mark Brown
2021-05-14 17:49     ` Mark Brown
2021-05-14 17:49     ` Mark Brown
2021-05-14 18:33     ` Chris Morgan
2021-05-14 18:33       ` Chris Morgan
2021-05-14 18:33       ` Chris Morgan
2021-05-14 19:58       ` Mark Brown [this message]
2021-05-14 19:58         ` Mark Brown
2021-05-14 19:58         ` Mark Brown
2021-05-14 21:04         ` Chris Morgan
2021-05-14 21:04           ` Chris Morgan
2021-05-14 21:04           ` Chris Morgan
2021-05-14 17:19 ` [PATCH v10 3/4] dt-bindings: " Chris Morgan
2021-05-14 17:19   ` Chris Morgan
2021-05-14 17:19   ` Chris Morgan
2021-05-14 17:19 ` [PATCH v10 4/4] arm64: dts: rockchip: add rk817 codec to Odroid Go Chris Morgan
2021-05-14 17:19   ` Chris Morgan
2021-05-14 17:19   ` Chris Morgan

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=20210514195835.GD6516@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=jbx6244@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=maccraft123mc@gmail.com \
    --cc=macroalpha82@gmail.com \
    --cc=macromorgan@hotmail.com \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=robh+dt@kernel.org \
    --cc=tiwai@suse.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.