linux-kernel - Re: [PATCH 2/2] arm64: dts: exynos: added mailbox node

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 17 Mar 2014 20:28:07 +0530
From:	Jassi Brar <jassisinghbrar@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Girish K S <ks.giri@...sung.com>, devicetree@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Suman Anna <s-anna@...com>, Ilho Lee <ilho215.lee@...sung.com>
Subject: Re: [PATCH 2/2] arm64: dts: exynos: added mailbox node

On Mon, Mar 17, 2014 at 5:45 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Monday 17 March 2014 17:33:59 Girish K S wrote:
>> +Samsung Mailbox Driver
>> +
>> +Required properties:
>> +- compatible:          Should be one of the following,
>> +                           "samsung,gh7-mailbox" for
>> +                               Samsung GH7 SoC series
>> +                           "samsung,exynos-mailbox" for
>> +                               exynosx SoC series
>> +- reg:                 Contains the mailbox register address range (base address
>> +                       and length)
>> +- interrupts:          Contains the interrupt information for the mailbox
>> +                       device.
>> +- samsung,mbox-names:  Array of the names of the mailboxes
>>
>
> I think we should not allow new mailbox drivers that don't conform to
> the framework that is currently under discussion. In particular, this
> means don't do a "samsung,mbox-names" property. The current consensus
> seems to be to have a #mbox-cells" property that allows to pass extra
> parameters from the client driver, and uses an "mboxes" property
> to reference the mailbox provided.
>
> It would be good if you follow up for the subsystem discussion and
> ensure it gets merged in time, and supports all the use cases you are
> interested in. The interface is not entirely nailed down yet, so
> it's a good time to contribute. However, I can already promise that
> it won't use matching by strings.
>
I was just about to submit next revision of framework that this
Samsung driver conforms to. Now I think I need some expert opinion ...
(sorry if following is repetition)

  As Kumar Gala pointed out in the other thread, the mailbox/ipc chain
is going to be _very_ platform specific so much so that one rethinks
if a common api is even warranted : because the client driver will be
different even if just the remote api(which is going to be
proprietary) changes, keeping everything else same. For example, a
client driver for Highbank is highly unlikely to be reusable on
Exynos, even if both used the same mailbox controller. By my limited
foresight, mailbox assignment via DT doesn't bring us much benefit but
only ritual code.

  Perhaps the mailbox controller driver should name its links as it
wants. By how the remote works with the mailbox links, the client
driver asks for a specific mailbox link (which maybe a hardcoded
string in the driver or be gotten alongside other data via client's
DT) ?

  IOW we can't have a generic API/DT-bindings that could get us
reusable client drivers. But only common framework/code that would
otherwise be duplicated by every platform.

Thanks
Jassi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/