Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp465629pxk; Thu, 1 Oct 2020 06:52:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxgMQ8f/6Dq6akehtWc2bJipdfqtil7kXHO/3wHxF4Hv0dfYNK6wmBYeBzfHHDAd0lFzy9G X-Received: by 2002:aa7:d417:: with SMTP id z23mr7988926edq.62.1601560353508; Thu, 01 Oct 2020 06:52:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601560353; cv=none; d=google.com; s=arc-20160816; b=Ja/SaSV9Wqxv+H04zui8i9J2Mu8jHLk/I0Uq5BF1fCLArkN5wq1965xDLmT2uGOpE2 b8S2lO2vGYbP7p2tQDMhM8WUcBt6sMlGu8qzeQIaHU/1+/i5z+sVXP2rQpmRMrX2C3DM 0XgExMNMZDP3I4dFflt2GFA8ZNMZaMDugFLpSowx1/pbhFKP1YRzqRrghViRbbaQR3Fz UBfB6jFkvorC0xUaY/21mQ7DPeIyqiMLkoax8rJ4dG+egfDlceHbSH48OKU8yoQMtdcK jgVRqutfTlIPktMtudSEPvV8UoaCPHXIyTBJGKzkKGckIgKWPObB987ntuf4QTRmRIEs CVjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=jaxI0W283WrcWdMiOUysrEs/KPcHVtCS1b4onXKubQ0=; b=syadAippagh2GKQG1tCZo/u7cTLgz5tfmc+FTrFAB6riDrQr0I6PbTMB4aLMXEiBSL dkk3gRttuo2Udxy4ymPLxHox7CRXVpuN9d3iyzUy4RslK/tv5qc6o5lsPVsYyrnIk4kl vI0ODihbHN9C0d1gPFQ2Ksm1B83TIBTfTVrqD8i229Dv6pdCLuQ7Ug+1Eg7HBk3z4Bv/ ULKqN5+hrRWy1omdlqw30xtOIWj0Um+BSoUIKhtVZpmqUg6qjYFOHvLeL6wOaM2TKVxN LZ3dY/tMCrU6yM3VEIjZZ1jKRlu6/aWJRzO7ynZe1r8j3CY4if6pb6YJugA7obmKnJd4 xQ2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a16si3999045ejk.665.2020.10.01.06.52.10; Thu, 01 Oct 2020 06:52:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732261AbgJANuV (ORCPT + 99 others); Thu, 1 Oct 2020 09:50:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51908 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732018AbgJANuT (ORCPT ); Thu, 1 Oct 2020 09:50:19 -0400 Received: from smtp1.goneo.de (smtp1.goneo.de [IPv6:2001:1640:5::8:30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B02BC0613D0; Thu, 1 Oct 2020 06:50:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp1.goneo.de (Postfix) with ESMTP id 79C1F23EE85; Thu, 1 Oct 2020 15:50:15 +0200 (CEST) X-Virus-Scanned: by goneo X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 tests=[ALL_TRUSTED=-1, AWL=-0.088, BAYES_00=-1.9] autolearn=ham Received: from smtp1.goneo.de ([127.0.0.1]) by localhost (smtp1.goneo.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlurzYLBPhyk; Thu, 1 Oct 2020 15:50:14 +0200 (CEST) Received: from lem-wkst-02.lemonage (hq.lemonage.de [87.138.178.34]) by smtp1.goneo.de (Postfix) with ESMTPSA id 0C42D23F38B; Thu, 1 Oct 2020 15:50:13 +0200 (CEST) Date: Thu, 1 Oct 2020 15:50:09 +0200 From: Lars Poeschel To: Greg Kroah-Hartman Cc: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Thierry Reding , Lee Jones , "open list:PWM SUBSYSTEM" , open list Subject: Re: [PATCH] pwm: sysfs: Set class on pwm devices Message-ID: <20201001135009.2dpgojasd3fm5phh@lem-wkst-02.lemonage> References: <20200929121953.2817843-1-poeschel@lemonage.de> <20200930065726.fjcsm4pfh65medgl@pengutronix.de> <20200930092056.maz5biy2ugr6yc3p@lem-wkst-02.lemonage> <20200930094146.73s3qzvf5ekjeavc@pengutronix.de> <20201001090531.gubfwmznlto2ng6l@lem-wkst-02.lemonage> <20201001112449.GA2364834@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201001112449.GA2364834@kroah.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 01, 2020 at 01:24:49PM +0200, Greg Kroah-Hartman wrote: > On Thu, Oct 01, 2020 at 11:05:31AM +0200, Lars Poeschel wrote: > > On Wed, Sep 30, 2020 at 11:41:46AM +0200, Uwe Kleine-K?nig wrote: > > > Hello, > > > > > > I added Greg Kroah-Hartman who I discussed this with via irc a bit to > > > Cc:. > > > > > > On Wed, Sep 30, 2020 at 11:20:56AM +0200, Lars Poeschel wrote: > > > > thank you for your review! > > > > > > > > On Wed, Sep 30, 2020 at 08:57:26AM +0200, Uwe Kleine-K?nig wrote: > > > > > On Tue, Sep 29, 2020 at 02:19:53PM +0200, poeschel@lemonage.de wrote: > > > > > > From: Lars Poeschel > > > > > > > > > > > > This adds a class to exported pwm devices. > > > > > > Exporting a pwm through sysfs did not yield udev events. The > > > > > > > > > > I wonder what is your use-case here. This for sure also has a place to > > > > > be mentioned in the commit log. I suspect there is a better way to > > > > > accomplish you way. > > > > > > > > Use-case is to be able to use a pwm from a non-root userspace process. > > > > I use udev rules to adjust permissions. > > > > > > Hmm, how do you trigger the export? Without being aware of all the > > > details in the sysfs code I would expect that the exported stuff is > > > available instantly once the write used to export the PWM is completed. > > > So changing the permissions can be done directly after triggering the > > > export in the same process. > > > > The export is triggered through the userspace process itself. Why can it > > do this ? Because there is another udev rule, that changes permissions > > when a pwmchip appears. > > Then I'd like to have the second udev rule, that changes permissions on > > the freshly exported pwm. The userspace process can't do this. > > You are right I could propably do everything from within udev: If a > > pwmchip appears, export certain pwms and right away change their > > permissions. It does not also not feel right. It'd require knowledge > > from the userspace application to be mapped to udev. > > The way the kernel code is now, yes, you will not have any way to > trigger it by userspace as the kernel is creating a "raw" struct device > that isn't assigned to anything. That is what needs to be fixed here. I did a first try with our approach. I set the class of the child to its parent class. This does work and create the directories right under /sys/pwm but because the child now also inherits the dev_groups from the parent its directory also contain export, unexport and npwm files, that don't apply for pwm's as soon a I register the device to driver core. Did we miss something or is there a way to avoid that ? I had a look at device_add and saw that as soon as a class it set it's dev_groups get exported through device_add_attrs. > > > Out of interest: What do you use the pwm for? Isn't there a suitable > > > kernel driver that can do the required stuff? Compared to the kernel-API > > > the sysfs interface isn't atomic. Is this an annoyance? > > > > Use-case is generating a voltage from the pwm. This voltage is used to > > signal different states and does not change very often. This is > > absolutely not annoying that this is not atomic. We just change the duty > > cycle on the fly. Everything else is configured one time at startup. > > I'd call what I need pwm-dac. I could not find a ready to use driver. > > Maybe I could misuse some kernel driver for this. Maybe I could use > > pwm-led or pwm-brightness or pwm-fan. Propably pwm-regulator could work, > > there is even a userspace facing part for this, but this is not > > devicetree ready. > > ...and the worst, please don't blame me: The application is java, so > > ioctl is a problem. > > I thought java could do ioctls, otherwise how would it ever be able to > talk to serial ports? It is not impossible but it is horrible. java itself can access the ports through normal file I/O, but it can not set control lines or baudrate or anything. You need some C-code for this, that is not part of the java vm itself and has to be called through something called JNI - java native interface. Regards, Lars