From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751852AbdFOSd5 (ORCPT ); Thu, 15 Jun 2017 14:33:57 -0400 Received: from mail-pf0-f179.google.com ([209.85.192.179]:33529 "EHLO mail-pf0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752323AbdFOSdx (ORCPT ); Thu, 15 Jun 2017 14:33:53 -0400 Date: Thu, 15 Jun 2017 11:33:42 -0700 From: Bjorn Andersson To: Sebastian Reichel Cc: Dmitry Torokhov , Rob Herring , John Stultz , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org Subject: Re: [PATCH 2/2] Input: pm8941-pwrkey: Introduce reboot mode support Message-ID: <20170615183342.GX12920@tuxbook> References: <20170527065130.3456-1-bjorn.andersson@linaro.org> <20170527065130.3456-2-bjorn.andersson@linaro.org> <20170530025324.GD32841@dtor-ws> <20170530044711.GP12920@tuxbook> <20170608163243.j4dfpa6swoz27ofd@earth> <20170612233203.GT12920@tuxbook> <20170615162657.dgjsriesdzlqwzux@earth> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170615162657.dgjsriesdzlqwzux@earth> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 15 Jun 09:26 PDT 2017, Sebastian Reichel wrote: > Hi, > > On Mon, Jun 12, 2017 at 04:32:03PM -0700, Bjorn Andersson wrote: [..] > > As such if we split the non-input related handling into another driver > > we would need to make the input driver create a subdevice during probe - > > or create a new pon-driver with a new compatible that internally spawns > > the pwrkey driver. Neither seems desirable to me... > > The pon-driver would have been the proper solution, but with the > binding already being defined that's no longer a nice option :( > We have a binding for the "qcom,pm8941-pwrkey", but as long as we maintain the compatibility in the input driver with this we could come up with a new binding for the "pon" block. > > The features of the PON block not yet shown on LKML are status registers > > to indicate the reason for powering up the PMIC and a watchdog (which I > > don't believe is used or exposed today). > > So we have a block, which has watchdog, powerdown, reboot, boot-reason, > reboot-mode and power key. To me that does not look like it should be > one driver. > Unfortunately I do agree with this. It would make sense to describe the pon in a single DT-node and have a pon-driver spawning off individual driver for each functionality. That way we get a clean representation in DT and we get clean implementation of each component... Regards, Bjorn