From: subhasish@mistralsolutions.com (Subhasish Ghosh)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 13/13] tty: pruss SUART driver
Date: Wed, 23 Feb 2011 13:34:45 -0000 [thread overview]
Message-ID: <6E7634AAF813458489E0444DF71260CF@subhasishg> (raw)
Hello,
Anything regarding this.
--------------------------------------------------
From: "Subhasish Ghosh" <subhasish@mistralsolutions.com>
Sent: Wednesday, February 23, 2011 11:00 AM
To: "Greg KH" <gregkh@suse.de>; "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: "Arnd Bergmann" <arnd@arndb.de>; <linux-arm-kernel@lists.infradead.org>;
"Thomas Gleixner" <tglx@linutronix.de>; <sachi@mistralsolutions.com>;
<davinci-linux-open-source@linux.davincidsp.com>; <nsekhar@ti.com>; "open
list" <linux-kernel@vger.kernel.org>; <m-watkins@ti.com>; "Stalin
Srinivasan" <stalin.s@mistralsolutions.com>
Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver
> I could not follow the recommendations clearly.
> This is just to clarify.
>
> Currently, I have the following files for the suart implementation:
>
> drivers/tty/serial/da8xx_pruss/pruss_suart_api.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_err.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_regs.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_board.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_mcasp.h
> drivers/tty/serial/da8xx_pruss/pruss_suart_utils.h
>
> drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
> drivers/tty/serial/da8xx_pruss/pruss_suart.c
> drivers/tty/serial/da8xx_pruss/pruss_suart_utils.c
>
> Of these, I will be removing pruss_suart_err.h as part of the Linux error
> code cleanup.
> But, I need to keep at least pruss_suart_board.h as a separate file, as
> this defines
> configurations which will be often modified by users, I don't want to mix
> it with other files.
>
> Should I combine rest of the headers into a single file ? and keep the
> other three .c files under "drivers/tty/serial/"
> and remove the da8xx_pruss directory altogether.
>
>
> --------------------------------------------------
> From: "Greg KH" <gregkh@suse.de>
> Sent: Tuesday, February 22, 2011 8:07 PM
> To: "Subhasish Ghosh" <subhasish@mistralsolutions.com>
> Cc: "Arnd Bergmann" <arnd@arndb.de>;
> <linux-arm-kernel@lists.infradead.org>; "Thomas Gleixner"
> <tglx@linutronix.de>; "Alan Cox" <alan@lxorguk.ukuu.org.uk>;
> <sachi@mistralsolutions.com>;
> <davinci-linux-open-source@linux.davincidsp.com>; <nsekhar@ti.com>; "open
> list" <linux-kernel@vger.kernel.org>; <m-watkins@ti.com>
> Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver
>
>> On Tue, Feb 22, 2011 at 02:12:32PM +0530, Subhasish Ghosh wrote:
>>> Hello,
>>>
>>> I had kept separate files to affirm the modularity and ease of
>>> portability of the system.
>>>
>>> There are three different interfaces,
>>> 1. The Linux driver interface
>>> 2. The PRU control interface
>>> 3. The McASP serializer interface.
>>>
>>> To maintain modularity, I had classified the files respectively as :
>>> 1. pruss_suart.c
>>> 2. pruss_suart_api.c
>>> 3. pruss_suart_utils.c
>>>
>>> This is not a single device which can be expressed as a single file,
>>> but functionally different devices logically cascaded together to
>>> work in unison.
>>>
>>> We use the PRU for packet processing, but the actual data is
>>> transmitted/received through the
>>> McASP, which we use as a serializer.
>>>
>>> I feel to combine these disparate functionalities into a single file
>>> will not
>>>
>>> 1. Help better understanding the device. I mean, why should a TTY
>>> UART driver be aware of the McASP or the PRU.
>>> 2. In case of a bug in the API layer or McASP, the driver need not
>>> be touched, thus improve maintainability.
>>> 3. If we need to port it to another Linux version, just editing the
>>> driver file should suffice, this will reduce bugs while porting.
>>
>> If your code is in the kernel tree, you do not need to ever port it to a
>> new version, as it will happen automatically as new kernels are
>> released, so this really isn't anything to worry about.
>>
>>> To me, combining all of these into a single file only creates a
>>> mess. This is the reason I had separated them into different files!!
>>> I don't understand why should it be better to have all of these into
>>> a single file.
>>
>> As Alan stated, just use 3 files in the directory with the other
>> drivers, you don't need a subdir for something small like this.
>>
>> thanks,
>>
>> greg k-h
>
next reply other threads:[~2011-02-23 13:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 13:34 Subhasish Ghosh [this message]
2011-02-23 18:21 ` [PATCH v2 13/13] tty: pruss SUART driver Greg KH
-- strict thread matches above, loose matches on Subject: below --
2011-02-11 14:51 [PATCH v2 00/13] pruss mfd drivers Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 13/13] tty: pruss SUART driver Subhasish Ghosh
2011-02-11 16:28 ` Alan Cox
2011-02-18 13:47 ` Subhasish Ghosh
2011-02-18 14:35 ` Alan Cox
2011-02-18 18:23 ` Thomas Gleixner
2011-02-18 18:51 ` Arnd Bergmann
2011-02-22 8:42 ` Subhasish Ghosh
2011-02-22 14:37 ` Greg KH
2011-02-23 5:30 ` Subhasish Ghosh
2011-02-23 18:20 ` Greg KH
2011-02-22 8:43 ` Subhasish Ghosh
2011-02-22 16:34 ` Arnd Bergmann
2011-02-24 10:31 ` Subhasish Ghosh
2011-02-22 10:26 ` Subhasish
2011-02-22 11:11 ` Alan Cox
2011-03-01 13:37 ` Subhasish Ghosh
2011-03-01 14:07 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6E7634AAF813458489E0444DF71260CF@subhasishg \
--to=subhasish@mistralsolutions.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox