Re: [PATCH v9 08/10] arm64: dts: qcom: sc8280xp: Add multiport controller node for SC8280

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 03, 2023 at 12:40:19AM +0530, Krishna Kurapati PSSNV wrote:
> On 6/27/2023 8:46 PM, Johan Hovold wrote:
> > On Sat, Jun 24, 2023 at 12:43:23PM +0530, Krishna Kurapati PSSNV wrote:
> >>> On 21.06.2023 06:36, Krishna Kurapati wrote:
> >>>> Add USB and DWC3 node for tertiary port of SC8280 along with multiport
> >>>> IRQ's and phy's. This will be used as a base for SA8295P and SA8295-Ride
> >>>> platforms.
> >>>>
> >>>> Signed-off-by: Krishna Kurapati <quic_kriskura@xxxxxxxxxxx>

> >> Yes wakeup is supported by all ports now, but I didn't make those
> >> changes now as I wanted to keep driver code diff minimal and don't need
> >> wakeup support for the product currently. But for sure, will update
> >> driver code to handle wakeup on all ports in near future.
> > 
> > Why didn't you include it in v9? I thought you had a working
> > implementation for this?
> > 
> > Since wakeup will be another case where glue and core need to interact,
> > it's good to have the wakeup implementation from the start to be able to
> > evaluate your multiport implementation properly.
> > 
> > Right now it looks like you only added wakeup interrupt lookup and
> > request, but then you never actually enable them which is not very nice.

>   As mentioned in one of my comments on earlier patches, wakeup is not a 
> requirement I currently need to work on for the product. I added 
> multiport IRQ support only because my pathces need to modify IRQ names. 
> If there is a customer requirement I get in the future, I will 
> definitely implement the wakeup part. But for now, I would like to stick 
> to what is necessary for getting Multiport to work.

I think you need to implement this now as this is a basic features of
any USB controller and one which is already supported by the driver you
are changing. We've also had a long of history of Qualcomm pushing
incomplete implementations upstream and then they move on to more
pressing deadline and never actually complete the work.

This very wakeup support is a good example of this as parts of it was
merged years ago and when someone later tried to get it to actually
work, it turned into a complete hack of an implementation as no one had
thought about the overall design.

Johan



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux