linux-kernel - Re: [PATCH v4] soundwire: intel: move to auxiliary bus

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 11 Jun 2021 09:51:49 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     alsa-devel@...a-project.org, Leon Romanovsky <leon@...nel.org>,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        hui.wang@...onical.com, Jason Gunthorpe <jgg@...dia.com>,
        Dave Ertman <david.m.ertman@...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 v4] soundwire: intel: move to auxiliary bus

Thanks Vinod for your feedback,

>> If you look at the *existing* code, we don't handle any "resources" with the
>> platform devices, we use the platform_device_info.data to pass the link
>> information. It's a void pointer. We do not touch the resource field in the
>> platform_device_into at all.
> 
> Yes that is true I dont disagree on that part. My ask here is to make it
> better, it can be followed up after this but I would at least like to
> agree on the direction.

[...]

>> That's it. We did not change anything else, all the other fields are
>> identical. We are only changing the TYPE of device and the interfaces for
>> probe/remove but using the same information and the same device hierarchy.
> 
> The move in itself is okay but I dont think that should be the end goal.

What we suggested in this patch is only an iso-functionality change. I 
believe from Greg's and your feedback that there is no objection on that 
small step.

This is not the end-goal indeed. The second step would be to remove the 
intel_init.c file. I fully agree with you Vinod that this can be moved 
into the SOF driver, and we could do this in a follow-up step. We can 
also improve the partition between 'context' used by the child driver 
and information passed by the parent on SHIM registers and bases.

I think we'd need to agree on the details of the second step, Bard and I 
can work on a proposal, but I don't see a disconnect on the direction to 
simplify the interface. That's the right thing to do.