Re: [RFC 1/5] soundwire: bus_type: add sdw_master_device support

[Bard liao <yung-chuan.liao@linux.intel.com>]

On 4/28/2020 3:51 PM, Vinod Koul wrote:
> On 28-04-20, 08:55, Greg KH wrote:
>> On Tue, Apr 28, 2020 at 12:19:51PM +0530, Vinod Koul wrote:
>>> On 28-04-20, 08:37, Greg KH wrote:
>>>> On Tue, Apr 28, 2020 at 10:01:44AM +0530, Vinod Koul wrote:
>>>>>>> That is not true for everyone, it is only true for Intel, pls call that
>>>>>>> out as well...
>>>>>> Why is it not true for everyone?  How else do you get the pm stuff back
>>>>>> to your hardware?
>>>>> The rest of the world would do using the real controller device. For
>>>>> example the soundwire controller on Qualcomm devices is enumerated as a
>>>>> DT device and is using these...
>>>>>
>>>>> If Intel had a standalone controller or enumerated as individual
>>>>> functions, it would have been a PCI device and would manage as such
>>>> If it is not a standalone controller, what exactly is it?  I thought it
>>>> was an acpi device, am I mistaken?
>>>>
>>>> What is the device that the proper soundwire controller driver binds to
>>>> on an Intel-based system?
>>> The HDA controller which is a PCI device. The device represent HDA
>>> function, DSP and Soundwire controller instances (yes it is typically
>>> more than one instance)
>> Then those "instances" should be split up into individual devices that a
>> driver can bind to.  See the work happening on the "virtual" bus for
>> examples of how that can be done.
> Yes removing platform devices is the goal for Intel now :) Pierre & Bard
> have been diligently trying to solve this.
>
> Only difference is the means to end goal. I am not convinced that this
> should be in soundwire subsystem.
>
> Looks like folks are trying to review and port to use this bus. Makes
> sense to me..
> https://lore.kernel.org/netdev/c5197d2f-3840-d304-6b09-d334cae81294@linux.intel.com/
>
>> A platform device better not be being used here, I'm afraid to look at
>> the code now...
> Well if the plan for 'virtual-bus' goes well, it should be  a simple
> replacement of platform->virtual for Intel driver. Rest of the driver
> should not be impacted :)

We can't expect when will 'virtual-bus' be upstream and it's not feasible
to wait forever. Can we move forward with current solution and switch to
'virtual-bus' whenever it is upstream?

> Thanks