linux-kernel - Re: [PATCH 3/3] soundwire: bus_type: add sdw_master

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 13 May 2020 15:46:42 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     alsa-devel@...a-project.org, tiwai@...e.de,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        ranjani.sridharan@...ux.intel.com, hui.wang@...onical.com,
        broonie@...nel.org, srinivas.kandagatla@...aro.org,
        jank@...ence.com, mengdong.lin@...el.com,
        slawomir.blauciak@...el.com, sanyog.r.kale@...el.com,
        Bard Liao <yung-chuan.liao@...ux.intel.com>,
        rander.wang@...ux.intel.com, bard.liao@...el.com
Subject: Re: [PATCH 3/3] soundwire: bus_type: add sdw_master_device support

On 12-05-20, 12:01, Pierre-Louis Bossart wrote:
> > > > > > 
> > > > > > There isn't any known implementation with more than one controller.
> > > > > 
> > > > > But then it can come in "future" right. So lets try to make it future
> > > > > proof by not using the link_id (we can expose that as a sysfs if people
> > > > > want to know). So a global unique id needs to allocated (hint: idr or
> > > > > equivalent) and used as master_id
> > > > 
> > > > Can you clarify if you are asking for a global ID for Intel/ACPI
> > > > platforms,
> > > > or for DT as well? I can't figure out from the soundwire-controller.yaml
> > > > definitions if there is already a notion of unique ID.
> > > 
> > > If ACPI was unique, then I was planning to update the definition below
> > > to include that. Given that it is not the case, let's make it agnostic to
> > > underlying firmware.
> > 
> > I am not sure I understand how this would be done.
> > 
> > The call sequence is
> > 
> > sdw_bus_master_add(bus)
> >      sdw_master_device_add(bus, parent, fw_node)
> > 
> > At the bus level, we don't have any information on which controller the
> > bus is related to.

This should be done inside the sdw_bus. controller should not care about
this IMO.

> > We'd need to add an argument to sdw_bus_master_add() and have the
> > controller unique ID be allocated outside of the SoundWire core, hence
> > my question on whether the DT definition should not be extended.
> 
> And btw I don't think it makes sense to add a new definition for Intel. We
> already have a notion of HDaudio bus->idx that's set to zero since we don't
> have a case for multiple HDaudio controllers.
> 
> if we ever do have more than once controller, then we should rely on HDaudio
> bus->idx as the identifier and not create one specifically for SoundWire -
> which means as I mentioned above passing an argument and not defining a
> controller ID in the SoundWire core.

I was thinking of following code in bus.c

static DEFINE_IDA(sdw_ida);

static sdw_get_id(struct sdw_bus *bus)
{
        int rc = ida_alloc(&sdw_ida, GFP_KERNEL);

        if (rc < 0)
                return rc;

        bus->id = rc;
        return 0;
}

int sdw_add_bus_master(struct sdw_bus *bus)
{
        ...

        ret = sdw_get_id(bus);

        ...
}

void sdw_delete_bus_master(struct sdw_bus *bus)
{
        da_free(&sdw_ida, bus->id);
}

This way you get a unique master number across all devices and this has
nothing to do with link/of ids and is used for numbering masters in
sysfs uniquely.

HTH
-- 
~Vinod