[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AHEAGAB5CMixysy1ydkfyaqy.3.1587463423329.Hmail.wenhu.wang@vivo.com>
Date: Tue, 21 Apr 2020 18:03:43 +0800 (GMT+08:00)
From: 王文虎 <wenhu.wang@...o.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: arnd@...db.de, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, kernel@...o.com, robh@...nel.org,
Christophe Leroy <christophe.leroy@....fr>,
Scott Wood <oss@...error.net>,
Michael Ellerman <mpe@...erman.id.au>,
Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v2,RESEND] misc: new driver sram_uapi for user level SRAM access
>On Tue, Apr 21, 2020 at 05:09:47PM +0800, 王文虎 wrote:
>> Hi, Greg, Arnd,
>>
>> Thank you for your comments first, and then really very very very sorry
>> for driving Greg to sigh and I hope there would be chance to share Moutai
>> (rather than whisky, we drink it much, a kind of Baijiu), after the virus.
>>
>> Back to the comments, I'd like to do a bit of documentation or explanation first,
>> which should have been done early or else there would not be so much to explain:
>> 1. What I have been trying to do is to access the Freescale Cache-SRAM device form
>> user level;
>> 2. I implemented it using UIO, which was thought of non-proper;
>
>I still think that using uio is the best way to do this, and never said
>it was "non-proper". All we got bogged down in was the DT
>representation of stuff from what I remember. That should be worked
>through.
>
>thanks,
>
>greg k-h
Surely, but so how would things go? Scott said not fit for him. And he was
gonna to write a new patch(Oh, that is what I have been doing.....,and I really
donot think he need to do it)
This is the final version using UIO, and even Christophe had Reviewed-by,
https://lore.kernel.org/patchwork/patch/1226225/
If no ending reaches, I have to make a step forward to keep working with
the misc device version.
Thanks, and regards,
Wenhu
Powered by blists - more mailing lists