assuming the existance of page 0x10 and 0x11
* Remove structs and constants related to the page 0x10 and 0x11
Diff from v3:
* Added missing Signed-off-by and Tested-by tags
Diff from v4:
* Fix whitespace formatting problems
Signed-off-by: Adrian Pop
Tested-by: Ido Schimmel
Reviewed-by: Andrew
assuming the existance of page 0x10 and 0x11
* Remove structs and constants related to the page 0x10 and 0x11
Diff from v3:
* Added missing Signed-off-by and Tested-by tags
Signed-off-by: Adrian Pop
Tested-by: Ido Schimmel
---
Makefile.am | 2 +-
qsfp-dd.c| 333
Hi!
Sorry for that. I'll resubmit v4 and I'll add diff from v1, diff from
v2 and diff from v3.
I will also add Michal Kubecek.
Adrian
On Thu, 13 Aug 2020 at 12:24, Ido Schimmel wrote:
>
> On Thu, Aug 13, 2020 at 10:17:35AM +0300, Adrian Pop wrote:
> > The Commo
just noticed I forgot to sign-off the patch. Can the following
lines be added by you or it's me who needs to add them by
re-submitting?
Signed-off-by: Adrian Pop
Tested-by: Ido Schimmel
Thank you!
Adrian
On Sat, 8 Aug 2020 at 17:30, Andrew Lunn wrote:
>
> On Thu, Aug 06, 2020 at 07:21:21
The Common Management Interface Specification (CMIS) for QSFP-DD shares
some similarities with other form factors such as QSFP or SFP, but due to
the fact that the module memory map is different, the current ethtool
version is not able to provide relevant information about an interface.
This patch
Hi Andrew!
Should I resubmit v3 after I delete the code that has to do with page
0x10 and 0x11?
Adrian
On Thu, 6 Aug 2020 at 21:08, Andrew Lunn wrote:
>
> Hi Adrian
>
> > +static void
> > +qsfp_dd_parse_diagnostics(const __u8 *id, struct qsfp_dd_diags *const sd)
> > +{
> > + __u16 rx_power_
>
> Branch "next" is merged into master now so you can base v2 on master.
>
Hi Michal!
Just submitted v2. I fixed the little problems noticed by Ido and you.
The submission consists of only one patch, since I noticed that some
extra whitespace 'fixes' were wrongly introduced by my editor so I
sup
length in meters instead of kilometers
* Fix bad value for QSFP_DD_DATE_VENDOR_LOT_OFFSET
* Fix initialization for struct qsfp_dd_diags
* Remove unrelated whitespace cleanups in qsfp.c and Makefile.am
Signed-off-by: Adrian Pop
Tested-by: Ido Schimmel
---
Makefile.am | 2 +-
qsfp-dd.c| 553
>
> AFAICS the kernel counterpart is going to reach mainline in 5.9-rc1
> merge window. Please base your patch on "next" branch or wait until next
> is merged into master after 5.8 release (which should be later today or
> tomorrow).
I will wait until tomorrow and rebase my patch onto master then.
Hi Andrew, Ido!
> Hi Adrian, thanks again for submitting this patch. I got two comments
> off-list. Sharing them here.
Thanks for pointing that out, I took a look and you're right. I'll fix them.
> Didn't we discuss that page 3 might be useful? I would prefer not to
> document that pages 0x10 an
| 128B | 128B |
+--+--+--+--+--+--
Several functions from qsfp.c could be reused, so an additional parameter
was added to each and the functions were moved to sff-common.c.
Signed-off-by: Adrian Pop
Tested-by: Ido Schimmel
or its presence better than me. Based on that, I can
re-submit my old patch for ethtool.
Adrian
On Sun, 28 Jun 2020 at 12:56, Ido Schimmel wrote:
>
> On Sat, Jun 27, 2020 at 09:42:10PM +0100, Adrian Pop wrote:
> > >
> > > Hi Adrian, Andrew,
> > >
> > >
>
> Hi Adrian, Andrew,
>
> Not sure I understand... You want the kernel to always pass page 03h to
> user space (potentially zeroed)? Page 03h is not mandatory according to
> the standard and page 01h contains information if page 03h is present or
Hi Ido!
Andrew was thinking of having 03h after 0
> You are saying pages 00h, 01h and 02h are mandatory for QSPF-DD. Page
> 03h is optional, but when present, it seems to contain what is page
> 02h above. Since the QSPF KAPI has it, QSPF-DD KAPI should also have
> it. So i would suggest that pages 10h and 11h come after that.
>
> If a driver want
>
> Is page 03h valid for a QSFP DD? Do we add pages 10h and 11h after
> page 03h, or instead of? How do we indicate to user space what pages
> of data have been passed to it?
>
>Andrew
>From QSFP-DD CMIS Rev 4.0: "In particular, support of the Lower Memory
and of Page 00h is required for all
Hi Ido, Andrew!
I'm happy to receive these emails and to see that my old patch had
some interest. Yes, at that time there was no official support for
QSFP-DD in the upstream kernel. I was able to test my code using a
custom driver we developed in my company. If everything works out, I'd
be happy t
16 matches
Mail list logo
