From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936956AbdJQREe (ORCPT ); Tue, 17 Oct 2017 13:04:34 -0400 Received: from mail-it0-f52.google.com ([209.85.214.52]:44882 "EHLO mail-it0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934248AbdJQREc (ORCPT ); Tue, 17 Oct 2017 13:04:32 -0400 X-Google-Smtp-Source: ABhQp+RwBAfmIPdkOIUM5vQfEfomBpLwHnkQNtWvKLW9xCkf0/miplKMX6lWhHrUuzlFCv/Qxf7e6w== Date: Tue, 17 Oct 2017 10:04:29 -0700 From: Brian Norris To: Thierry Reding Cc: Jeffy Chen , linux-kernel@vger.kernel.org, dmitry.torokhov@gmail.com, heiko@sntech.de, rjw@rjwysocki.net, dianders@chromium.org, tfiga@chromium.org, broonie@kernel.org, seanpaul@chromium.org, linux-pwm@vger.kernel.org Subject: Re: [RFC PATCH v4 7/8] pwm: Add dummy pwmchip for orphan pwms Message-ID: <20171017170428.GB3408@google.com> References: <20171017101624.12506-1-jeffy.chen@rock-chips.com> <20171017101624.12506-8-jeffy.chen@rock-chips.com> <20171017124031.GA27983@ulmo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171017124031.GA27983@ulmo> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Oct 17, 2017 at 02:40:31PM +0200, Thierry Reding wrote: > On Tue, Oct 17, 2017 at 06:16:23PM +0800, Jeffy Chen wrote: > > When the pwm driver is unbound while the pwm is still requested, the > > pwm core would not actually remove the pwmchip(return -EBUSY instead). > > > > So it would hold some references to the invalid resources(e.g. pwmchip). > > > > And the customer who requested the pwm would have those references too, > > and may crash the kernel when trying to access them later. > > > > Add a dummy pwmchip, and assign orphan pwms to it to avoid that. > > > > Signed-off-by: Jeffy Chen > > --- > > > > Changes in v4: > > Fix compile warning. > > > > Changes in v3: > > Assign orphan pwms to dummy pwmchip instead of adding device link in the > > customer driver. > > What happened to this? Device links were specifically designed to avoid > situations like these. I think Jeffy came up with this as an odd response to my suggestion on v2 that we could just handle the device links in the PWM core. I don't fully understand why the complete change in direction... BTW, since you seem to have an opinion about device links: is it expected that all consumer drivers will make explicit calls to device_link_add()? I thought this should be avoided, if possible (e.g., this can be handled in pwm_get()). > A dummy PWM chip doesn't seem like the right solution to this. Agreed. Brian