On Wed, Aug 14, 2019 at 09:52:25AM -0500, Jassi Brar wrote:
On Wed, Aug 14, 2019 at 5:05 AM Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
Ok, but the offer is to Morten for MHUv2 driver.
On Tue, Aug 13, 2019 at 11:36:56AM -0500, Jassi Brar wrote:
[...]
Can you please share the client code against which you tested this driver?Thanks for acknowledging that limitation. But lets also address it.
As mentioned in the response to your initial comment, the driver does
not currently support mixing protocols.
We are hesitant to dedicate time to developing mixing protocols given
that we don't have any current usecase nor any current platform which
would support this.
From my past experience, I realise it is much more efficient to tidyup
the code myself, than endlessly trying to explain the benefits.
Thanks for the patience and offer.
Can we try the same with MHUv1 and SCMIMHUv1 driver is fine as it is.
upstream driver.
I did try my best to keep you from messing the SCMI driver, without success
https://lkml.org/lkml/2017/8/7/924
I disagree, you haven't told me how to address the usecase which I mentioned
with the abstraction/multiplexer on top of MHU as you have been suggesting.
I am sure MHUv2 will have the same usecase.
--
Regards,
Sudeep