All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: alsa-devel@alsa-project.org, patches@opensource.cirrus.com,
	pierre-louis.bossart@linux.intel.com,
	linux-kernel@vger.kernel.org, sanyog.r.kale@intel.com,
	yung-chuan.liao@linux.intel.com
Subject: Re: [PATCH v3 2/4] soundwire: Provide build stubs for common functions
Date: Thu, 24 Nov 2022 15:02:01 +0530	[thread overview]
Message-ID: <Y386ERSr1EmkTYwk@matsya> (raw)
In-Reply-To: <20221124092231.GD105268@ediswmail.ad.cirrus.com>

On 24-11-22, 09:22, Charles Keepax wrote:
> On Thu, Nov 24, 2022 at 10:21:32AM +0530, Vinod Koul wrote:
> > On 21-11-22, 14:14, Charles Keepax wrote:
> > > Provide stub functions when CONFIG_SOUNDWIRE is not set for functions
> > > that are quite likely to be used from common code on devices supporting
> > > multiple control buses.
> > > 
> > > Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> > > Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> > > ---
> > > +static inline int sdw_stream_add_slave(struct sdw_slave *slave,
> > > +				       struct sdw_stream_config *stream_config,
> > > +				       struct sdw_port_config *port_config,
> > > +				       unsigned int num_ports,
> > > +				       struct sdw_stream_runtime *stream)
> > > +{
> > > +	return 0;
> > 
> > Should this and other here not return error...? Indicating sdw is not
> > available..? Silently ignoring may not be very helpful in debugging
> > 
> 
> Yeah I was a little unsure which way to go on that, in the end I
> opted for returning zero as it was more likely code would get
> optimised out. But I am happy to switch to returning an error, it
> would as you say making debugging misconfigurations easier.
> -ENOSYS seems kinda reasonable I think.

Right, -ENOSYS seems to be apt here

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org>
To: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: yung-chuan.liao@linux.intel.com,
	pierre-louis.bossart@linux.intel.com, sanyog.r.kale@intel.com,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	patches@opensource.cirrus.com
Subject: Re: [PATCH v3 2/4] soundwire: Provide build stubs for common functions
Date: Thu, 24 Nov 2022 15:02:01 +0530	[thread overview]
Message-ID: <Y386ERSr1EmkTYwk@matsya> (raw)
In-Reply-To: <20221124092231.GD105268@ediswmail.ad.cirrus.com>

On 24-11-22, 09:22, Charles Keepax wrote:
> On Thu, Nov 24, 2022 at 10:21:32AM +0530, Vinod Koul wrote:
> > On 21-11-22, 14:14, Charles Keepax wrote:
> > > Provide stub functions when CONFIG_SOUNDWIRE is not set for functions
> > > that are quite likely to be used from common code on devices supporting
> > > multiple control buses.
> > > 
> > > Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> > > Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> > > ---
> > > +static inline int sdw_stream_add_slave(struct sdw_slave *slave,
> > > +				       struct sdw_stream_config *stream_config,
> > > +				       struct sdw_port_config *port_config,
> > > +				       unsigned int num_ports,
> > > +				       struct sdw_stream_runtime *stream)
> > > +{
> > > +	return 0;
> > 
> > Should this and other here not return error...? Indicating sdw is not
> > available..? Silently ignoring may not be very helpful in debugging
> > 
> 
> Yeah I was a little unsure which way to go on that, in the end I
> opted for returning zero as it was more likely code would get
> optimised out. But I am happy to switch to returning an error, it
> would as you say making debugging misconfigurations easier.
> -ENOSYS seems kinda reasonable I think.

Right, -ENOSYS seems to be apt here

-- 
~Vinod

  reply	other threads:[~2022-11-24  9:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 14:14 [PATCH v3 0/4] Minor SoundWire clean ups Charles Keepax
2022-11-21 14:14 ` Charles Keepax
2022-11-21 14:14 ` [PATCH v3 1/4] soundwire: bus: export sdw_nwrite_no_pm and sdw_nread_no_pm functions Charles Keepax
2022-11-21 14:14   ` Charles Keepax
2022-11-21 14:14 ` [PATCH v3 2/4] soundwire: Provide build stubs for common functions Charles Keepax
2022-11-21 14:14   ` Charles Keepax
2022-11-24  4:51   ` Vinod Koul
2022-11-24  4:51     ` Vinod Koul
2022-11-24  9:22     ` Charles Keepax
2022-11-24  9:22       ` Charles Keepax
2022-11-24  9:32       ` Vinod Koul [this message]
2022-11-24  9:32         ` Vinod Koul
2022-11-21 14:14 ` [PATCH v3 3/4] soundwire: debugfs: Switch to sdw_read_no_pm Charles Keepax
2022-11-21 14:14   ` Charles Keepax
2022-11-21 14:14 ` [PATCH v3 4/4] soundwire: stream: Move remaining register accesses over to no_pm Charles Keepax
2022-11-21 14:14   ` Charles Keepax

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=Y386ERSr1EmkTYwk@matsya \
    --to=vkoul@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@opensource.cirrus.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=sanyog.r.kale@intel.com \
    --cc=yung-chuan.liao@linux.intel.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.