On 14/08/2019 17:51, Sudeep Holla wrote:
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:
On Tue, Aug 13, 2019 at 11:36:56AM -0500, Jassi Brar wrote:
[...]
As mentioned in the response to your initial comment, the driver does
not currently support mixing protocols.
Thanks for acknowledging that limitation. But lets also address it.
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.
Can you please share the client code against which you tested this driver?
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.
Ok, but the offer is to Morten for MHUv2 driver.
Can we try the same with MHUv1 and SCMI
upstream driver.
MHUv1 driver is fine as it is.
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.
MHUv2 driver is addressing existing (door-bell) use case as well as new
(multi-word) use case using new IP features.
--
Regards,
Sudeep
