From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932993AbcFONaD (ORCPT ); Wed, 15 Jun 2016 09:30:03 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:38178 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932967AbcFON3z (ORCPT ); Wed, 15 Jun 2016 09:29:55 -0400 MIME-Version: 1.0 In-Reply-To: <576156D6.4010606@arm.com> References: <1465228439-13457-1-git-send-email-sudeep.holla@arm.com> <1465228439-13457-4-git-send-email-sudeep.holla@arm.com> <576156D6.4010606@arm.com> From: Ulf Hansson Date: Wed, 15 Jun 2016 15:29:48 +0200 Message-ID: Subject: Re: [PATCH 3/3] firmware: scpi: add device power domain support using genpd To: Sudeep Holla Cc: "linux-kernel@vger.kernel.org" , Jon Medhurst , Mathieu Poirier , Suzuki K Poulose , "Rafael J. Wysocki" , Kevin Hilman , "linux-pm@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [...] > >>> +static const struct of_device_id scpi_power_domain_ids[] = { >>> + { .compatible = "arm,scpi-power-domains", }, >>> + { /* sentinel */ } >>> +}; >> >> >> Actually I think you shouldn't implement this a standalone driver and >> thus you can remove this compatible. >> > > While I tend to agree, I did this to keep it aligned with other SCPI > users(clocks, sensors,.. for example). > > I assume remove compatible just from driver ? IMO, it doesn't make sense > to add power domain provider without a compatible. > >> Instead, I think it's better if you let the arm_scpi driver to also >> initialize the PM domain. >> > > OK, I can do that. > >> If you still want the PM domain code to be maintained in a separate >> file, just provide a header file which declares an >> "scpi_pm_domain_init()" function (and a stub when not supported), >> which the arm_scpi driver should call during ->probe(). >> > > I am fine with that, just that it deviates from the approach taken in > other subsystems as I mentioned above. If DT maintainers are happy with you adding a compatible for this, don't let me stop you from implementing this as standalone driver. I have no strong opinions about it, so perhaps it's then better to not deviate from other cases!? Kind regards Uffe