linux-kernel - Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181126210638.0b8c4ee8@bbrezillon>
Date:   Mon, 26 Nov 2018 21:06:38 +0100
From:   Boris Brezillon <boris.brezillon@...tlin.com>
To:     vitor <vitor.soares@...opsys.com>
Cc:     <wsa@...-dreams.de>, <linux-i2c@...r.kernel.org>, <corbet@....net>,
        <linux-doc@...r.kernel.org>, <gregkh@...uxfoundation.org>,
        <arnd@...db.de>, <psroka@...ence.com>, <agolec@...ence.com>,
        <adouglas@...ence.com>, <bfolta@...ence.com>, <dkos@...ence.com>,
        <alicja@...ence.com>, <cwronka@...ence.com>, <sureshp@...ence.com>,
        <rafalc@...ence.com>, <thomas.petazzoni@...tlin.com>, <nm@...com>,
        <robh+dt@...nel.org>, <pawel.moll@....com>, <mark.rutland@....com>,
        <ijc+devicetree@...lion.org.uk>, <galak@...eaurora.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <geert@...ux-m68k.org>, <linus.walleij@...aro.org>,
        <Xiang.Lin@...aptics.com>, <linux-gpio@...r.kernel.org>,
        <nsekhar@...com>, <pgaj@...ence.com>, <peda@...ntia.se>,
        <mshettel@...eaurora.org>, <swboyd@...omium.org>,
        <joao.pinto@...opsys.com>
Subject: Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and
 bus specific parts

On Mon, 26 Nov 2018 19:28:02 +0000
vitor <vitor.soares@...opsys.com> wrote:

> On 26/11/18 19:08, Boris Brezillon wrote:
> > On Mon, 26 Nov 2018 19:56:18 +0100
> > Boris Brezillon <boris.brezillon@...tlin.com> wrote:
> >     
> >>>       - for the others it will easy the SoC integration avoiding
> >>> duplicated work and doing things from scratch.  
> >> What would be duplicated? You want to support a new SoC, just add a new
> >> entry in the of_match_table and you're done. When you need to add
> >> SoC/integration specific stuff, create a struct and attach a different
> >> instance per-compatible so that each SoC can have its own configuration
> >> (or even init sequence if needed). That's how we do for pretty much all
> >> IPs out there, why should designware ones be different?  
> > To be more specific, I'd like a real example that shows why the
> > separation is needed.  
> 
> Ok no problem. We can delay this for PCI and other rules support.

I finally understand what this separation is all about: supporting both
PCI and platform devices. I guess I've been distracted by this sentence:

"
This patch will allow SOC integrators to add their code specific to
DesignWare I3C IP.
"

which for me meant each SoC would have its own platform_driver.

In any case, I think this is a bit premature do this separation, unless
you already know about one integrator planning to expose this IP over
PCI.