[2/3] ASoC: dt-bindings: xmos,xvf3500: add bindings for XMOS XVF3500

  The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
multicore controller for voice processing.

Add new bindings to define the device properties.

[1] https://www.xmos.com/xvf3500/

Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
 .../devicetree/bindings/sound/xmos,xvf3500.yaml    | 51 ++++++++++++++++++++++
 1 file changed, 51 insertions(+)
  

On 15/01/2024 10:16, Javier Carrasco wrote:
> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
> multicore controller for voice processing.
> 
> Add new bindings to define the device properties.

I don't see any bus, so how does it work? How do you get the voice data
from it? I also do not see any DAI: neither here nor in the driver...

If there is going to be any new version, then implement all following
comments:

A nit, subject: drop second/last, redundant "bindings for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18


> 
> [1] https://www.xmos.com/xvf3500/
> 
> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
> ---
>  .../devicetree/bindings/sound/xmos,xvf3500.yaml    | 51 ++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
> new file mode 100644
> index 000000000000..e93a735a0f1a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/xmos,xvf3500.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: XMOS XVF3500 VocalFusion Voice Processor
> +
> +maintainers:
> +  - Javier Carrasco <javier.carrasco@wolfvision.net>
> +
> +description: |-

Do not need '|-' unless you need to preserve formatting.


> +  The XMOS XVF3500 VocalFusion Voice Processor is a low-latency, 32-bit
> +  multicore controller for voice processing.
> +  https://www.xmos.com/xvf3500/
> +
> +properties:
> +  compatible:
> +    const: xmos,xvf3500
> +
> +  reset-gpios:
> +    maxItems: 1
> +
> +  vcc1v0-supply:
> +    description: |

Do not need '|' unless you need to preserve formatting.


> +      Regulator for the 1V0 supply.
> +
> +  vcc3v3-supply:
> +    description: |

Do not need '|' unless you need to preserve formatting.

> +      Regulator for the 3V3 supply.
> +
> +additionalProperties: false

This goes after required: block.

