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] [day] [month] [year] [list]
Message-ID: <653402b90609130725i10a47accy854d677188b5d7a8@mail.gmail.com>
Date:	Wed, 13 Sep 2006 16:25:37 +0200
From:	"Miguel Ojeda" <maxextreme@...il.com>
To:	"Ben Dooks" <ben-linux@...ff.org>
Cc:	greg@...ah.com, alan@...rguk.ukuu.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3] LCD Display Driver lcddisplay, ks0108, cfag12864b

Please reply in the last patch version, subject:

[PATCH 2/2] drivers: LCD Display support.

On 9/13/06, Ben Dooks <ben-linux@...ff.org> wrote:
> I think there would be a case for splitting the lcd
> drivers into two layers, one to deal with the hardware
> talking to an lcd device (such as an parallel port)
> and the second to deal with the command sequences
> being sent.
>

It is divided already in two layers:

ks0108.c -> It is the driver for a LCD controller. It deals with the
hardware (not directly, it uses parport module). It exports the
functions defined for such controller to other modules.

cfag12864b.c -> It is a LCD driver, depends on ks0108. This is the
driver that tells what and how to write.

> For instance, we have two boards based on ARM which
> use a CPLD to decode CS1 and CS2, etc. This would
> mean re-writing your driver (and anyone elses)
> depending on what sort of LCD we would like to
> connect to these.
>

I don't think so. The ks0108 controller driver was built to control
the LCD using the parallel port and a specific wiring.

If you want to use your boards, write a driver for them. What is the problem.

(Please tell me if I misunderstood you)

> If there was an generic device driver, then you
> could export the writing of bytes to user-space
> and have them use the hardware to do any protocol
> they liked.
>

A generic driver for what? There are many different ports/wirings,
different LCDs displays, different LCD controllers, different
protocols...

I didn't understand what do you mean.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