Re: [PATCH V5 1/6] SLIMbus: Device management on SLIMbus

[Sagar Dharia <sdharia@codeaurora.org>]

[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]

On 4/29/2016 5:17 AM, Mark Brown wrote:
> On Thu, Apr 28, 2016 at 06:49:23PM +0200, Arnd Bergmann wrote:
>> On Thursday 28 April 2016 17:39:20 Mark Brown wrote:
>>> It's not just platforms that use these things though - there's things
>>> like the SolarFlare NICs where the firmware update mechanism essentially
>>> involves exposing a SPI flash as part of a PCI device and we just merged
>>> an ASoC driver for a video card which was reusing some existing IPs and
>>> chips.
>> That's of course fine: you essentially have a discoverable bus there,
>> and if we need something like that, we can always add it later to
>> any subsystem.
> No, the issue with those cases is that there are devices on discoverable
> buses that instantiate non-discoverable buses as part of the
> discoverable device so the implementation of the discoverable device is
> in part essentially a board file.
>
>> In contrast, the interface in the proposed slimbus subsystem seems
>> designed for board files, and is in the best case just dead code
>> that can be removed, or has a risk of being misused e.g. if some
>> device manufacturer decides to use a board file for this instead
>> of describing the slimbus slaves in DT.
> Which can be more of a pain than it should be if the code has been
> written to assume that all the world is DT.  That's the most problematic
> bit of this meme - I've seen people doing things like duplicating IP
> drivers inside larger devices because they don't think they're allowed
> to reuse the IP driver.  We can fix this sort of thing up when we notice
> it but we should also try to avoid people making the mistakes in the
> first place since it saves everyone a lot of effort.  With subsystems
> and to a lesser extent off SoC drivers we need to be careful about just
> blindly removing non-DT code and writing things so they're hard to use
> without DT.
>
> Like I say in this case I think the board file stuff is probably never
> going to get used so it's probably sensible to remove that code but it
> does need to be thought about.
I agree that the board-file stuff isn't going to be used and will remove it.
I will merge patch1 and patch2 and we can later add ACPI 
support/board-file support if needed.

Thanks for the comments
Sagar


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


[-- Attachment #2: Type: text/html, Size: 3213 bytes --]