[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191213161122.GB2653074@kroah.com>
Date: Fri, 13 Dec 2019 17:11:22 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc: alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
tiwai@...e.de, broonie@...nel.org, vkoul@...nel.org,
jank@...ence.com, srinivas.kandagatla@...aro.org,
slawomir.blauciak@...el.com,
Bard liao <yung-chuan.liao@...ux.intel.com>,
Rander Wang <rander.wang@...ux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
Sanyog Kale <sanyog.r.kale@...el.com>
Subject: Re: [alsa-devel] [PATCH v4 07/15] soundwire: slave: move uevent
handling to slave
On Fri, Dec 13, 2019 at 09:11:27AM -0600, Pierre-Louis Bossart wrote:
> On 12/13/19 1:22 AM, Greg KH wrote:
> > On Thu, Dec 12, 2019 at 11:04:01PM -0600, Pierre-Louis Bossart wrote:
> > > Currently the code deals with uevents at the bus level, but we only care
> > > for Slave events
> >
> > What does this mean? I can't understand it, can you please provide more
> > information on what you are doing here?
>
> In the earlier versions of the patch, the code looks like this and there was
> an open on what to do with a master-specific event.
>
> static int sdw_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
> + struct sdw_master_device *md;
> struct sdw_slave *slave;
> char modalias[32];
>
> - if (is_sdw_slave(dev)) {
> + if (is_sdw_md(dev)) {
> + md = to_sdw_master_device(dev);
> + /* TODO: do we need to call add_uevent_var() ? */
> + } else if (is_sdw_slave(dev)) {
> slave = to_sdw_slave_device(dev);
> +
> + sdw_slave_modalias(slave, modalias, sizeof(modalias));
> +
> + if (add_uevent_var(env, "MODALIAS=%s", modalias))
> + return -ENOMEM;
> } else {
> dev_warn(dev, "uevent for unknown Soundwire type\n");
> return -EINVAL;
> }
>
> Vinod suggested this was not needed and suggested the code for uevents be
> moved to be slave-specific, which is what this patch does.
Then describe it really really well in the changelog text. We have no
rememberance of prior conversations when looking at commits in the tree
in the future.
thaniks,
greg k-h
Powered by blists - more mailing lists