From: Yusuf Khan <yusisamerican@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jason Wang <jasowang@redhat.com>,
Michael Kelley <mikelley@microsoft.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
gregkh <gregkh@linuxfoundation.org>,
javier@javigon.com, Will Deacon <will@kernel.org>,
Jens Axboe <axboe@kernel.dk>,
Bjorn Andersson <bjorn.andersson@linaro.org>
Subject: Re: [PATCH] drivers: ddcci: upstream DDCCI driver
Date: Sat, 26 Feb 2022 02:48:25 -0800 [thread overview]
Message-ID: <CAJoG2+_qbu1Ca51exoq+0MSdcGda4y5YxM9vdseDqiH1n_i88A@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a3TWx71xT83003LSFsu1eF1p75hCxvpCB_FZf1SrNjQJw@mail.gmail.com>
Arnd, the driver includes a backlight driver, the main part of the
driver(ddcci.c) is a monitor communication protocol. Should
I leave the backlight driver(ddcci-backlight.c) in drivers/video/backlight?
On Sat, Feb 26, 2022 at 1:39 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> with the other ones.On Sat, Feb 26, 2022 at 3:20 AM Yusuf Khan
> <yusisamerican@gmail.com> wrote:
> >
> > This patch upstreams the DDCCI driver by Christoph Grenz into
> > the kernel. The original gitlab page is loacted at https://gitlab
> > .com/ddcci-driver-linux/ddcci-driver-linux/-/tree/master.
> >
> > Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
> > ---
> > drivers/Kconfig | 2 +
> > drivers/Makefile | 1 +
> > drivers/ddcci/Kconfig | 3 +
> > drivers/ddcci/Makefile | 3 +
> > drivers/ddcci/ddcci-backlight.c | 413 +++++++
> > drivers/ddcci/ddcci.c | 1895 +++++++++++++++++++++++++++++++
> > include/linux/ddcci.h | 164 +++
>
> If this is a backlight driver, I think it should go into
> drivers/video/backlight/,
> no need for a top-level subsystem.
>
> > + */
> > +
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > +#include <asm-generic/fcntl.h>
>
> Including the asm-generic version causes the build failures. If you need
> the contents, use <linux/fcntl.h>, otherwise leave it out.
>
> > +static dev_t ddcci_cdev_first;
> > +static dev_t ddcci_cdev_next;
> > +static dev_t ddcci_cdev_end;
> > +static DEFINE_SEMAPHORE(core_lock);
>
> No new semaphores please, this should probably be a mutex.
>
>
> > +struct bus_type ddcci_bus_type;
> > +EXPORT_SYMBOL_GPL(ddcci_bus_type);
> > +
> > +/* Assert neccessary string array sizes */
> > +#ifndef sizeof_field
> > +# define sizeof_field(t,m) FIELD_SIZEOF(t,m)
> > +#endif
> > +static_assert(sizeof_field(struct ddcci_device, prot) > 8);
> > +static_assert(sizeof_field(struct ddcci_device, type) > 8);
> > +static_assert(sizeof_field(struct ddcci_device, model) > 8);
> > +static_assert(sizeof_field(struct ddcci_device, vendor) > 8);
> > +static_assert(sizeof_field(struct ddcci_device, module) > 8);
> > +
> > +/* Internal per-i2c-client driver data */
> > +struct ddcci_bus_drv_data {
> > + unsigned long quirks;
> > + struct i2c_client *i2c_dev;
> > + struct semaphore sem;
> > + unsigned char recv_buffer[DDCCI_RECV_BUFFER_SIZE];
> > +};
>
> Same here.
>
> > +static const struct file_operations ddcci_fops = {
> > + .owner = THIS_MODULE,
> > + .read = ddcci_cdev_read,
> > + .write = ddcci_cdev_write,
> > + .open = ddcci_cdev_open,
> > + .release = ddcci_cdev_close,
> > + .llseek = ddcci_cdev_seek
> > +};
>
> It looks like this adds low-level access to a bus that is already managed by
> the drm (or older framebuffer) drivers. How do you prevent these two
> from stepping on each other's toes?
>
> Arnd
next prev parent reply other threads:[~2022-02-26 10:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-26 2:20 [PATCH] drivers: ddcci: upstream DDCCI driver Yusuf Khan
2022-02-26 2:33 ` Yusuf Khan
2022-02-26 9:38 ` Arnd Bergmann
2022-02-26 10:48 ` Yusuf Khan [this message]
2022-02-26 21:58 ` Arnd Bergmann
2022-02-26 3:57 Yusuf Khan
2022-02-26 4:01 ` Yusuf Khan
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=CAJoG2+_qbu1Ca51exoq+0MSdcGda4y5YxM9vdseDqiH1n_i88A@mail.gmail.com \
--to=yusisamerican@gmail.com \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=bjorn.andersson@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=jasowang@redhat.com \
--cc=javier@javigon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikelley@microsoft.com \
--cc=mst@redhat.com \
--cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).