From: Tom Rix <trix@redhat.com> To: "Wu, Hao" <hao.wu@intel.com>, Moritz Fischer <mdf@kernel.org> Cc: "corbet@lwn.net" <corbet@lwn.net>, "michal.simek@xilinx.com" <michal.simek@xilinx.com>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "krzysztof.kozlowski@canonical.com" <krzysztof.kozlowski@canonical.com>, "nava.manne@xilinx.com" <nava.manne@xilinx.com>, "Xu, Yilun" <yilun.xu@intel.com>, "davidgow@google.com" <davidgow@google.com>, "fpacheco@redhat.com" <fpacheco@redhat.com>, "Gong, Richard" <richard.gong@intel.com>, "luca@lucaceresoli.net" <luca@lucaceresoli.net>, "linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout Date: Thu, 17 Jun 2021 06:21:07 -0700 [thread overview] Message-ID: <9c527087-3646-2f22-1234-2b0247511cc9@redhat.com> (raw) In-Reply-To: <DM6PR11MB381924F43550A6699CB55213850E9@DM6PR11MB3819.namprd11.prod.outlook.com> On 6/17/21 1:34 AM, Wu, Hao wrote: >> On Wed, Jun 16, 2021 at 01:05:36AM +0000, Wu, Hao wrote: >>>> On 6/15/21 1:08 AM, Wu, Hao wrote: >>>>>> Subject: [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout >>>>>> >>>>>> From: Tom Rix <trix@redhat.com> >>>>>> >>>>>> Follow drivers/net/ethernet/ which has control configs >>>>>> NET_VENDOR_BLA that map to drivers/net/ethernet/bla >>>>>> Since fpgas do not have many vendors, drop the 'VENDOR' and use >>>>>> FPGA_BLA. >>>>> Hi Tom, >>>>> >>>>> Thanks for this patch. : ) >>>>> >>>>> DFL is not a vendor, but something can be shared/reused. It's possible that >>>>> other vendors reuse the same concepts and the drivers of DFL. If vendor >>>>> drivers need to be moved inside sub folders, then maybe it's better to >>>>> leave DFL in the parent folder? >>>> xrt is also not a vendor, more a subdevice framework like dfl. >>>> >>>> I am not sure what you mean by other dfl vendors can you give an example ? >>> It's fine, but the description here is a little confusing on vendor/framework >>> handling. No other vendor so far, but it's possible, DFL can be used in >>> non-intel device, and related drivers can be reused as well. Then a fpga >>> mgr driver depends on DFL, should be put inside dfl folder or new >>> vendor's subfolder? >>> >>> Hao >>> >> I'm somewhat neutral on this. If someone non-intel starts using DFL we could >> also >> move the common parts back ... > That's fine. > >> That being said, I'm not super convinced we have to move stuff in the >> first place. > I remember that the first submission of our code is having everything inside a sub > folder, but was suggested that to have everything moved out, this is why we have > dfl files here now. To be honest, I have the similar feeling as you, I didn't see any > strong reason to make this something we must do, but both solutions should be > fine. : ) xrt is bringing in the subdir xrt/ Even after the likely move of xrt subdevices to other subsystems, there will be about as many files in fpga/xrt/ as in fpga/ If both of you are fine with a mixed files and subdir organization, then I'll drop this patchset. If you want only files, then xrt needs to refactor, so let them know. Tom > Thanks > Hao > >> - Moritz
WARNING: multiple messages have this Message-ID (diff)
From: Tom Rix <trix@redhat.com> To: "Wu, Hao" <hao.wu@intel.com>, Moritz Fischer <mdf@kernel.org> Cc: "corbet@lwn.net" <corbet@lwn.net>, "michal.simek@xilinx.com" <michal.simek@xilinx.com>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "krzysztof.kozlowski@canonical.com" <krzysztof.kozlowski@canonical.com>, "nava.manne@xilinx.com" <nava.manne@xilinx.com>, "Xu, Yilun" <yilun.xu@intel.com>, "davidgow@google.com" <davidgow@google.com>, "fpacheco@redhat.com" <fpacheco@redhat.com>, "Gong, Richard" <richard.gong@intel.com>, "luca@lucaceresoli.net" <luca@lucaceresoli.net>, "linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout Date: Thu, 17 Jun 2021 06:21:07 -0700 [thread overview] Message-ID: <9c527087-3646-2f22-1234-2b0247511cc9@redhat.com> (raw) In-Reply-To: <DM6PR11MB381924F43550A6699CB55213850E9@DM6PR11MB3819.namprd11.prod.outlook.com> On 6/17/21 1:34 AM, Wu, Hao wrote: >> On Wed, Jun 16, 2021 at 01:05:36AM +0000, Wu, Hao wrote: >>>> On 6/15/21 1:08 AM, Wu, Hao wrote: >>>>>> Subject: [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout >>>>>> >>>>>> From: Tom Rix <trix@redhat.com> >>>>>> >>>>>> Follow drivers/net/ethernet/ which has control configs >>>>>> NET_VENDOR_BLA that map to drivers/net/ethernet/bla >>>>>> Since fpgas do not have many vendors, drop the 'VENDOR' and use >>>>>> FPGA_BLA. >>>>> Hi Tom, >>>>> >>>>> Thanks for this patch. : ) >>>>> >>>>> DFL is not a vendor, but something can be shared/reused. It's possible that >>>>> other vendors reuse the same concepts and the drivers of DFL. If vendor >>>>> drivers need to be moved inside sub folders, then maybe it's better to >>>>> leave DFL in the parent folder? >>>> xrt is also not a vendor, more a subdevice framework like dfl. >>>> >>>> I am not sure what you mean by other dfl vendors can you give an example ? >>> It's fine, but the description here is a little confusing on vendor/framework >>> handling. No other vendor so far, but it's possible, DFL can be used in >>> non-intel device, and related drivers can be reused as well. Then a fpga >>> mgr driver depends on DFL, should be put inside dfl folder or new >>> vendor's subfolder? >>> >>> Hao >>> >> I'm somewhat neutral on this. If someone non-intel starts using DFL we could >> also >> move the common parts back ... > That's fine. > >> That being said, I'm not super convinced we have to move stuff in the >> first place. > I remember that the first submission of our code is having everything inside a sub > folder, but was suggested that to have everything moved out, this is why we have > dfl files here now. To be honest, I have the similar feeling as you, I didn't see any > strong reason to make this something we must do, but both solutions should be > fine. : ) xrt is bringing in the subdir xrt/ Even after the likely move of xrt subdevices to other subsystems, there will be about as many files in fpga/xrt/ as in fpga/ If both of you are fine with a mixed files and subdir organization, then I'll drop this patchset. If you want only files, then xrt needs to refactor, so let them know. Tom > Thanks > Hao > >> - Moritz _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-06-17 13:21 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-14 20:16 [PATCH v4 0/4] fpga: reorganize to subdirs trix 2021-06-14 20:16 ` trix 2021-06-14 20:16 ` [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout trix 2021-06-14 20:16 ` trix 2021-06-15 8:08 ` Wu, Hao 2021-06-15 8:08 ` Wu, Hao 2021-06-15 20:48 ` Tom Rix 2021-06-15 20:48 ` Tom Rix 2021-06-16 1:05 ` Wu, Hao 2021-06-16 1:05 ` Wu, Hao 2021-06-17 4:43 ` Moritz Fischer 2021-06-17 4:43 ` Moritz Fischer 2021-06-17 8:34 ` Wu, Hao 2021-06-17 8:34 ` Wu, Hao 2021-06-17 13:21 ` Tom Rix [this message] 2021-06-17 13:21 ` Tom Rix 2021-06-18 22:04 ` Moritz Fischer 2021-06-18 22:04 ` Moritz Fischer 2021-06-14 20:16 ` [PATCH v4 2/4] fpga: xilinx: " trix 2021-06-14 20:16 ` trix 2021-06-15 7:36 ` Greg KH 2021-06-15 7:36 ` Greg KH 2021-06-15 20:19 ` Tom Rix 2021-06-15 20:19 ` Tom Rix 2021-06-16 6:44 ` Greg KH 2021-06-16 6:44 ` Greg KH 2021-06-14 20:16 ` [PATCH v4 3/4] fpga: altera: " trix 2021-06-14 20:16 ` trix 2021-06-14 20:16 ` [PATCH v4 4/4] fpga: lattice: " trix 2021-06-14 20:16 ` trix
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=9c527087-3646-2f22-1234-2b0247511cc9@redhat.com \ --to=trix@redhat.com \ --cc=corbet@lwn.net \ --cc=davidgow@google.com \ --cc=fpacheco@redhat.com \ --cc=gregkh@linuxfoundation.org \ --cc=hao.wu@intel.com \ --cc=krzysztof.kozlowski@canonical.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-fpga@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luca@lucaceresoli.net \ --cc=mdf@kernel.org \ --cc=michal.simek@xilinx.com \ --cc=nava.manne@xilinx.com \ --cc=richard.gong@intel.com \ --cc=yilun.xu@intel.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: linkBe 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.