All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v3 1/6] PCI: rockchip: Create individual folder for rockchip drivers
Date: Thu, 22 Mar 2018 09:47:35 +0100	[thread overview]
Message-ID: <20180322084735.GC6211@kroah.com> (raw)
In-Reply-To: <7275bd77-016a-2729-482d-2855703d9b56@rock-chips.com>

On Thu, Mar 22, 2018 at 09:03:58AM +0800, Shawn Lin wrote:
> [+ Greg]

Why me?

> > It would be OK for me to keep files separate too; a separate question
> > would then be whether we have to rename drivers/pci/host if we add
> > endpoint drivers in there, do we have to?
> > 
> > At that stage we could well move drivers/pci/dwc and drivers/pci/cadence
> > in there too.
> > 
> 
> I add Greg to this thread, and hope he could shed a light here.
> 
> That is completely the same situation annoying me when looking into
> drivers/usb where they have drivers/usb/host/ for host drivers,
> drivers/usb/gadget/ for device framwork, drivers/usb/gaget/udc for
> device drivers, and even surprisingly drivers/usb/dwc2/,
> drivers/usb/dwc3/ and drivers/usb/renesas_usbhs/ for supporting both of
> host and device functional drivers....

USB is "messy" in that we have hardware that acts both as a host and a
gadget controller.  Don't use our directory scheme as an example to do
anything :)

Do what is right for the PCI subsystem, if a driver is too "complex"
that it needs lots of different files, make a subdirectory to make it
easier to manage.  That's all we did for USB, nothing really complex.

good luck!

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
To: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Lorenzo Pieralisi
	<lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH v3 1/6] PCI: rockchip: Create individual folder for rockchip drivers
Date: Thu, 22 Mar 2018 09:47:35 +0100	[thread overview]
Message-ID: <20180322084735.GC6211@kroah.com> (raw)
In-Reply-To: <7275bd77-016a-2729-482d-2855703d9b56-TNX95d0MmH7DzftRWevZcw@public.gmane.org>

On Thu, Mar 22, 2018 at 09:03:58AM +0800, Shawn Lin wrote:
> [+ Greg]

Why me?

> > It would be OK for me to keep files separate too; a separate question
> > would then be whether we have to rename drivers/pci/host if we add
> > endpoint drivers in there, do we have to?
> > 
> > At that stage we could well move drivers/pci/dwc and drivers/pci/cadence
> > in there too.
> > 
> 
> I add Greg to this thread, and hope he could shed a light here.
> 
> That is completely the same situation annoying me when looking into
> drivers/usb where they have drivers/usb/host/ for host drivers,
> drivers/usb/gadget/ for device framwork, drivers/usb/gaget/udc for
> device drivers, and even surprisingly drivers/usb/dwc2/,
> drivers/usb/dwc3/ and drivers/usb/renesas_usbhs/ for supporting both of
> host and device functional drivers....

USB is "messy" in that we have hardware that acts both as a host and a
gadget controller.  Don't use our directory scheme as an example to do
anything :)

Do what is right for the PCI subsystem, if a driver is too "complex"
that it needs lots of different files, make a subdirectory to make it
easier to manage.  That's all we did for USB, nothing really complex.

good luck!

greg k-h

  reply	other threads:[~2018-03-22  8:47 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-06  2:42 [PATCH v3 0/6] Add endpoint driver for Rockchip PCIe controller Shawn Lin
2018-03-06  2:42 ` Shawn Lin
2018-03-06  2:43 ` [PATCH v3 1/6] PCI: rockchip: Create individual folder for rockchip drivers Shawn Lin
2018-03-06  2:43   ` Shawn Lin
2018-03-20 14:04   ` Lorenzo Pieralisi
2018-03-20 14:04     ` Lorenzo Pieralisi
2018-03-21  0:47     ` Shawn Lin
2018-03-21  0:47       ` Shawn Lin
2018-03-20 17:46   ` Bjorn Helgaas
2018-03-20 17:46     ` Bjorn Helgaas
2018-03-21  1:04     ` Shawn Lin
2018-03-21  1:04       ` Shawn Lin
2018-03-21 18:19       ` Lorenzo Pieralisi
2018-03-21 18:19         ` Lorenzo Pieralisi
2018-03-21 19:30         ` Bjorn Helgaas
2018-03-21 19:30           ` Bjorn Helgaas
2018-03-22  1:03         ` Shawn Lin
2018-03-22  1:03           ` Shawn Lin
2018-03-22  8:47           ` Greg Kroah-Hartman [this message]
2018-03-22  8:47             ` Greg Kroah-Hartman
2018-03-22 11:09             ` Shawn Lin
2018-03-22 11:09               ` Shawn Lin
2018-03-22 11:30           ` Lorenzo Pieralisi
2018-03-22 11:30             ` Lorenzo Pieralisi
2018-03-06  2:43 ` [PATCH v3 2/6] PCI: rockchip: Split out common function to parse DT Shawn Lin
2018-03-06  2:43   ` Shawn Lin
2018-03-06  2:43 ` [PATCH v3 3/6] PCI: rockchip: Split out common function to init controller Shawn Lin
2018-03-06  2:43   ` Shawn Lin
2018-03-06  2:43 ` [PATCH v3 4/6] dt-bindings: PCI: rockchip: Rename rockchip-pcie.txt to rockchip-pcie-host.txt Shawn Lin
2018-03-06  2:43   ` Shawn Lin
2018-03-06  2:44 ` [PATCH v3 5/6] PCI: rockchip: Add Endpoint controller driver for Rockchip PCIe controller Shawn Lin
2018-03-06  2:44   ` Shawn Lin
2018-03-06  2:44 ` [PATCH v3 6/6] dt-bindings: PCI: rockchip: Add DT bindings for Rockchip PCIe endpoint controller Shawn Lin
2018-03-06  2:44   ` Shawn Lin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180322084735.GC6211@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=shawn.lin@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.