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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 9A92EC433FE for ; Wed, 12 Oct 2022 10:46:04 +0000 (UTC) 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:In-Reply-To:MIME-Version:References: 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: List-Owner; bh=o1s5Ey8EQTCLByehsZWVCKSc0Fi6g3QWRu+kaoJHNVQ=; b=fv0CJo08CM3vgt YU0RDDg8kRwUublEwLEGac03FNYwfR4dYppbTVXLuscNZDysOU/VJABckGmE1wAB9+5Wn5xBxMu9O TtDQO0NVHrx4Af244fqhwhuFVKRloefiYybkaFcrxtMya4PGL5aUduEsEaX3C8ary6fxskajzUmzo UfoCKnvvdFljck4yHlWnMR+QNHdPasxHn1lYtOH531t1nzRBsyRTWhLHFG9A08umX6xQu++AAPHE0 Qf3JroZB6R2EWwvDwg9+RE+dSb+Nxf5+pI7k5vFD7B154IqrOlwumSua0qyTZgLyQqFI5TC2YkVGS ilN9lD70yMk+d+1c9HjQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oiZE6-007iIs-71; Wed, 12 Oct 2022 10:44:38 +0000 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oiZE1-007iHC-6G for linux-arm-kernel@lists.infradead.org; Wed, 12 Oct 2022 10:44:36 +0000 Received: by mail-ej1-x62d.google.com with SMTP id bj12so37030418ejb.13 for ; Wed, 12 Oct 2022 03:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=qcyLVkAX4C2bQHqyPJ/6XHXt/goPwBl/28hWztrqBv0=; b=TKT2y3gv+qWGG/MJK1wMNgFVTIagv0sWHP213Hy3PFFRoHMY4AZQF0/xkzPStK4HOe rARX+CTlYPua1GrCYpekAgsM5QnoYu/8T3HVwUpoqYBgkOx0UVvK8Of3VnFDlxl8l40H z5DX1DEQseNHiFJu8GIxLrIOdXsUozcyUPGomdWcaDtZyj+AeRXSGDLzPMztk8d4jqxt OB90ek0hkt11zl21l/PC13EWYcZKrTv7kiZOfJhnSKl17BHaSmXm1jM9b+oaXT0s3BDD 5y3t5wcoXCwYGk6MTJu89wfgf+vWmd+yIGkpWAXWh+umTqRhygGpCY2oiqtcjHr4V870 nssg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qcyLVkAX4C2bQHqyPJ/6XHXt/goPwBl/28hWztrqBv0=; b=73AcQGBdhJFZrfbUESf49rvtsCAvT2Yq8j9IkSCSxsO5WUmz1x0SWS5fxt8wqMpM47 Wx9kyv3/PRZ9CiLok/EKIH/iHRhGr7H35gQ1bpYc/5IiUYDrVtrtoBLYqLVsfWoudXGj j2w0e0FAHnYfcHnugAgYiOwkFcuYM9Lj4Eog3UW0W9mjgy6ihjpNJ+3yFn0vKGloaDij B6gFsbIwwTC4w0S33gMbQdo/wWZLwArrLfhrCZD8obIgn6SYxmYtDC3KQewr/XRRflYW w7XTsZ+bo/r5yZvb97WCmun869pCa0+CyGrMzS/xs135av9PzE770WCHkgbr+Q4YFbF+ DdPA== X-Gm-Message-State: ACrzQf1V9oLPC2dyTc/qnltnx4F7bBeJQ26Ly+ps1ROoRrUvO3JaiQny 20OIIBxPzeElTMcRU7jOKPlRWQ== X-Google-Smtp-Source: AMsMyM6Hp1pU50Y68qeyPx4K85LDY/OK4+Joj7THjBkSSu9oWVUliaNZjcL3QdHUDllKxE2qKPnhuA== X-Received: by 2002:a17:907:1b1e:b0:783:8e33:2d1c with SMTP id mp30-20020a1709071b1e00b007838e332d1cmr21916987ejc.304.1665571469032; Wed, 12 Oct 2022 03:44:29 -0700 (PDT) Received: from localhost ([86.61.181.4]) by smtp.gmail.com with ESMTPSA id x6-20020a1709064bc600b0073bdf71995dsm1028050ejv.139.2022.10.12.03.44.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Oct 2022 03:44:28 -0700 (PDT) Date: Wed, 12 Oct 2022 12:44:27 +0200 From: Jiri Pirko To: Vadim Fedorenko Cc: Jakub Kicinski , Arkadiusz Kubalewski , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, Vadim Fedorenko Subject: Re: [RFC PATCH v3 1/6] dpll: Add DPLL framework base functions Message-ID: References: <20221010011804.23716-1-vfedorenko@novek.ru> <20221010011804.23716-2-vfedorenko@novek.ru> <24d1d750-7fd0-44e2-318c-62f6a4a23ea5@novek.ru> <576aaccb-991e-ea77-e27a-b9f640c49292@novek.ru> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <576aaccb-991e-ea77-e27a-b9f640c49292@novek.ru> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221012_034433_511163_A7E66EBF X-CRM114-Status: GOOD ( 27.87 ) 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 Tue, Oct 11, 2022 at 11:23:38PM CEST, vfedorenko@novek.ru wrote: >On 11.10.2022 09:32, Jiri Pirko wrote: >> Mon, Oct 10, 2022 at 09:54:26PM CEST, vfedorenko@novek.ru wrote: >> > On 10.10.2022 10:18, Jiri Pirko wrote: >> > > Mon, Oct 10, 2022 at 03:17:59AM CEST, vfedorenko@novek.ru wrote: >> > > > From: Vadim Fedorenko >> > > > >> > > > DPLL framework is used to represent and configure DPLL devices >> > > > in systems. Each device that has DPLL and can configure sources >> > > > and outputs can use this framework. >> > > > >> > > > Signed-off-by: Vadim Fedorenko >> > > > Co-developed-by: Jakub Kicinski >> > > > Co-developed-by: Arkadiusz Kubalewski >> > > > --- > [...] >> > > > +static int dpll_pre_doit(const struct genl_ops *ops, struct sk_buff *skb, >> > > > + struct genl_info *info) >> > > > +{ >> > > > + struct dpll_device *dpll_id = NULL, *dpll_name = NULL; >> > > > + >> > > > + if (!info->attrs[DPLLA_DEVICE_ID] && >> > > > + !info->attrs[DPLLA_DEVICE_NAME]) >> > > > + return -EINVAL; >> > > > + >> > > > + if (info->attrs[DPLLA_DEVICE_ID]) { >> > > > + u32 id = nla_get_u32(info->attrs[DPLLA_DEVICE_ID]); >> > > > + >> > > > + dpll_id = dpll_device_get_by_id(id); >> > > > + if (!dpll_id) >> > > > + return -ENODEV; >> > > > + info->user_ptr[0] = dpll_id; >> > > >> > > struct dpll_device *dpll should be stored here. >> > > >> > > >> > > > + } >> > > > + if (info->attrs[DPLLA_DEVICE_NAME]) { >> > > >> > > You define new API, have one clear handle for devices. Either name or >> > > ID. Having both is messy. >> > > >> > That was added after the discussion with Jakub and Arkadiusz where we agreed >> > that the device could be referenced either by index or by name. The example >> > is that userspace app can easily find specific DPLL device if it knows the >> > name provided by a driver of that specific device. Without searching through >> > sysfs to find index value. Later commands could be executed using index once >> > it's known through CMD_GET_DEVICE/ATTR_DEVICE_NAME. >> >> What exacly is the name? What is the semantics? How the name is >> generated in case of multiple instances of the same driver. What happens >> if two drivers use the same name? Is the name predictable (in sense of >> "stable over reboots")? >> > >The way we were thinking about name is that driver can provide it's own name >based on the hardware values, like MAC address or any other unique >identifier, or the subsystem will use 'dpll%d' template to create the device. >In the first case names can be predictable and stable over reboots at the >same time. Well, I don't think it is in general good idea to allow the drivers such flexibility in strings directly passed to userspace. From past experience, it usually end up with mess which is very hard to control. Therefore, I believe that the driver should pass info in struct of well defined fields. Like for example THIS_MODULE, and dpll.c can get the name by module_name() [...] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel