From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B49BEC433F5 for ; Sat, 26 Feb 2022 10:48:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231193AbiBZKtO (ORCPT ); Sat, 26 Feb 2022 05:49:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229796AbiBZKtM (ORCPT ); Sat, 26 Feb 2022 05:49:12 -0500 Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 244336EB19 for ; Sat, 26 Feb 2022 02:48:37 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id g20so8081177vsb.9 for ; Sat, 26 Feb 2022 02:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I27KF98I0JlvERzhmnPqQRZW8dN4hXcZo1yC0uVJNCU=; b=gAWvdMWzCQAuNFzuGaEBnVvHp7O5niBRhTGL7mZKkD8LYxmGoyJdczGYr0orZ3mG7p xKt6Z7IaNUaSDyOje94svuqvCaAN+nyXq4sEeICnz/jSs3YosCPugjBqGm5a3JuI2dcF QsVLMS2SIyqhSTcxHKmxBF3HKbB4N1HDel0Shji/fsSCAPl2ooWPZ1qfIQly53G2qYrT mlQstYftm9KXVNGazaZSmPLDvtRPOnWDhQrsWF0mEDrxeMfynhFIO+7JiehnCTEOffbG LYmqbvbU9PIcKmMv2N9duod7e8PQ414eggZBtffeqgAbjk+T56sAZJbpIxUI3YtIqrce 7qMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I27KF98I0JlvERzhmnPqQRZW8dN4hXcZo1yC0uVJNCU=; b=0kXSrzqi731HPmC9Of85OUtA7Su8G5AT/wDuVENMVu8WKbRIKu8Fv94GCd8T87JIbH e6HI4/bx/uv73p/gNiLkCIotBv7E59E7vBUMbfJXroTpgljVvdN7W2t1PzApQ24hyGGg Znw4k04ouwMaiWyMfza8yIoKsvaSK79Wl5aSA9QsRy+Q1sh7Mf5aGjNna667vDvTYEzI OPHTiNgC5N9SmUzIn3Q6IVaNrx2vFvJtA1NmCErfMHYoMuEAvqK/K/BorBOtKmms8jTI 6vbPG17vmMSy699L52eiPs0Ts+XIldVUYZ4mRNmtLpG9k1U2F/Ee9mkwfGnJjoM9Z+l3 3E+Q== X-Gm-Message-State: AOAM531HC7JBSgfqXERsBJElUVbv3e5oJ6gWqgC/Iz0qvuObKwoK6AGK +lgbA1K19xv0f+HdyYV5BSBuAN2hMijWhFxLMe8= X-Google-Smtp-Source: ABdhPJwJZdXHvxr1FV8CIRfqEAKpLcXu3Zpiaf6Lr2QbPlzjYHguxIDo7fEgfEVg/HZYpythMmcVW3S14OTexamm2nI= X-Received: by 2002:a67:d886:0:b0:31c:44f6:a968 with SMTP id f6-20020a67d886000000b0031c44f6a968mr5160687vsj.60.1645872515947; Sat, 26 Feb 2022 02:48:35 -0800 (PST) MIME-Version: 1.0 References: <20220226022053.958688-1-yusisamerican@gmail.com> In-Reply-To: From: Yusuf Khan Date: Sat, 26 Feb 2022 02:48:25 -0800 Message-ID: Subject: Re: [PATCH] drivers: ddcci: upstream DDCCI driver To: Arnd Bergmann Cc: Linux Kernel Mailing List , Jason Wang , Michael Kelley , "Michael S. Tsirkin" , gregkh , javier@javigon.com, Will Deacon , Jens Axboe , Bjorn Andersson Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wrote: > > with the other ones.On Sat, Feb 26, 2022 at 3:20 AM Yusuf Khan > 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 > > --- > > 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 > > Including the asm-generic version causes the build failures. If you need > the contents, use , 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