> +
> +required:
> +  - compatible
> +  - reset-gpios
> +  - vcc1v0-supply
> +  - vcc3v3-supply
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    xvf3500: voice-processor {

Drop unused label.



Best regards,
Krzysztof
  

On 15.01.24 14:02, Krzysztof Kozlowski wrote:
> On 15/01/2024 10:16, Javier Carrasco wrote:
>> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
>> multicore controller for voice processing.
>>
>> Add new bindings to define the device properties.
> 
> I don't see any bus, so how does it work? How do you get the voice data
> from it? I also do not see any DAI: neither here nor in the driver...
> 
The voice data and any other information can be retrieved directly via
USB from userspace. Once in normal operation, the device acts as a
regular "onboard" USB device and the driver does not need to do any
further management.
> If there is going to be any new version, then implement all following
> comments:
> 
> A nit, subject: drop second/last, redundant "bindings for". The
> "dt-bindings" prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
> 
> 
>>
>> [1] https://www.xmos.com/xvf3500/
>>
>> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
>> ---
>>  .../devicetree/bindings/sound/xmos,xvf3500.yaml    | 51 ++++++++++++++++++++++
>>  1 file changed, 51 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
>> new file mode 100644
>> index 000000000000..e93a735a0f1a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
>> @@ -0,0 +1,51 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/sound/xmos,xvf3500.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: XMOS XVF3500 VocalFusion Voice Processor
>> +
>> +maintainers:
>> +  - Javier Carrasco <javier.carrasco@wolfvision.net>
>> +
>> +description: |-
> 
> Do not need '|-' unless you need to preserve formatting.
> 
> 
>> +  The XMOS XVF3500 VocalFusion Voice Processor is a low-latency, 32-bit
>> +  multicore controller for voice processing.
>> +  https://www.xmos.com/xvf3500/
>> +
>> +properties:
>> +  compatible:
>> +    const: xmos,xvf3500
>> +
>> +  reset-gpios:
>> +    maxItems: 1
>> +
>> +  vcc1v0-supply:
>> +    description: |
> 
> Do not need '|' unless you need to preserve formatting.
> 
> 
>> +      Regulator for the 1V0 supply.
>> +
>> +  vcc3v3-supply:
>> +    description: |
> 
> Do not need '|' unless you need to preserve formatting.
> 
>> +      Regulator for the 3V3 supply.
>> +
>> +additionalProperties: false
> 
> This goes after required: block.
> 
>> +
>> +required:
>> +  - compatible
>> +  - reset-gpios
>> +  - vcc1v0-supply
>> +  - vcc3v3-supply
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/gpio/gpio.h>
>> +
>> +    xvf3500: voice-processor {
> 
> Drop unused label.
> 
> 
> 
> Best regards,
> Krzysztof
> 
Thank you for your feedback and best regards,
Javier Carrasco
  

On 15/01/2024 14:58, Javier Carrasco wrote:
> On 15.01.24 14:02, Krzysztof Kozlowski wrote:
>> On 15/01/2024 10:16, Javier Carrasco wrote:
>>> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
>>> multicore controller for voice processing.
>>>
>>> Add new bindings to define the device properties.
>>
>> I don't see any bus, so how does it work? How do you get the voice data
>> from it? I also do not see any DAI: neither here nor in the driver...
>>
> The voice data and any other information can be retrieved directly via
> USB from userspace. Once in normal operation, the device acts as a
> regular "onboard" USB device and the driver does not need to do any
> further management.

So is this an USB device? If yes, then shouldn't be just auto-discovered
and you add here some bindings for other device? This looks like coding
power sequence not in USB node, but in some other, new node.

Best regards,
Krzysztof
  

On 15.01.24 15:35, Krzysztof Kozlowski wrote:
> On 15/01/2024 14:58, Javier Carrasco wrote:
>> On 15.01.24 14:02, Krzysztof Kozlowski wrote:
>>> On 15/01/2024 10:16, Javier Carrasco wrote:
>>>> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
>>>> multicore controller for voice processing.
>>>>
>>>> Add new bindings to define the device properties.
>>>
>>> I don't see any bus, so how does it work? How do you get the voice data
>>> from it? I also do not see any DAI: neither here nor in the driver...
>>>
>> The voice data and any other information can be retrieved directly via
>> USB from userspace. Once in normal operation, the device acts as a
>> regular "onboard" USB device and the driver does not need to do any
>> further management.
> 
> So is this an USB device? If yes, then shouldn't be just auto-discovered
> and you add here some bindings for other device? This looks like coding
> power sequence not in USB node, but in some other, new node.
> 
> Best regards,
> Krzysztof
> 
It is an USB device that requires two power supplies and a reset to
boot. Afterwards it is auto-discovered and functions normally as a
regular USB device. In that sense it works like the onboard USB HUBs:

https://github.com/torvalds/linux/blob/master/drivers/usb/misc/onboard_usb_hub.c

The onboard USB HUB driver is of course more complex because it has to
support other features, but the idea of enabling the power supplies and
toggling the reset signal is essentially the same.

Best regards,
Javier Carrasco
  

On 15/01/2024 16:59, Javier Carrasco wrote:
>>> The voice data and any other information can be retrieved directly via
>>> USB from userspace. Once in normal operation, the device acts as a
>>> regular "onboard" USB device and the driver does not need to do any
>>> further management.
>>
>> So is this an USB device? If yes, then shouldn't be just auto-discovered
>> and you add here some bindings for other device? This looks like coding
>> power sequence not in USB node, but in some other, new node.
>>
>> Best regards,
>> Krzysztof
>>
> It is an USB device that requires two power supplies and a reset to
> boot. Afterwards it is auto-discovered and functions normally as a
> regular USB device. In that sense it works like the onboard USB HUBs:
> 
> https://github.com/torvalds/linux/blob/master/drivers/usb/misc/onboard_usb_hub.c
> 
> The onboard USB HUB driver is of course more complex because it has to
> support other features, but the idea of enabling the power supplies and
> toggling the reset signal is essentially the same.
> 

Yeah, about that... so this is not really correct device representation
for DT. There is no such device as XVF3500 outside of USB bus. There is
XVF3500 but on USB bus and this should be there. In the past we allowed
such root-level devices just because we did not have other way to handle
them. Now we have.

Best regards,
Krzysztof
  

On 15.01.24 17:03, Krzysztof Kozlowski wrote:
> On 15/01/2024 16:59, Javier Carrasco wrote:
>>>> The voice data and any other information can be retrieved directly via
>>>> USB from userspace. Once in normal operation, the device acts as a
>>>> regular "onboard" USB device and the driver does not need to do any
>>>> further management.
>>>
>>> So is this an USB device? If yes, then shouldn't be just auto-discovered
>>> and you add here some bindings for other device? This looks like coding
>>> power sequence not in USB node, but in some other, new node.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>> It is an USB device that requires two power supplies and a reset to
>> boot. Afterwards it is auto-discovered and functions normally as a
>> regular USB device. In that sense it works like the onboard USB HUBs:
>>
>> https://github.com/torvalds/linux/blob/master/drivers/usb/misc/onboard_usb_hub.c
>>
>> The onboard USB HUB driver is of course more complex because it has to
>> support other features, but the idea of enabling the power supplies and
>> toggling the reset signal is essentially the same.
>>
> 
> Yeah, about that... so this is not really correct device representation
> for DT. There is no such device as XVF3500 outside of USB bus. There is
> XVF3500 but on USB bus and this should be there. In the past we allowed
> such root-level devices just because we did not have other way to handle
> them. Now we have.
> 
> Best regards,
> Krzysztof
> 

Do you mean that the XVF3500 should not be represented as a platform
device and instead it should turn into an USB device represented as a
node of an USB controller? Something like this (Rockchip SoC):

&usb_host1_xhci {
	...

	xvf3500 {
		...
	};
};

Did I get you right or is that not the correct representation? Thank you
again.

Best regards,
Javier Carrasco
  

On 15/01/2024 17:24, Javier Carrasco wrote:
> Do you mean that the XVF3500 should not be represented as a platform
> device and instead it should turn into an USB device represented as a
> node of an USB controller? Something like this (Rockchip SoC):
> 
> &usb_host1_xhci {
> 	...
> 
> 	xvf3500 {
> 		...
> 	};
> };
> 
> Did I get you right or is that not the correct representation? Thank you
> again.

I believe it should be just like onboard hub. I don't understand why
onboard hub was limited to hub, because other USB devices also could be
designed similarly by hardware folks :/

And if we talk about Linux drivers, then your current solution does not
support suspend/resume and device unbind.

Best regards,
Krzysztof
  

On 15.01.24 19:11, Krzysztof Kozlowski wrote:
> On 15/01/2024 17:24, Javier Carrasco wrote:
>> Do you mean that the XVF3500 should not be represented as a platform
>> device and instead it should turn into an USB device represented as a
>> node of an USB controller? Something like this (Rockchip SoC):
>>
>> &usb_host1_xhci {
>> 	...
>>
>> 	xvf3500 {
>> 		...
>> 	};
>> };
>>
>> Did I get you right or is that not the correct representation? Thank you
>> again.
> 
> I believe it should be just like onboard hub. I don't understand why
> onboard hub was limited to hub, because other USB devices also could be
> designed similarly by hardware folks :/
> 
> And if we talk about Linux drivers, then your current solution does not
> support suspend/resume and device unbind.
> 
> Best regards,
> Krzysztof
> 

Actually this series is an attempt to get rid of a misuse of the
onboard_usb_hub driver by a device that is not a HUB, but requires the
platform-part of that driver for the initialization.

What would be the best approach to provide support upstream? Should I
turn this driver into a generic USB driver that does what the
platform-part of the onboard HUB does? Or are we willing to accept
non-HUB devices in the onboard_usb_hub driver even though it supports
more operations?

I am adding linux-usb to this thread in case someone has other suggestions.

Thanks and best regards,
Javier Carrasco
  

On 15/01/2024 20:43, Javier Carrasco wrote:
> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
>> On 15/01/2024 17:24, Javier Carrasco wrote:
>>> Do you mean that the XVF3500 should not be represented as a platform
>>> device and instead it should turn into an USB device represented as a
>>> node of an USB controller? Something like this (Rockchip SoC):
>>>
>>> &usb_host1_xhci {
>>> 	...
>>>
>>> 	xvf3500 {
>>> 		...
>>> 	};
>>> };
>>>
>>> Did I get you right or is that not the correct representation? Thank you
>>> again.
>>
>> I believe it should be just like onboard hub. I don't understand why
>> onboard hub was limited to hub, because other USB devices also could be
>> designed similarly by hardware folks :/
>>
>> And if we talk about Linux drivers, then your current solution does not
>> support suspend/resume and device unbind.
>>
>> Best regards,
>> Krzysztof
>>
> 
> Actually this series is an attempt to get rid of a misuse of the
> onboard_usb_hub driver by a device that is not a HUB, but requires the
> platform-part of that driver for the initialization.

That's just naming issue, isn't it?

> 
> What would be the best approach to provide support upstream? Should I
> turn this driver into a generic USB driver that does what the
> platform-part of the onboard HUB does? Or are we willing to accept

No, because you did not solve the problems I mentioned. This is neither
accurate hardware description nor proper Linux driver model handling PM
and unbind.

> non-HUB devices in the onboard_usb_hub driver even though it supports
> more operations?
> 
> I am adding linux-usb to this thread in case someone has other suggestions.

I don't see any difference between this device and onboard hub. The
concept and the problem is the same. Therefore either treat it as as
onboard hub or come with USB-version of PCI power sequencing.

https://lore.kernel.org/all/20240104130123.37115-1-brgl@bgdev.pl/

Best regards,
Krzysztof
  

On 15.01.24 21:43, Krzysztof Kozlowski wrote:
> On 15/01/2024 20:43, Javier Carrasco wrote:
>> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
>>> On 15/01/2024 17:24, Javier Carrasco wrote:
>>>> Do you mean that the XVF3500 should not be represented as a platform
>>>> device and instead it should turn into an USB device represented as a
>>>> node of an USB controller? Something like this (Rockchip SoC):
>>>>
>>>> &usb_host1_xhci {
>>>> 	...
>>>>
>>>> 	xvf3500 {
>>>> 		...
>>>> 	};
>>>> };
>>>>
>>>> Did I get you right or is that not the correct representation? Thank you
>>>> again.
>>>
>>> I believe it should be just like onboard hub. I don't understand why
>>> onboard hub was limited to hub, because other USB devices also could be
>>> designed similarly by hardware folks :/
>>>
>>> And if we talk about Linux drivers, then your current solution does not
>>> support suspend/resume and device unbind.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>> Actually this series is an attempt to get rid of a misuse of the
>> onboard_usb_hub driver by a device that is not a HUB, but requires the
>> platform-part of that driver for the initialization.
> 
> That's just naming issue, isn't it?
> 
>>
>> What would be the best approach to provide support upstream? Should I
>> turn this driver into a generic USB driver that does what the
>> platform-part of the onboard HUB does? Or are we willing to accept
> 
> No, because you did not solve the problems I mentioned. This is neither
> accurate hardware description nor proper Linux driver model handling PM
> and unbind.
> 
You mentioned the PM handling twice, but I am not sure what you mean.
The driver provides callbacks for SIMPLE_DEV_PM_OPS, which I tested in
freeze and memory power states with positive results. On the other hand,
I suppose that you insisted for a good reason, so I would be grateful if
you could show me what I am doing wrong. The macro pattern was taken
from other devices under sound/, which also check CONFIG_PM_SLEEP,
but maybe I took a bad example or missed something.
>> non-HUB devices in the onboard_usb_hub driver even though it supports
>> more operations?
>>
>> I am adding linux-usb to this thread in case someone has other suggestions.
> 
> I don't see any difference between this device and onboard hub. The
> concept and the problem is the same. Therefore either treat it as as
> onboard hub or come with USB-version of PCI power sequencing.
> 
I have nothing against adding this device to onboard_usb_hub as long as
it is valid upstream, so no conflicts arise with new additions to the
list (which was the trigger for all of this with v6.7). That is
obviously the most trivial solution and as you said, it is justs a
naming issue because the power sequence is not HUB-specific.
> https://lore.kernel.org/all/20240104130123.37115-1-brgl@bgdev.pl/
> 
> Best regards,
> Krzysztof
> 
Thanks and best regards,
Javier Carrasco
  

On Tue, 16 Jan 2024 08:29:04 +0100,
Javier Carrasco wrote:
> 
> On 15.01.24 21:43, Krzysztof Kozlowski wrote:
> > On 15/01/2024 20:43, Javier Carrasco wrote:
> >> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
> >>> On 15/01/2024 17:24, Javier Carrasco wrote:
> >>>> Do you mean that the XVF3500 should not be represented as a platform
> >>>> device and instead it should turn into an USB device represented as a
> >>>> node of an USB controller? Something like this (Rockchip SoC):
> >>>>
> >>>> &usb_host1_xhci {
> >>>> 	...
> >>>>
> >>>> 	xvf3500 {
> >>>> 		...
> >>>> 	};
> >>>> };
> >>>>
> >>>> Did I get you right or is that not the correct representation? Thank you
> >>>> again.
> >>>
> >>> I believe it should be just like onboard hub. I don't understand why
> >>> onboard hub was limited to hub, because other USB devices also could be
> >>> designed similarly by hardware folks :/
> >>>
> >>> And if we talk about Linux drivers, then your current solution does not
> >>> support suspend/resume and device unbind.
> >>>
> >>> Best regards,
> >>> Krzysztof
> >>>
> >>
> >> Actually this series is an attempt to get rid of a misuse of the
> >> onboard_usb_hub driver by a device that is not a HUB, but requires the
> >> platform-part of that driver for the initialization.
> > 
> > That's just naming issue, isn't it?
> > 
> >>
> >> What would be the best approach to provide support upstream? Should I
> >> turn this driver into a generic USB driver that does what the
> >> platform-part of the onboard HUB does? Or are we willing to accept
> > 
> > No, because you did not solve the problems I mentioned. This is neither
> > accurate hardware description nor proper Linux driver model handling PM
> > and unbind.
> > 
> You mentioned the PM handling twice, but I am not sure what you mean.
> The driver provides callbacks for SIMPLE_DEV_PM_OPS, which I tested in
> freeze and memory power states with positive results. On the other hand,
> I suppose that you insisted for a good reason, so I would be grateful if
> you could show me what I am doing wrong. The macro pattern was taken
> from other devices under sound/, which also check CONFIG_PM_SLEEP,
> but maybe I took a bad example or missed something.

FWIW, the patterns in sound/ are somewhat outdated and need to be
refreshed.  Nowadays one should use DEFINE_SIMPLE_DEV_PM_OPS() instead
(that should work without ifdef).


thanks,

Takashi
  

On 16/01/2024 08:29, Javier Carrasco wrote:
> On 15.01.24 21:43, Krzysztof Kozlowski wrote:
>> On 15/01/2024 20:43, Javier Carrasco wrote:
>>> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
>>>> On 15/01/2024 17:24, Javier Carrasco wrote:
>>>>> Do you mean that the XVF3500 should not be represented as a platform
>>>>> device and instead it should turn into an USB device represented as a
>>>>> node of an USB controller? Something like this (Rockchip SoC):
>>>>>
>>>>> &usb_host1_xhci {
>>>>> 	...
>>>>>
>>>>> 	xvf3500 {
>>>>> 		...
>>>>> 	};
>>>>> };
>>>>>
>>>>> Did I get you right or is that not the correct representation? Thank you
>>>>> again.
>>>>
>>>> I believe it should be just like onboard hub. I don't understand why
>>>> onboard hub was limited to hub, because other USB devices also could be
>>>> designed similarly by hardware folks :/
>>>>
>>>> And if we talk about Linux drivers, then your current solution does not
>>>> support suspend/resume and device unbind.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>> Actually this series is an attempt to get rid of a misuse of the
>>> onboard_usb_hub driver by a device that is not a HUB, but requires the
>>> platform-part of that driver for the initialization.
>>
>> That's just naming issue, isn't it?
>>
>>>
>>> What would be the best approach to provide support upstream? Should I
>>> turn this driver into a generic USB driver that does what the
>>> platform-part of the onboard HUB does? Or are we willing to accept
>>
>> No, because you did not solve the problems I mentioned. This is neither
>> accurate hardware description nor proper Linux driver model handling PM
>> and unbind.
>>
> You mentioned the PM handling twice, but I am not sure what you mean.
> The driver provides callbacks for SIMPLE_DEV_PM_OPS, which I tested in
> freeze and memory power states with positive results. On the other hand,
> I suppose that you insisted for a good reason, so I would be grateful if
> you could show me what I am doing wrong. The macro pattern was taken
> from other devices under sound/, which also check CONFIG_PM_SLEEP,
> but maybe I took a bad example or missed something.

You have two Linux devices: USB device and platform device. The platform
device controls power of USB device. If platform device goes to some
variant of sleep (PRM, system PM) before the USB device, how will USB
device react? Will it work? I doubt.

You have no ordering / dependencies / device links between these devices
thus possible problems.

>>> non-HUB devices in the onboard_usb_hub driver even though it supports
>>> more operations?
>>>
>>> I am adding linux-usb to this thread in case someone has other suggestions.
>>
>> I don't see any difference between this device and onboard hub. The
>> concept and the problem is the same. Therefore either treat it as as
>> onboard hub or come with USB-version of PCI power sequencing.
>>
> I have nothing against adding this device to onboard_usb_hub as long as
> it is valid upstream, so no conflicts arise with new additions to the
> list (which was the trigger for all of this with v6.7). That is

I am sorry, but we talk here only about upstream. I don't know therefore
what "valid upstream" means. You cannot send a patch which is "not valid
upstream". I mean, technically you can, but this would be waste of our
time and receive rather annoyed responses.

> obviously the most trivial solution and as you said, it is justs a
> naming issue because the power sequence is not HUB-specific.

I would ack it. Others? No clue, I also do not remember full story
behind onboard USB hub and why it was called "hub" instead of "onboard
USB device".

Best regards,
Krzysztof
  

On 22.01.24 13:01, Takashi Iwai wrote:
> On Tue, 16 Jan 2024 08:29:04 +0100,
> Javier Carrasco wrote:
>>
>> On 15.01.24 21:43, Krzysztof Kozlowski wrote:
>>> On 15/01/2024 20:43, Javier Carrasco wrote:
>>>> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
>>>>> On 15/01/2024 17:24, Javier Carrasco wrote:
>>>>>> Do you mean that the XVF3500 should not be represented as a platform
>>>>>> device and instead it should turn into an USB device represented as a
>>>>>> node of an USB controller? Something like this (Rockchip SoC):
>>>>>>
>>>>>> &usb_host1_xhci {
>>>>>> 	...
>>>>>>
>>>>>> 	xvf3500 {
>>>>>> 		...
>>>>>> 	};
>>>>>> };
>>>>>>
>>>>>> Did I get you right or is that not the correct representation? Thank you
>>>>>> again.
>>>>>
>>>>> I believe it should be just like onboard hub. I don't understand why
>>>>> onboard hub was limited to hub, because other USB devices also could be
>>>>> designed similarly by hardware folks :/
>>>>>
>>>>> And if we talk about Linux drivers, then your current solution does not
>>>>> support suspend/resume and device unbind.
>>>>>
>>>>> Best regards,
>>>>> Krzysztof
>>>>>
>>>>
>>>> Actually this series is an attempt to get rid of a misuse of the
>>>> onboard_usb_hub driver by a device that is not a HUB, but requires the
>>>> platform-part of that driver for the initialization.
>>>
>>> That's just naming issue, isn't it?
>>>
>>>>
>>>> What would be the best approach to provide support upstream? Should I
>>>> turn this driver into a generic USB driver that does what the
>>>> platform-part of the onboard HUB does? Or are we willing to accept
>>>
>>> No, because you did not solve the problems I mentioned. This is neither
>>> accurate hardware description nor proper Linux driver model handling PM
>>> and unbind.
>>>
>> You mentioned the PM handling twice, but I am not sure what you mean.
>> The driver provides callbacks for SIMPLE_DEV_PM_OPS, which I tested in
>> freeze and memory power states with positive results. On the other hand,
>> I suppose that you insisted for a good reason, so I would be grateful if
>> you could show me what I am doing wrong. The macro pattern was taken
>> from other devices under sound/, which also check CONFIG_PM_SLEEP,
>> but maybe I took a bad example or missed something.
> 
> FWIW, the patterns in sound/ are somewhat outdated and need to be
> refreshed.  Nowadays one should use DEFINE_SIMPLE_DEV_PM_OPS() instead
> (that should work without ifdef).
> 
> 
> thanks,
> 
> Takashi

Thank you for your feedback. I noticed that the pattern looks different,
but given that many devices in sound/ still use that pattern, I just
followed suit. In that case I will only use DEFINE_SIMPLE_DEV_PM_OPS.

Thanks again and best regards,
Javier Carrasco
  

On 22.01.24 13:29, Krzysztof Kozlowski wrote:
> On 16/01/2024 08:29, Javier Carrasco wrote:
>> On 15.01.24 21:43, Krzysztof Kozlowski wrote:
>>> On 15/01/2024 20:43, Javier Carrasco wrote:
>>>> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
>>>>> On 15/01/2024 17:24, Javier Carrasco wrote:
>>>>>> Do you mean that the XVF3500 should not be represented as a platform
>>>>>> device and instead it should turn into an USB device represented as a
>>>>>> node of an USB controller? Something like this (Rockchip SoC):
>>>>>>
>>>>>> &usb_host1_xhci {
>>>>>> 	...
>>>>>>
>>>>>> 	xvf3500 {
>>>>>> 		...
>>>>>> 	};
>>>>>> };
>>>>>>
>>>>>> Did I get you right or is that not the correct representation? Thank you
>>>>>> again.
>>>>>
>>>>> I believe it should be just like onboard hub. I don't understand why
>>>>> onboard hub was limited to hub, because other USB devices also could be
>>>>> designed similarly by hardware folks :/
>>>>>
>>>>> And if we talk about Linux drivers, then your current solution does not
>>>>> support suspend/resume and device unbind.
>>>>>
>>>>> Best regards,
>>>>> Krzysztof
>>>>>
>>>>
>>>> Actually this series is an attempt to get rid of a misuse of the
>>>> onboard_usb_hub driver by a device that is not a HUB, but requires the
>>>> platform-part of that driver for the initialization.
>>>
>>> That's just naming issue, isn't it?
>>>
>>>>
>>>> What would be the best approach to provide support upstream? Should I
>>>> turn this driver into a generic USB driver that does what the
>>>> platform-part of the onboard HUB does? Or are we willing to accept
>>>
>>> No, because you did not solve the problems I mentioned. This is neither
>>> accurate hardware description nor proper Linux driver model handling PM
>>> and unbind.
>>>
>> You mentioned the PM handling twice, but I am not sure what you mean.
>> The driver provides callbacks for SIMPLE_DEV_PM_OPS, which I tested in
>> freeze and memory power states with positive results. On the other hand,
>> I suppose that you insisted for a good reason, so I would be grateful if
>> you could show me what I am doing wrong. The macro pattern was taken
>> from other devices under sound/, which also check CONFIG_PM_SLEEP,
>> but maybe I took a bad example or missed something.
> 
> You have two Linux devices: USB device and platform device. The platform
> device controls power of USB device. If platform device goes to some
> variant of sleep (PRM, system PM) before the USB device, how will USB
> device react? Will it work? I doubt.
> 
> You have no ordering / dependencies / device links between these devices
> thus possible problems.
> 
Thank you for clarifying this point. I only covered the platform device
and such device links are missing. I will opt for the inclusion in
onboard_usb_hub, which already covers both devices.
>>>> non-HUB devices in the onboard_usb_hub driver even though it supports
>>>> more operations?
>>>>
>>>> I am adding linux-usb to this thread in case someone has other suggestions.
>>>
>>> I don't see any difference between this device and onboard hub. The
>>> concept and the problem is the same. Therefore either treat it as as
>>> onboard hub or come with USB-version of PCI power sequencing.
>>>
>> I have nothing against adding this device to onboard_usb_hub as long as
>> it is valid upstream, so no conflicts arise with new additions to the
>> list (which was the trigger for all of this with v6.7). That is
> 
> I am sorry, but we talk here only about upstream. I don't know therefore
> what "valid upstream" means. You cannot send a patch which is "not valid
> upstream". I mean, technically you can, but this would be waste of our
> time and receive rather annoyed responses.
> 
I meant valid upstream, so sending such patch makes sense to the
community (and not only to us). So far you are the source of feedback
upstream, so I will follow your advice.
>> obviously the most trivial solution and as you said, it is justs a
>> naming issue because the power sequence is not HUB-specific.
> 
> I would ack it. Others? No clue, I also do not remember full story
> behind onboard USB hub and why it was called "hub" instead of "onboard
> USB device".
> 
> Best regards,
> Krzysztof
> 

Thank you and best regards,
Javier Carrasco