From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Date: Mon, 25 Jul 2016 12:57:13 +0200 From: Thierry Reding To: Mirza Krak Cc: Jon Hunter , Stephen Warren , Alexandre Courbot , pdeschrijver@nvidia.com, Prashant Gaikwad , Michael Turquette , sboyd@codeaurora.org, devicetree@vger.kernel.org, linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, Kumar Gala , linux@armlinux.org.uk Subject: Re: [RFC 6/6] bus: Add support for Tegra NOR controller Message-ID: <20160725105713.GA21170@ulmo.ba.sec> References: <1468935397-11926-1-git-send-email-mirza.krak@gmail.com> <1468935397-11926-7-git-send-email-mirza.krak@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" In-Reply-To: List-ID: --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 22, 2016 at 09:18:37PM +0200, Mirza Krak wrote: > 2016-07-22 11:38 GMT+02:00 Jon Hunter : > >>> The driver should have a remove function given that we can build as a > >>> module. > >> > >> At the moment I do not know what we would do in a remove function and > >> hence me not adding one. > > > > Should just be the inverse of the probe (although there is no inverse > > for the parsing DT bit). If you don't wish to add a remove, that is > > fine, but make the driver a 'bool' and not 'tristate' in the Kconfig so > > it cannot be configured as a module. >=20 > I understand the concept of a remove function, but I use devm_ calls > for all resources. These should be handled by the device core on a > driver detach? >=20 > One thing came to mind now that could be done in a remove method and > that is clearing the CONFIG_GO bit, or I could just do that first on > probe instead to make sure the controller is stopped. >=20 > Ok, one more thing came to mind, and that is depopulating the child > devices. Got it remove function it is then. >=20 > >>>> +module_platform_driver_probe(nor_driver, nor_probe); > >>> > >>> I would use "tegra_nor" namespace for all the structs, functions, etc. > >>> However, we may prefer to go with GMI and in which case tegra_gmi_pro= be, > >>> etc. > >> > >> ACK. Who gets the last call on what we should call the driver? It > >> seems that we both think GMI is a better name, do we need a third? :). > > > > The patches would have to go via Thierry and so ultimately, Thierry. > > However, I can't imagine he would object to GMI ;-) >=20 > Eagerly awaiting Thierry`s comments :). Let's go with GMI. The TRM has a mix of GMI vs. SNOR, but as Jon points out the pinmux doesn't mention SNOR, so in order to hopefully reduce the confusion, let's stick with GMI. Thierry --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXlfCGAAoJEN0jrNd/PrOh93MP/jsPdVE0PwR+Z94UQsYutowG t4bK/9ErFyvkKWiNDRTnKudga+1sOhg3NCsxs6FeJ2Xh0Cr3DVPJuJCH0ZknOkGu bqErhIUUaG7fHcdBt2H7VGBYDzQDN5eWVvJWKW7Bik4V8AGhV4EGnfkrhnWU7VVm B+qzmiGd2B9ec+F5xVJL4uB+M/Ma50N8aldk3kwqlD7pRfuux8nC7iuKMdF/hotg m0Nv/+zBN+RaOKCsIFoSKOITRocFF0oM6R6YX4ZsYLNELQyDoXkO51rtnx3LlrGN ce2mcddtSyBorAVVyfPyJFgUG2EJG0EF5Z4yQiBb946DU8x4T4W5M87AgngxsIbb aHnkHcSIG+PA73Sg/gDw4bzCKiwaMUD8zW7ZRsx2m9whdLZgfi8I9gI86+KPJUFm kSujU8bh6ymOKiKC8r0hsgbmBaIQ6AurxxAfxfKcpK5GHr+Yz6qDYUWCiGnCYHXs 4Kwb2RlFfmmlw3CpVV4ikZzyCEIsu0UxIskgExaMk5+2rF+sj+x3I5iRZt2uJcv0 xZR6js7H4aphEO1aIpalaLIxliUhoNZP/7+urJKMZdC4rGfzpGxkZpPHNc3Of1Ua fmaB6hXoDQwfZVncIWWrfBHlsr8M9OM3rMZSnJEQG0pDtTB+aBbkgvzp0tsR/BSc mKs9izCN/aTemZtwCZAw =MF8X -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH--