Re: [RFC PATCH 0/3] mailbox: hisilicon: add mailbox driver

From: Jassi Brar
Date: Mon Aug 10 2015 - 03:02:13 EST


On Thu, Aug 6, 2015 at 4:47 AM, Leo Yan <leo.yan@xxxxxxxxxx> wrote:
> Hi Jassi,
>
> Thanks for review.
>
> On Wed, Aug 05, 2015 at 04:22:01PM +0530, Jassi Brar wrote:
>> On Mon, Aug 3, 2015 at 6:43 AM, Leo Yan <leo.yan@xxxxxxxxxx> wrote:
>
> [...]
>
>> > For easily extending for Hisilicon series SoCs (SoCs may have difference
>> > for register's definition with each other), so firstly implement common
>> > mailbox driver; this common mailbox driver provides three mainly
>> > functionality:
>> >
>> > - help register channels into framework;
>> > - hook low level callback functions for register's operations;
>> > - Enhance rx channel's message queue, which is based on the code in
>> > drivers/mailbox/omap-mailbox.c.
>> >
>> Not cool.
>> Please don't reinvent the wheel by having platform specific
>> implementation of the mailbox api. Which vendor doesn't plan to roll
>> out new SoCs, and hence variations of mailbox controllers? The OMAP
>> stack predates the common api, and was actually supposed to be
>> converted over eventually. Please implement just the
>> drivers/mailbox/hi6220-mailbox.c (preferably by the name of the
>> mailbox controller, if any)
>
> Understood. Here i have one question, the rx channel's message queue is
> looks like a common mechanism and can be added into framework file
> mailbox.c, then Soc driver file can _ONLY_ focus on register level's
> operations. If so, the common driver in this patch also is unnecessary.
>
Yes, that's what I say, no 'common' driver for a platform.

> Do you suggest to use upper method to rework patches? Or just think
> it's okay to implement rx channel's message queue in hi6220-mailbox.c?
>
The code in drivers/mailbox/ should only manage the controller
(registers and interrupts). Everything else (queues, shmem etc) should
be in platform specific client driver(s).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/