From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCHv2 09/12] ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs (fsusb) Date: Mon, 11 Jun 2012 01:03:42 -0700 Message-ID: <20120611080341.GA12766@atomide.com> References: <20120611004502.20034.8840.stgit@dusk> <20120611004617.20034.21714.stgit@dusk> <20120611063416.GT12766@atomide.com> <20120611071301.GC6845@arwen.pp.htv.fi> <20120611074133.GZ12766@atomide.com> <20120611074854.GG6845@arwen.pp.htv.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-02-ewr.mailhop.org ([204.13.248.72]:44616 "EHLO mho-02-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750707Ab2FKIDp (ORCPT ); Mon, 11 Jun 2012 04:03:45 -0400 Content-Disposition: inline In-Reply-To: <20120611074854.GG6845@arwen.pp.htv.fi> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Felipe Balbi Cc: Paul Walmsley , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Tero Kristo , =?utf-8?Q?Beno=C3=AEt?= Cousson * Felipe Balbi [120611 00:55]: > Hi, > > On Mon, Jun 11, 2012 at 12:41:33AM -0700, Tony Lindgren wrote: > > > > This should be "static inline int fsusb_reset_host_controller" as it's > > > > in a header. > > > > > > why is it even in a header ? Only hwmod_fsusb_preprogram() will use it > > > anyway. > > > > Well ideally it would be something that any OHCI driver can use for > > it's reset, and whatever bus code can also call to reset and idle > > for the unused devices that don't have the driver compiled in. Got > > any better suggestions where to place it? I could be a generic > > ohci_reset function in some header? > > maybe create ? Then, while doing that, move register > definitions to this new header too... Something like: > > $ mv drivers/usb/host/ohci.h include/linux/usb/ > $ sed -i 's/\"ohci.h\"//g' $(git ls-files) > > then add your ohci_reset() function... Hmm but then again it's pointless to export the all the ohci registers as that will lead to misuse outside drivers/usb.. Sounds like just defining the reset register is safest option here. > > I don't want to have driver specific code under arch/arm/*omap*/* as > > the bus level code should not need to know anything about the driver > > specific registers. > > I see. Regards, Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Mon, 11 Jun 2012 01:03:42 -0700 Subject: [PATCHv2 09/12] ARM: OMAP2+: usb_host_fs: add custom setup_preprogram for usb_host_fs (fsusb) In-Reply-To: <20120611074854.GG6845@arwen.pp.htv.fi> References: <20120611004502.20034.8840.stgit@dusk> <20120611004617.20034.21714.stgit@dusk> <20120611063416.GT12766@atomide.com> <20120611071301.GC6845@arwen.pp.htv.fi> <20120611074133.GZ12766@atomide.com> <20120611074854.GG6845@arwen.pp.htv.fi> Message-ID: <20120611080341.GA12766@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Felipe Balbi [120611 00:55]: > Hi, > > On Mon, Jun 11, 2012 at 12:41:33AM -0700, Tony Lindgren wrote: > > > > This should be "static inline int fsusb_reset_host_controller" as it's > > > > in a header. > > > > > > why is it even in a header ? Only hwmod_fsusb_preprogram() will use it > > > anyway. > > > > Well ideally it would be something that any OHCI driver can use for > > it's reset, and whatever bus code can also call to reset and idle > > for the unused devices that don't have the driver compiled in. Got > > any better suggestions where to place it? I could be a generic > > ohci_reset function in some header? > > maybe create ? Then, while doing that, move register > definitions to this new header too... Something like: > > $ mv drivers/usb/host/ohci.h include/linux/usb/ > $ sed -i 's/\"ohci.h\"//g' $(git ls-files) > > then add your ohci_reset() function... Hmm but then again it's pointless to export the all the ohci registers as that will lead to misuse outside drivers/usb.. Sounds like just defining the reset register is safest option here. > > I don't want to have driver specific code under arch/arm/*omap*/* as > > the bus level code should not need to know anything about the driver > > specific registers. > > I see. Regards, Tony