Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1671263

Re: [PATCH v9 1/5] firmware: add extensible driver data params

From AKASHI Takahiro <takahiro.akashi@linaro.org>
Newsgroups linux.kernel
Subject Re: [PATCH v9 1/5] firmware: add extensible driver data params
Date 2017-06-21 03:00 +0200
Message-ID <tUC9X-7mL-7@gated-at.bofh.it> (permalink)
References (3 earlier) <tRPZL-65q-11@gated-at.bofh.it> <tRZZ7-3Du-1@gated-at.bofh.it> <tTwgi-6oU-17@gated-at.bofh.it> <tUucp-2wu-1@gated-at.bofh.it> <tUv8u-37f-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Jun 20, 2017 at 07:22:19PM +0200, Luis R. Rodriguez wrote:
> On Tue, Jun 20, 2017 at 09:27:45AM -0700, Vikram Mulukutla wrote:
> > 
> > perhaps a light
> > internal rework inside firmware_class might be more suitable towards the
> > extensibility goal while keeping driver API usage as simple as it is today
> > (even if you hate my patch for various reasons)?
> > 
> > [1] - https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/drivers/base/firmware_class.c?h=msm-3.18&id=7aa7efd3c150840369739893a84bd1d9f9774319
> 
> What you did is but one step I took, your changes make it easier to shuffle
> data around internally. Its not sufficient to clean things up well enough, for
> instance look at the "firmware behavior options" which are cleaned up in this
> patch 1/5. That's been one pain on our side for a while, people understanding
> when a flag applies or a feature, and making sure we document it all.
> 
> Then, one of the end goals is to provide extensibility, this is to allow users
> to *pass* similar type of struct for either a sync or async call. Without this
> the API remains unflexible and I predict we'll end up with the same situation
> later anyway.
> 
> The approach I took uses an internal struct for passing required data for the
> private internal API use. Then it also provides a public struct which can be
> used to grow requirements to make only *new* API easily extensible.
> 
> So we need all three things to move forward.

Given the discussions here, it would be better to split your [1/5] and
[2/5] into more smaller pieces, say,
  * re-factor the old APIs with introducing private fw_desc
  * add new APIs with extra public arguments
  * extend new APIs per-feature
      - sync/async callbacks
      - API version, and so on

This way, you can illustrate how your approach evolves and it may
mitigate people's concern about how complicated it is on the surface,
allowing for discussing each of aspects of new APIs separately.

Thanks,
-Takahiro AKASHI

>   Luis

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v9 1/5] firmware: add extensible driver data params Vikram Mulukutla <markivx@codeaurora.org> - 2017-06-20 18:30 +0200
  Re: [PATCH v9 1/5] firmware: add extensible driver data params "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-20 19:30 +0200
    Re: [PATCH v9 1/5] firmware: add extensible driver data params AKASHI Takahiro <takahiro.akashi@linaro.org> - 2017-06-21 03:00 +0200
      Re: [PATCH v9 1/5] firmware: add extensible driver data params "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-23 18:40 +0200

csiph-web