| Message ID | 20230329140404.1647925-1-pavan.kumar.linga@intel.com |
|---|---|
| Headers | show |
| Series | Introduce IDPF driver | expand |
Dear Pavan, Thank you very much for the new driver. It’s a lot of code. ;-) Am 29.03.23 um 16:03 schrieb Pavan Kumar Linga: > This patch series introduces the Infrastructure Data Path Function (IDPF) > driver. It is used for both physical and virtual functions. Except for > some of the device operations the rest of the functionality is the same > for both PF and VF. IDPF uses virtchnl version2 opcodes and structures > defined in the virtchnl2 header file which helps the driver to learn > the capabilities and register offsets from the device Control Plane (CP) > instead of assuming the default values. > > The format of the series follows the driver init flow to interface open. > To start with, probe gets called and kicks off the driver initialization > by spawning the 'vc_event_task' work queue which in turn calls the > 'hard reset' function. As part of that, the mailbox is initialized which > is used to send/receive the virtchnl messages to/from the CP. Once that is > done, 'core init' kicks in which requests all the required global resources > from the CP and spawns the 'init_task' work queue to create the vports. > > Based on the capability information received, the driver creates the said > number of vports (one or many) where each vport is associated to a netdev. > Also, each vport has its own resources such as queues, vectors etc. > From there, rest of the netdev_ops and data path are added. > > IDPF implements both single queue which is traditional queueing model > as well as split queue model. In split queue model, it uses separate queue > for both completion descriptors and buffers which helps to implement > out-of-order completions. It also helps to implement asymmetric queues, > for example multiple RX completion queues can be processed by a single > RX buffer queue and multiple TX buffer queues can be processed by a > single TX completion queue. In single queue model, same queue is used > for both descriptor completions as well as buffer completions. It also > supports features such as generic checksum offload, generic receive > offload (hardware GRO) etc. […] Can you please elaborate on how the driver can be tested, and if tests are added to automatically test the driver? Kind regards, Paul
On Wed, Mar 29, 2023 at 10:07 AM Pavan Kumar Linga <pavan.kumar.linga@intel.com> wrote: > > This patch series introduces the Infrastructure Data Path Function (IDPF) > driver. It is used for both physical and virtual functions. Except for > some of the device operations the rest of the functionality is the same > for both PF and VF. IDPF uses virtchnl version2 opcodes and structures > defined in the virtchnl2 header file which helps the driver to learn > the capabilities and register offsets from the device Control Plane (CP) > instead of assuming the default values. > > The format of the series follows the driver init flow to interface open. > To start with, probe gets called and kicks off the driver initialization > by spawning the 'vc_event_task' work queue which in turn calls the > 'hard reset' function. As part of that, the mailbox is initialized which > is used to send/receive the virtchnl messages to/from the CP. Once that is > done, 'core init' kicks in which requests all the required global resources > from the CP and spawns the 'init_task' work queue to create the vports. > > Based on the capability information received, the driver creates the said > number of vports (one or many) where each vport is associated to a netdev. > Also, each vport has its own resources such as queues, vectors etc. > From there, rest of the netdev_ops and data path are added. > > IDPF implements both single queue which is traditional queueing model > as well as split queue model. In split queue model, it uses separate queue > for both completion descriptors and buffers which helps to implement > out-of-order completions. It also helps to implement asymmetric queues, > for example multiple RX completion queues can be processed by a single > RX buffer queue and multiple TX buffer queues can be processed by a > single TX completion queue. In single queue model, same queue is used > for both descriptor completions as well as buffer completions. It also > supports features such as generic checksum offload, generic receive > offload (hardware GRO) etc. > > Pavan Kumar Linga (15): > virtchnl: add virtchnl version 2 ops > idpf: add module register and probe functionality > idpf: add controlq init and reset checks > idpf: add core init and interrupt request > idpf: add create vport and netdev configuration > idpf: continue expanding init task > idpf: configure resources for TX queues > idpf: configure resources for RX queues > idpf: initialize interrupts and enable vport > idpf: add splitq start_xmit > idpf: add TX splitq napi poll support > idpf: add RX splitq napi poll support > idpf: add singleq start_xmit and napi poll > idpf: add ethtool callbacks > idpf: configure SRIOV and add other ndo_ops > > .../device_drivers/ethernet/intel/idpf.rst | 46 + > drivers/net/ethernet/intel/Kconfig | 11 + > drivers/net/ethernet/intel/Makefile | 1 + > drivers/net/ethernet/intel/idpf/Makefile | 18 + > drivers/net/ethernet/intel/idpf/idpf.h | 734 +++ > .../net/ethernet/intel/idpf/idpf_controlq.c | 644 +++ > .../net/ethernet/intel/idpf/idpf_controlq.h | 131 + > .../ethernet/intel/idpf/idpf_controlq_api.h | 190 + > .../ethernet/intel/idpf/idpf_controlq_setup.c | 175 + > drivers/net/ethernet/intel/idpf/idpf_dev.c | 179 + > drivers/net/ethernet/intel/idpf/idpf_devids.h | 10 + > .../net/ethernet/intel/idpf/idpf_ethtool.c | 1325 +++++ > .../ethernet/intel/idpf/idpf_lan_pf_regs.h | 124 + > .../net/ethernet/intel/idpf/idpf_lan_txrx.h | 293 + > .../ethernet/intel/idpf/idpf_lan_vf_regs.h | 128 + > drivers/net/ethernet/intel/idpf/idpf_lib.c | 2551 +++++++++ > drivers/net/ethernet/intel/idpf/idpf_main.c | 85 + > drivers/net/ethernet/intel/idpf/idpf_mem.h | 20 + > .../ethernet/intel/idpf/idpf_singleq_txrx.c | 1262 +++++ > drivers/net/ethernet/intel/idpf/idpf_txrx.c | 4850 +++++++++++++++++ > drivers/net/ethernet/intel/idpf/idpf_txrx.h | 838 +++ > drivers/net/ethernet/intel/idpf/idpf_vf_dev.c | 180 + > .../net/ethernet/intel/idpf/idpf_virtchnl.c | 3802 +++++++++++++ > drivers/net/ethernet/intel/idpf/virtchnl2.h | 1153 ++++ > .../ethernet/intel/idpf/virtchnl2_lan_desc.h | 644 +++ > 25 files changed, 19394 insertions(+) > create mode 100644 Documentation/networking/device_drivers/ethernet/intel/idpf.rst > create mode 100644 drivers/net/ethernet/intel/idpf/Makefile > create mode 100644 drivers/net/ethernet/intel/idpf/idpf.h > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_controlq.c > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_controlq.h > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_controlq_api.h > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_controlq_setup.c > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_dev.c > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_devids.h > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_ethtool.c > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_lan_pf_regs.h > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_lan_txrx.h > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_lan_vf_regs.h > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_lib.c > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_main.c > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_mem.h > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_txrx.c > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_txrx.h > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_vf_dev.c > create mode 100644 drivers/net/ethernet/intel/idpf/idpf_virtchnl.c > create mode 100644 drivers/net/ethernet/intel/idpf/virtchnl2.h > create mode 100644 drivers/net/ethernet/intel/idpf/virtchnl2_lan_desc.h > > -- > 2.37.3 Reviewed-by: David Decotigny <decot@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Tested-by: David Decotigny <decot@google.com> Tested-by: Willem de Bruijn <willemb@google.com> We have been working with this driver at Google for well over a year through multiple revisions. The current version runs in continuous testing with both functional (RSS, checksum, TSO/USO, HW-GRO, etc., many from tools/testing/selftests/net) and performance (github.com/google/neper tcp_stream, tcp_rr, etc. in variety of #threads and #flows configurations) tests, including ASAN, lockdep. The driver is also exercised continuously with more varied application workloads.
On Wed, Mar 29, 2023 at 07:03:49AM -0700, Pavan Kumar Linga wrote: > This patch series introduces the Infrastructure Data Path Function (IDPF) > driver. It is used for both physical and virtual functions. Except for > some of the device operations the rest of the functionality is the same > for both PF and VF. IDPF uses virtchnl version2 opcodes and structures > defined in the virtchnl2 header file which helps the driver to learn > the capabilities and register offsets from the device Control Plane (CP) > instead of assuming the default values. Isn't IDPF currently being "standardized" at OASIS? Has a standard been ratified? Isn't it rather premature to merge a driver for a standard that doesn't exist? Publicly posting pre-ratification work is often against the IP policies of standards orgs, are you even legally OK to post this? Confused, Jason
On Thu, 30 Mar 2023 09:03:09 -0300 Jason Gunthorpe wrote: > On Wed, Mar 29, 2023 at 07:03:49AM -0700, Pavan Kumar Linga wrote: > > This patch series introduces the Infrastructure Data Path Function (IDPF) > > driver. It is used for both physical and virtual functions. Except for > > some of the device operations the rest of the functionality is the same > > for both PF and VF. IDPF uses virtchnl version2 opcodes and structures > > defined in the virtchnl2 header file which helps the driver to learn > > the capabilities and register offsets from the device Control Plane (CP) > > instead of assuming the default values. > > Isn't IDPF currently being "standardized" at OASIS? > > Has a standard been ratified? Isn't it rather premature to merge a > driver for a standard that doesn't exist? > > Publicly posting pre-ratification work is often against the IP > policies of standards orgs, are you even legally OK to post this? > > Confused, And you called me politically motivated in the discussion about RDMA :| Vendor posts a driver, nothing special as far as netdev is concerned.
On Thu, Mar 30, 2023 at 10:25:05AM -0700, Jakub Kicinski wrote: > On Thu, 30 Mar 2023 09:03:09 -0300 Jason Gunthorpe wrote: > > On Wed, Mar 29, 2023 at 07:03:49AM -0700, Pavan Kumar Linga wrote: > > > This patch series introduces the Infrastructure Data Path Function (IDPF) > > > driver. It is used for both physical and virtual functions. Except for > > > some of the device operations the rest of the functionality is the same > > > for both PF and VF. IDPF uses virtchnl version2 opcodes and structures > > > defined in the virtchnl2 header file which helps the driver to learn > > > the capabilities and register offsets from the device Control Plane (CP) > > > instead of assuming the default values. > > > > Isn't IDPF currently being "standardized" at OASIS? > > > > Has a standard been ratified? Isn't it rather premature to merge a > > driver for a standard that doesn't exist? > > > > Publicly posting pre-ratification work is often against the IP > > policies of standards orgs, are you even legally OK to post this? > > > > Confused, > > And you called me politically motivated in the discussion about RDMA :| > Vendor posts a driver, nothing special as far as netdev is concerned. The patches directly link to the OASIS working group, they need to explain WTF is going on here. The published doucments they link to expressly say: This is version 0.9 of IDPF Specification, to serve as basis for IDPF TC work. This is a work-in-progress document, and should not be used for implementation as is. Further OASIS has a legal IPR policy that basically means Intel needs to publicly justify that their Signed-off-by is consisent with the kernel rules of the DCO. ie that they have a legal right to submit this IP to the kernel. It is frequent that people make IPR mistakes, it is something maintainers should be double-checking when they are aware of it. Frankly, this stopped being a "vendor driver" as soon as they linked to OASIS documents. More broadly we have seen good success in Linux with the standards-first model. NVMe for example will not merge "vendor extensions" and the like that are not in the published ratified standard. It gives more power to the standards bodies and encourages vendor collaboration. It is up to netdev community, but it looks pretty wild to see patches link to a supposed multi-vendor OASIS standard, put the implementation under net/ethernet/intel/idpf/ and come before standard ratification. It is a legitimate question if that is how netdev community wants to manage its standard backed drivers. Jason
On 3/29/2023 9:11 PM, Paul Menzel wrote: > Dear Pavan, > > > Thank you very much for the new driver. It’s a lot of code. ;-) > > Am 29.03.23 um 16:03 schrieb Pavan Kumar Linga: >> This patch series introduces the Infrastructure Data Path Function (IDPF) >> driver. It is used for both physical and virtual functions. Except for >> some of the device operations the rest of the functionality is the same >> for both PF and VF. IDPF uses virtchnl version2 opcodes and structures >> defined in the virtchnl2 header file which helps the driver to learn >> the capabilities and register offsets from the device Control Plane (CP) >> instead of assuming the default values. >> >> The format of the series follows the driver init flow to interface open. >> To start with, probe gets called and kicks off the driver initialization >> by spawning the 'vc_event_task' work queue which in turn calls the >> 'hard reset' function. As part of that, the mailbox is initialized which >> is used to send/receive the virtchnl messages to/from the CP. Once >> that is >> done, 'core init' kicks in which requests all the required global >> resources >> from the CP and spawns the 'init_task' work queue to create the vports. >> >> Based on the capability information received, the driver creates the said >> number of vports (one or many) where each vport is associated to a >> netdev. >> Also, each vport has its own resources such as queues, vectors etc. >> From there, rest of the netdev_ops and data path are added. >> >> IDPF implements both single queue which is traditional queueing model >> as well as split queue model. In split queue model, it uses separate >> queue >> for both completion descriptors and buffers which helps to implement >> out-of-order completions. It also helps to implement asymmetric queues, >> for example multiple RX completion queues can be processed by a single >> RX buffer queue and multiple TX buffer queues can be processed by a >> single TX completion queue. In single queue model, same queue is used >> for both descriptor completions as well as buffer completions. It also >> supports features such as generic checksum offload, generic receive >> offload (hardware GRO) etc. > > […] > > Can you please elaborate on how the driver can be tested, and if tests > are added to automatically test the driver? > > Not really sure on what tests are you referring to. Can you please elaborate on that part? We are looking into ways to provide remote access to the HW but don't have anything currently available. Will provide more details once that is sorted. > Kind regards, > > Paul Thanks, Pavan
Posting on behalf of Michael Orr, Intel. ==== I am Michael Orr, from Intel I am the Convener of IDPF TC at Oasis, and the Author of IDPF charter, so Probably the right Person to answer this. Due to tech issues in getting subscribed, I am asking my Colleague to post this into the thread. Bottom line: There is no issue in publishing this driver, and no conflict with OASIS IDPF TC. See point-by-point below On 3/30/2023 1:29 PM, Jason Gunthorpe wrote: > On Thu, Mar 30, 2023 at 10:25:05AM -0700, Jakub Kicinski wrote: >> On Thu, 30 Mar 2023 09:03:09 -0300 Jason Gunthorpe wrote: >>> On Wed, Mar 29, 2023 at 07:03:49AM -0700, Pavan Kumar Linga wrote: >>>> This patch series introduces the Infrastructure Data Path Function (IDPF) >>>> driver. It is used for both physical and virtual functions. Except for >>>> some of the device operations the rest of the functionality is the same >>>> for both PF and VF. IDPF uses virtchnl version2 opcodes and structures >>>> defined in the virtchnl2 header file which helps the driver to learn >>>> the capabilities and register offsets from the device Control Plane (CP) >>>> instead of assuming the default values. >>> >>> Isn't IDPF currently being "standardized" at OASIS? IDPF is indeed being Standardized at OASIS. Everyone is free (AND INVITED!) to join the work. >>> >>> Has a standard been ratified? Isn't it rather premature to merge a >>> driver for a standard that doesn't exist? The Standard has not been ratified. Work has just started recently. When IDPF TC members finish the work and vote to approve the result THAT version will be the OASIS Standard IDPF specification, and will have a reference driver to accompany it, likely labeled V1.0 >>> >>> Publicly posting pre-ratification work is often against the IP >>> policies of standards orgs, are you even legally OK to post this? Publishing this driver does not go against any IP policy of OASIS or the IDPF TC. There is no legal issue. >>> >>> Confused, >> >> And you called me politically motivated in the discussion about RDMA :| >> Vendor posts a driver, nothing special as far as netdev is concerned. > > The patches directly link to the OASIS working group, they need to > explain WTF is going on here. As explained in the Charter, Intel & Google are donating the current Vendor driver & its spec to the IDPF TC to serve as a starting point for an eventual vendor-agnostic Spec & Driver that will be the OASIS IDPF standard set. > > The published doucments they link to expressly say: > > This is version 0.9 of IDPF Specification, to serve as basis for IDPF > TC work. This is a work-in-progress document, and should not be used > for implementation as is. Since I wrote this: This is intended to state that version 0.9 is NOT *the* OASIS IDPF TC driver, just a base to start working from. We know the current version is not vendor independent and that it is likely changes will be added by the IDPF TC. > > Further OASIS has a legal IPR policy that basically means Intel needs > to publicly justify that their Signed-off-by is consisent with the > kernel rules of the DCO. ie that they have a legal right to submit > this IP to the kernel. OASIS does NOT have such a legal IPR policy. The only IPR policy that applies to the IDPF TC members is the “Non-assert” IPR policy as stated in the Charter. Any IDPF TC member company is free to publish any vendor driver they choose to. What they Publish is simply then their driver, and not an implementation of the OASIS IDPF Standard. IDPF Charter (And draft spec, and all other documents and mailings) are here: https://www.oasis-open.org/committees/documents.php?wg_abbrev=idpf&show_descriptions=yes OASIS IPR Policies for TC’s are here: https://www.oasis-open.org/policies-guidelines/ipr/ > > It is frequent that people make IPR mistakes, it is something > maintainers should be double-checking when they are aware of it. > > Frankly, this stopped being a "vendor driver" as soon as they linked > to OASIS documents. > > More broadly we have seen good success in Linux with the > standards-first model. NVMe for example will not merge "vendor > extensions" and the like that are not in the published ratified > standard. It gives more power to the standards bodies and encourages > vendor collaboration. > > It is up to netdev community, but it looks pretty wild to see patches > link to a supposed multi-vendor OASIS standard, put the implementation > under net/ethernet/intel/idpf/ and come before standard > ratification. > > It is a legitimate question if that is how netdev community wants to > manage its standard backed drivers. > > Jason
On Mon, Apr 03, 2023 at 04:36:56PM -0500, Samudrala, Sridhar wrote: > > Further OASIS has a legal IPR policy that basically means Intel needs > > to publicly justify that their Signed-off-by is consisent with the > > kernel rules of the DCO. ie that they have a legal right to submit > > this IP to the kernel. > > OASIS does NOT have such a legal IPR policy. The only IPR policy that > applies to the IDPF TC members is the “Non-assert” IPR policy as stated > in the Charter. Non-assert is relevant to inclusion in Linux and is part of what the DCO considers. According to the OASIS IPR non-assert doesn't automatically trigger just because information has been shared within a TC. As the submitter you need to explain that all IP and license issues are accounted for because *in general* taking work-in-progress out of a industry workgroup with an IPR is a problematic thing to include in Linux. eg you can say that the 0.9 document this series linked to has properly reached "OASIS Standards Draft Deliverable" and is thus covered by the IPR, or you can explain that all Intel has confirmed outside OASIS that all parties that contribued to the document clear the IP release, or perhaps even that Intel is the only IP owner. This abnormal thing just needs to be explained, maintainer's can't be left to guess if IP issues are correct. Jason
Jason - The Driver being published now is an Intel driver, under Intel directory, and using the Intel Device ID - because it is NOT the IDPF standard. It is a Vendor driver. Therefore all the discussion about any IPR policy applying to the OASIS TC work is simply irrelevant here. The reason OASIS is referenced is that since this Intel driver is the basis/starting point for an Eventual OASIS IDPF standard, anyone who has an interest in OASIS IDPF will have an interest in this driver even If they have no interest in Intel's Products. I (we) assume that there are many people in the mailing list who might be interested in at least keeping up with OASIS IDPF TC work, hence the OASIS references. Anyone who is not interested in OASIS IDPF can simply ignore this referencing. If you have additional questions, please reach out to me directly - I'll gladly discuss any concerns, but I think This should happen apart from this forum. My contact is below. P2P answers below -- Michael Orr NCNG Strategy & Roadmap Office WW Cell: (669)265-5995 Note: Dyslexic @Work. Please excuse my typos. (Remember, Dyslexics are teople, poo) -----Original Message----- From: Jason Gunthorpe <jgg@nvidia.com> Sent: Tuesday, April 4, 2023 7:42 PM To: Samudrala, Sridhar <sridhar.samudrala@intel.com> Cc: Jakub Kicinski <kuba@kernel.org>; Linga, Pavan Kumar <pavan.kumar.linga@intel.com>; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; Saleem, Shiraz <shiraz.saleem@intel.com>; Tantilov, Emil S <emil.s.tantilov@intel.com>; willemb@google.com; decot@google.com; Hay, Joshua A <joshua.a.hay@intel.com>; Christoph Hellwig <hch@lst.de>; Orr, Michael <michael.orr@intel.com>; Singhai, Anjali <anjali.singhai@intel.com> Subject: Re: [Intel-wired-lan] [PATCH net-next 00/15] Introduce IDPF driver On Mon, Apr 03, 2023 at 04:36:56PM -0500, Samudrala, Sridhar wrote: > > > Further OASIS has a legal IPR policy that basically means Intel > > > needs to publicly justify that their Signed-off-by is consisent with > > > the kernel rules of the DCO. ie that they have a legal right to > > > submit this IP to the kernel. > > > > OASIS does NOT have such a legal IPR policy. The only IPR policy that > > applies to the IDPF TC members is the “Non-assert” IPR policy as > > stated in the Charter. > Non-assert is relevant to inclusion in Linux and is part of what the DCO considers. According to the OASIS IPR non-assert doesn't automatically trigger just because information has been shared within a TC. The TC charter states that *All* TC work is under Non-Assert. Any materials/documents/code submitted to the TC do not change ownership, but they are covered by a "non-assert" license. this applies to Everything, not just final or draft deliverables. I have not seen any OASIS statement that says what you quote above, and the TC member companies have not agreed to any such. There is nothing needed to "trigger" non-assert and any information Shared in the TC *IS* under non-assert. When you sing up to the OASIS TC mailing list you agree to these terms. But more importantly: whatever OASIS's Policies/IPR are, they do not apply here. This driver upload is NOT part of the TC work, and OASIS has nothing to do with it. > As the submitter you need to explain that all IP and license issues are accounted for because *in general* taking work-in-progress out of a industry workgroup with an IPR is a problematic thing to include in Linux. I frankly do not understand what the above means, and how this would make "all IP and license issues are accounted for". Again - the driver published by intel here is not " taking work-in-progress out of a industry workgroup". On the contrary - this is an Intel Driver, that will be Donated INTO the OASIS TC Industry work-group. Even then, it will NOT be "THE" standard. It is just a way to speed up the TC work by having it not start from scratch. > eg you can say that the 0.9 document this series linked to has properly reached "OASIS Standards Draft Deliverable" and is thus covered by the IPR, > or you can explain that all Intel has confirmed outside OASIS that all parties that contribued to the document clear the IP release, or perhaps even that Intel is the > only IP owner. I am not planning to say any of these. 1. This driver has not reached "OASIS Standards Draft Deliverable" - in fact, I have no idea what this term means - it is not in the TC's milestones, and if this term has any legal/IPR significance, I do not know it. 2. This driver is an Intel driver, published as such, and has nothing to do with OASIS, and any and all OASIS Policies and IPR terms do not apply. When the IDPF TC will Publish an industry-standard IDPF driver - THAT driver, like all TC materials, will be under Non-Assert IPR policy - and nothing else. > This abnormal thing just needs to be explained, maintainer's can't be left to guess if IP issues are correct. > Jason
On Tue, Apr 04, 2023 at 07:19:54PM +0000, Orr, Michael wrote: > The Driver being published now is an Intel driver, under Intel > directory, and using the Intel Device ID - because it is NOT the > IDPF standard. It is a Vendor driver. This series literally said in patch 1 that it is implementing "virtchnl version 2" and links directly to unapproved OASIS documents as "the specification for reference". What you are saying may be the case, but it does not match what was submitted for review. Send a v2 with the references to OASIS scrubbed out of the series, and explain what you explained here in the cover letter - that this Intel IDPF is not derived from the other OASIS IDPF. Then you are fine. > I am not planning to say any of these. > 1. This driver has not reached "OASIS Standards Draft Deliverable" - > in fact, I have no idea what this term means - it is not in the TC's > milestones, and if this term has any legal/IPR significance, I do > not know it. It is a defined term in the OASIS IPR you linked to: 19. OASIS Standards Draft Deliverable - an OASIS Deliverable that has been designated and approved by a Technical Committee as an OASIS Standards Draft Deliverable and which is enumerated in and developed in accordance with the OASIS Technical Committee Process. IPR Section 6: ... a limited covenant not to assert any Essential Claims required to implement such OASIS Standards Draft Deliverable ... IPR Section 10.3 describes how the "non-assertion mode TC" works, and that the non-assertion covenant comes into full effect for a "OASIS Standards Final Deliverable" [defined term #20]. The OASIS document "TC Process" explains what steps a TC must do to achieve these milestones defined in the IPR. Achieving the milestones defined in the IPR unambiguously triggers the non-assertion convents and then we know the IP is safe to incorporate into Linux. As I've said a few times now, Linux requires submissions to be properly licensed and have IP rights compatible with the GPL. IPR is complicated, the knee jerk reaction should be to reject any patches implementing in-progress works from standards bodies. Jason
FYI, thanks to Michael for the feedback. > As explained in the Charter, Intel & Google are donating the current > Vendor driver & its spec to the IDPF TC to serve as a starting point for > an eventual vendor-agnostic Spec & Driver that will be the OASIS IDPF > standard set. Having both under the same name seems like a massive confusion.
On 4/6/23 9:39 PM, Christoph Hellwig wrote: > > FYI, thanks to Michael for the feedback. > >> As explained in the Charter, Intel & Google are donating the current >> Vendor driver & its spec to the IDPF TC to serve as a starting point for >> an eventual vendor-agnostic Spec & Driver that will be the OASIS IDPF >> standard set. > > Having both under the same name seems like a massive confusion. I was thinking something similar. If "idpf" is likely to be the final generic driver name (which makes sense), and Intel's driver is an Intel-device specific driver, can Intel use a more Intel-device specific name for their driver? This would help both in reminding us that this isn't intended as the vendor-agnostic driver, and would prevent potential future name confusion. sln