netdev - Re: [PATCH 2/2] can: tcan4x5x: Add tcan4x5x driver to the kernel

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]

Message-ID: <f7bde33a-894b-9b27-6475-d69aaf19df1a@grandegger.com>
Date:   Wed, 26 Sep 2018 20:34:47 +0200
From:   Wolfgang Grandegger <wg@...ndegger.com>
To:     Dan Murphy <dmurphy@...com>, mkl@...gutronix.de,
        davem@...emloft.net
Cc:     linux-can@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] can: tcan4x5x: Add tcan4x5x driver to the kernel

Hello Dan,

Am 26.09.2018 um 20:00 schrieb Dan Murphy:
> Wolfgang
> 
> On 09/26/2018 12:54 PM, Wolfgang Grandegger wrote:
>> Hello,
>>
>> I wonder why you do not extend the existing MCAN driver by implementing
>> an interface to access the hardware. Would that be feasible?
>>
> 
> That did cross my mind. The issue is I have no way of testing the existing
> driver to make sure I did not break anything.

Yes, I can imagine, but we should try to avoid duplicated code in the
first place. I personally do not have a MCAN device at hand either, but
we should be able to manage that.

> My thought was to create a basic MCAN framework and attach the devices to it.
> So, like in this case, if there is a special way to talk to the device it can 
> be handled in the device driver.

Basically, that's what I have in mind. The "mcan" driver uses it's own
directory with just one file in it. Maybe the idea behind that was to
extend it sooner than later like the "c_can" driver.

> If thats what is needed then I will have to re-write the driver.

Let's have a closer look first. If it's just about accessing one
register at a time, like with memory mapped io, the interface should be
trivial but with SPI we may want to read/write a bulk of data to speed
up the register accesses, use a work queue or thread, etc.

Wolfgang