From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 393CF168 for ; Sun, 4 Jul 2021 15:56:21 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id o18so14904028pgu.10 for ; Sun, 04 Jul 2021 08:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mime-version:content-disposition; bh=K2diU9KWyJASkYFPtaMAcRisbrNMDviSK63SFvUX3lM=; b=KPpTrH5/H9z3ApoT8xnpR8l85RrbAGUeoFvwYlT0NdWhS5jPSYgk+AcJWB/OB9iy7/ rK30TL4lbZLL4LRrappX97hD4uSpj+ZTEI9G2biGsXYxgGdKP3iYY3og6JZeRelzX/NK diNUebuXXoZlgx+p1MOiWp61/4gLIdM4PyVWR8gbmPRNq+d1ja9RZy0aV1CKJMMiAh6s rfXvpki3WpD9kvSJakX1auQMXdIDlvujfK429EcmzAsrajDO8FR4GcPProZ7HDg4eUGO 3Uvx6KJTLC5Ej+1+j8av8WwAaHssXui01PWFqWzxJnDex6dhmqiHPLSJuTkjrtOVCMfR Tu9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=K2diU9KWyJASkYFPtaMAcRisbrNMDviSK63SFvUX3lM=; b=rp1Fq8t3C7FSriKW6x9k8HXGP79VcqZlZ8+NPkUtu4OoH2OnleuNKZjTz6rY0kjtFN V4qI0dGbvykwgTVn4VAQQ1GKwSo1juEmWFn1lGs0Vqh3hyoiWF5KZ9vEjehZq8I9CRqB vDh2HsVJQgHgR+LSHPr+jp7t92PeCxgbANjiGDo1uNmlAoj8VdPDHhltWo+rEGKagKEY rslOfE3Gm41xNKO2kji06xygSYWzg7Dpg21JwHmWb3NYLrCrMj7dSB7LPZ0U9w4P4WuH j0xU9p8xIrZY2AJpW9gCKZxsGrL+7JpWaoT5NihUz+iFmC2xA8neNNvcCj7rs7gj8vtn w+Aw== X-Gm-Message-State: AOAM530xsqrYNG5D3cuTdGsY9CWCTE9bpAO53u3AscAY1txpbol1TlNc BeKt1vGF70U1h4jQGTffh7g= X-Google-Smtp-Source: ABdhPJx/MqrjtL61CGxEabIT5HI65iVP4Obbsncf+0uA9qdbKQH59smVp9MmgLCMwSknI3AZYESzuQ== X-Received: by 2002:a63:d90b:: with SMTP id r11mr10917482pgg.81.1625414180733; Sun, 04 Jul 2021 08:56:20 -0700 (PDT) Received: from ojas ([182.69.223.21]) by smtp.gmail.com with ESMTPSA id m7sm2141928pjf.8.2021.07.04.08.56.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Jul 2021 08:56:20 -0700 (PDT) Date: Sun, 4 Jul 2021 21:26:08 +0530 From: Ojaswin Mujoo To: nsaenz@kernel.org Cc: gregkh@linuxfoundation.org, stefan.wahren@i2se.com, arnd@arndb.de, dan.carpenter@oracle.com, phil@raspberrypi.com, bcm-kernel-feedback-list@broadcom.com, linux-arm-kernel@lists.infradead.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v3 0/5] vchiq: Patch to separate platform and cdev code Message-ID: Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, This patchset adderesses the TODO item number 10 specified at: drivers/staging/vc04-services/interface/TODO For reference, the task is: 10) Reorganize file structure: Move char driver to it's own file and join both platform files The cdev is defined alongside with the platform code in vchiq_arm.c. It would be nice to completely decouple it from the actual core code. For instance to be able to use bcm2835-audio without having /dev/vchiq created. One could argue it's better for security reasons or general cleanliness. It could even be interesting to create two different kernel modules, something the likes of vchiq-core.ko and vchiq-dev.ko. This would also ease the upstreaming process. A summary of the patches is as follows: - Patch 1: Move cdev init code into a function - Patch 2: Shift some devlarations from vchiq_arm.c to vchiq_arm.h for sharing - Patch 3: Move vchiq cdev init code from vchiq_arm.c into vchiq_dev.c - Patch 4: Decouple cdev code by defining a Kconfig entry to allow optional compilation of it. - Patch 5: Merge code in vchiq_2835_arm.c to vchiq_arm.c (More details can be found in the commit messages) Changes since v2 [1]: * In Patch 1, as suggested, I have added error handling code back to ensure the driver exits when there is an error in creating vchiq cdev * I have built this patch against the right kernel (gregkh/staging, staging-next branch) to avoid introducing any unwanted inconsistencies like whitespace changes I have tested the patch using vchiq_test utility on RPi 3B+. Additionally, I had a small question regarding the next steps here (quoting my cover letter from v2): This question is more related to the next set of patches I'm planning to submit. So the last thing left in this TODO is to completely decouple vchiq platform and cdev code into 2 separate modules and I am planning to do that in a different patchset. The approach I have in mind is to start by using EXPORT_SYMBOL to export all the functions (and accessor functions for variables like g_state) that would be required for cdev init. Majority of these would be exported from vchiq_arm.c and vchiq_core.c, and will then be used in vchiq-dev.ko. Is this the right way to approach this? Thank you in advance for the help. Please let me know if any changes/ additional info is required. Regards, Ojaswin [1] v2: https://lkml.org/lkml/2021/6/20/63 Ojaswin Mujoo (5): staging: vchiq: Refactor vchiq cdev code staging: vchiq: Move certain declarations to vchiq_arm.h staging: vchiq: Move vchiq char driver to its own file staging: vchiq: Make creation of vchiq cdev optional staging: vchiq: Combine vchiq platform code into single file drivers/staging/vc04_services/Kconfig | 10 + drivers/staging/vc04_services/Makefile | 5 +- .../interface/vchiq_arm/vchiq_2835_arm.c | 564 ---- .../interface/vchiq_arm/vchiq_arm.c | 2344 +++++------------ .../interface/vchiq_arm/vchiq_arm.h | 82 + .../interface/vchiq_arm/vchiq_dev.c | 1440 ++++++++++ 6 files changed, 2265 insertions(+), 2180 deletions(-) delete mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c create mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c -- 2.25.1 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 X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F9B5C07E95 for ; Sun, 4 Jul 2021 15:58:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0F45A61356 for ; Sun, 4 Jul 2021 15:58:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0F45A61356 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Subject:Cc:To: From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=moKfhNUs/ox0jL/jAcE3KYtnOLph2wXmfGSWgh71Op0=; b=NONZnaHR4OSNGW VfUMcTgUgmWBlAcpVgCv3UF8SU3Qqwvjl31pbur+IC7IhLo2lXA5MxoWFbYU5AozYpT9Ivg4GTl0n 0xIaCT6F16s+wDMt+99dVPrOjVNEg/324skXLFtaW6MFBRRQMI++kjqvajaJnHi5Yuz0TSHFe1Xkb f1y82DHjXUqUMEzxqjd6JiBHxxb93seUZ7/+ntNoY0HED+mJzY7ceNwNIlH9hYaoCbAc57I0GKbY1 IcJNCSTljAEp0fUQPyTnvGzwEdxLYabl1+iH5EMW18v9YjdqzBiJ0T0WJBtViovHjQ6UU9xGUUsSi WgWQ35RH88E6q+1eaWjA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m04Tq-006USt-Mm; Sun, 04 Jul 2021 15:56:26 +0000 Received: from mail-pg1-x52b.google.com ([2607:f8b0:4864:20::52b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m04Tn-006USY-1U for linux-arm-kernel@lists.infradead.org; Sun, 04 Jul 2021 15:56:24 +0000 Received: by mail-pg1-x52b.google.com with SMTP id u14so15498797pga.11 for ; Sun, 04 Jul 2021 08:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mime-version:content-disposition; bh=K2diU9KWyJASkYFPtaMAcRisbrNMDviSK63SFvUX3lM=; b=KPpTrH5/H9z3ApoT8xnpR8l85RrbAGUeoFvwYlT0NdWhS5jPSYgk+AcJWB/OB9iy7/ rK30TL4lbZLL4LRrappX97hD4uSpj+ZTEI9G2biGsXYxgGdKP3iYY3og6JZeRelzX/NK diNUebuXXoZlgx+p1MOiWp61/4gLIdM4PyVWR8gbmPRNq+d1ja9RZy0aV1CKJMMiAh6s rfXvpki3WpD9kvSJakX1auQMXdIDlvujfK429EcmzAsrajDO8FR4GcPProZ7HDg4eUGO 3Uvx6KJTLC5Ej+1+j8av8WwAaHssXui01PWFqWzxJnDex6dhmqiHPLSJuTkjrtOVCMfR Tu9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=K2diU9KWyJASkYFPtaMAcRisbrNMDviSK63SFvUX3lM=; b=E3Td0jtL4d/cndxl3W7DxMrOt+C5fiUkbnaHfGKaWnUz6EydPkt1FA4j04W2kBaVxh 0jgTVMj+vYAt2MPYVg97HTw2d5Cp1CVVYOYppleQsW3V7fm84A5Bilo5TfHTo9ObxVN2 6HrM9YQCL7Ptv5ayYZV2D/826TFnfGTmBCrzmYi+MXQK9RwTFal7MDqPQig9ZabVwR5H /fgjYiXya3OdCcPjaGDnVMFNMMWFVVMvsj6XG4n2/tSCJ9d1r9HT0cx8M0b972z3iojN mXntiXuNJGNYsosjrPTrwG11v4gIuOzJXRuPlsEazD4q4u5h8N7nDNblwNKRMR2mg43I rEFw== X-Gm-Message-State: AOAM533ftmd3rc9QFTIVNOY2inbLr0XWp+kswTirXM1guZY2OD8CTBF0 nGDwiEmkLARXSnqhKXO+sQU= X-Google-Smtp-Source: ABdhPJx/MqrjtL61CGxEabIT5HI65iVP4Obbsncf+0uA9qdbKQH59smVp9MmgLCMwSknI3AZYESzuQ== X-Received: by 2002:a63:d90b:: with SMTP id r11mr10917482pgg.81.1625414180733; Sun, 04 Jul 2021 08:56:20 -0700 (PDT) Received: from ojas ([182.69.223.21]) by smtp.gmail.com with ESMTPSA id m7sm2141928pjf.8.2021.07.04.08.56.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Jul 2021 08:56:20 -0700 (PDT) Date: Sun, 4 Jul 2021 21:26:08 +0530 From: Ojaswin Mujoo To: nsaenz@kernel.org Cc: gregkh@linuxfoundation.org, stefan.wahren@i2se.com, arnd@arndb.de, dan.carpenter@oracle.com, phil@raspberrypi.com, bcm-kernel-feedback-list@broadcom.com, linux-arm-kernel@lists.infradead.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v3 0/5] vchiq: Patch to separate platform and cdev code Message-ID: MIME-Version: 1.0 Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210704_085623_149286_172E3297 X-CRM114-Status: GOOD ( 24.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello, This patchset adderesses the TODO item number 10 specified at: drivers/staging/vc04-services/interface/TODO For reference, the task is: 10) Reorganize file structure: Move char driver to it's own file and join both platform files The cdev is defined alongside with the platform code in vchiq_arm.c. It would be nice to completely decouple it from the actual core code. For instance to be able to use bcm2835-audio without having /dev/vchiq created. One could argue it's better for security reasons or general cleanliness. It could even be interesting to create two different kernel modules, something the likes of vchiq-core.ko and vchiq-dev.ko. This would also ease the upstreaming process. A summary of the patches is as follows: - Patch 1: Move cdev init code into a function - Patch 2: Shift some devlarations from vchiq_arm.c to vchiq_arm.h for sharing - Patch 3: Move vchiq cdev init code from vchiq_arm.c into vchiq_dev.c - Patch 4: Decouple cdev code by defining a Kconfig entry to allow optional compilation of it. - Patch 5: Merge code in vchiq_2835_arm.c to vchiq_arm.c (More details can be found in the commit messages) Changes since v2 [1]: * In Patch 1, as suggested, I have added error handling code back to ensure the driver exits when there is an error in creating vchiq cdev * I have built this patch against the right kernel (gregkh/staging, staging-next branch) to avoid introducing any unwanted inconsistencies like whitespace changes I have tested the patch using vchiq_test utility on RPi 3B+. Additionally, I had a small question regarding the next steps here (quoting my cover letter from v2): This question is more related to the next set of patches I'm planning to submit. So the last thing left in this TODO is to completely decouple vchiq platform and cdev code into 2 separate modules and I am planning to do that in a different patchset. The approach I have in mind is to start by using EXPORT_SYMBOL to export all the functions (and accessor functions for variables like g_state) that would be required for cdev init. Majority of these would be exported from vchiq_arm.c and vchiq_core.c, and will then be used in vchiq-dev.ko. Is this the right way to approach this? Thank you in advance for the help. Please let me know if any changes/ additional info is required. Regards, Ojaswin [1] v2: https://lkml.org/lkml/2021/6/20/63 Ojaswin Mujoo (5): staging: vchiq: Refactor vchiq cdev code staging: vchiq: Move certain declarations to vchiq_arm.h staging: vchiq: Move vchiq char driver to its own file staging: vchiq: Make creation of vchiq cdev optional staging: vchiq: Combine vchiq platform code into single file drivers/staging/vc04_services/Kconfig | 10 + drivers/staging/vc04_services/Makefile | 5 +- .../interface/vchiq_arm/vchiq_2835_arm.c | 564 ---- .../interface/vchiq_arm/vchiq_arm.c | 2344 +++++------------ .../interface/vchiq_arm/vchiq_arm.h | 82 + .../interface/vchiq_arm/vchiq_dev.c | 1440 ++++++++++ 6 files changed, 2265 insertions(+), 2180 deletions(-) delete mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c create mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c -- 2.25.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel