On Wednesday 06 January 2021 15:27:07 Russell King - ARM Linux admin wrote:
> On Wed, Jan 06, 2021 at 03:23:38PM +, Russell King - ARM Linux admin
> wrote:
> > On Wed, Jan 06, 2021 at 03:21:38PM +, Russell King - ARM Linux admin
> > wrote:
> > > On Wed, Jan 06, 2021 at 03:55:32PM +0100,
On Wed, Jan 06, 2021 at 03:23:38PM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 06, 2021 at 03:21:38PM +, Russell King - ARM Linux admin
> wrote:
> > On Wed, Jan 06, 2021 at 03:55:32PM +0100, Pali Rohár wrote:
> > > On my tested CarlitoxxPro module is:
> > >
> > >
On Wed, Jan 06, 2021 at 03:21:38PM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 06, 2021 at 03:55:32PM +0100, Pali Rohár wrote:
> > On my tested CarlitoxxPro module is:
> >
> > Option values : 0x00 0x1c
> > Option
On Wed, Jan 06, 2021 at 03:55:32PM +0100, Pali Rohár wrote:
> On my tested CarlitoxxPro module is:
>
> Option values : 0x00 0x1c
> Option: RX_LOS implemented,
> inverted
> Option
On Sunday 03 January 2021 03:41:32 Pali Rohár wrote:
> Hello!
>
> On Sunday 03 January 2021 03:25:23 Thomas Schreiber wrote:
> > Hi Pali,
> > I have a CarlitoxxPro module and I reported an issue about RX_LOS pin
> > to the manufacturer.
> > It looks to me that the module asserts "inverted LOS"
Hello!
On Sunday 03 January 2021 03:25:23 Thomas Schreiber wrote:
> Hi Pali,
> I have a CarlitoxxPro module and I reported an issue about RX_LOS pin
> to the manufacturer.
> It looks to me that the module asserts "inverted LOS" through EEPROM
> but does not implement it.
So, it is broken :-( But
Hi Pali,
I have a CarlitoxxPro module and I reported an issue about RX_LOS pin
to the manufacturer.
It looks to me that the module asserts "inverted LOS" through EEPROM
but does not implement it. Consequently, the SFP state machine of my
host router stays in check los state and link is not set up
On Thursday 31 December 2020 18:13:38 Andrew Lunn wrote:
> > > Looking at sfp_module_info(), adding a check for i2c_block_size < 2
> > > when determining what length to return. ethtool should do the right
> > > thing, know that the second page has not been returned to user space.
> >
> > But if
> > Looking at sfp_module_info(), adding a check for i2c_block_size < 2
> > when determining what length to return. ethtool should do the right
> > thing, know that the second page has not been returned to user space.
>
> But if we limit length of eeprom then userspace would not be able to
>
On Thursday 31 December 2020 16:30:33 Andrew Lunn wrote:
> On Thu, Dec 31, 2020 at 01:14:10PM +0100, Pali Rohár wrote:
> > On Wednesday 30 December 2020 19:09:58 Russell King - ARM Linux admin wrote:
> > > On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> > > > On Wednesday 30 December
On Thursday 31 December 2020 16:09:25 Andrew Lunn wrote:
> On Thu, Dec 31, 2020 at 01:14:10PM +0100, Pali Rohár wrote:
> > On Wednesday 30 December 2020 19:09:58 Russell King - ARM Linux admin wrote:
> > > On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> > > > On Wednesday 30 December
On Thu, Dec 31, 2020 at 01:14:10PM +0100, Pali Rohár wrote:
> On Wednesday 30 December 2020 19:09:58 Russell King - ARM Linux admin wrote:
> > On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> > > On Wednesday 30 December 2020 18:13:15 Andrew Lunn wrote:
> > > > Hi Pali
> > > >
> > >
On Thu, Dec 31, 2020 at 01:14:10PM +0100, Pali Rohár wrote:
> On Wednesday 30 December 2020 19:09:58 Russell King - ARM Linux admin wrote:
> > On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> > > On Wednesday 30 December 2020 18:13:15 Andrew Lunn wrote:
> > > > Hi Pali
> > > >
> > >
On Wednesday 30 December 2020 19:09:58 Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> > On Wednesday 30 December 2020 18:13:15 Andrew Lunn wrote:
> > > Hi Pali
> > >
> > > I have to agree with Russell here. I would rather have no diagnostics
> Which shows why it's pointless producing an EEPROM validation tool that
> runs under Linux (as has been your suggestion). They won't use it,
> since their testing only goes as far as "does it work in our product?"
Yes, i would need SNIA to push for conformance testing, hold
plug-testing events,
On Wed, Dec 30, 2020 at 08:30:52PM +0100, Andrew Lunn wrote:
> > Ok!
> >
> > So should we completely skip hwmon_device_register_with_info() call
> > if (i2c_block_size < 2) ?
>
> Yep. That would be a nice simple test.
>
> But does ethtool -m still export the second page? That is also
>
> Ok!
>
> So should we completely skip hwmon_device_register_with_info() call
> if (i2c_block_size < 2) ?
Yep. That would be a nice simple test.
But does ethtool -m still export the second page? That is also
unreliable.
Andrew
On Wed, Dec 30, 2020 at 06:31:52PM +0100, Pali Rohár wrote:
> On Wednesday 30 December 2020 17:05:46 Russell King - ARM Linux admin wrote:
> > On Wed, Dec 30, 2020 at 05:56:34PM +0100, Pali Rohár wrote:
> > > This change is really required for those Realtek chips. I thought that
> > > it is
On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> On Wednesday 30 December 2020 18:13:15 Andrew Lunn wrote:
> > Hi Pali
> >
> > I have to agree with Russell here. I would rather have no diagnostics
> > than untrustable diagnostics.
>
> Ok!
>
> So should we completely skip
On Wednesday 30 December 2020 18:13:15 Andrew Lunn wrote:
> On Wed, Dec 30, 2020 at 05:05:46PM +, Russell King - ARM Linux admin
> wrote:
> > On Wed, Dec 30, 2020 at 05:56:34PM +0100, Pali Rohár wrote:
> > > This change is really required for those Realtek chips. I thought that
> > > it is
On Wednesday 30 December 2020 17:05:46 Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 05:56:34PM +0100, Pali Rohár wrote:
> > This change is really required for those Realtek chips. I thought that
> > it is obvious that from *both* addresses 0x50 and 0x51 can be read only
> > one
On Wed, Dec 30, 2020 at 05:05:46PM +, Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 05:56:34PM +0100, Pali Rohár wrote:
> > This change is really required for those Realtek chips. I thought that
> > it is obvious that from *both* addresses 0x50 and 0x51 can be read only
> >
On Wed, Dec 30, 2020 at 05:56:34PM +0100, Pali Rohár wrote:
> This change is really required for those Realtek chips. I thought that
> it is obvious that from *both* addresses 0x50 and 0x51 can be read only
> one byte at the same time. Reading 2 bytes (for be16 value) cannot be
> really done by
On Wednesday 30 December 2020 16:10:37 Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 04:47:52PM +0100, Pali Rohár wrote:
> > Workaround for GPON SFP modules based on VSOL V2801F brand was added in
> > commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490
> >
On Wed, Dec 30, 2020 at 04:47:52PM +0100, Pali Rohár wrote:
> Workaround for GPON SFP modules based on VSOL V2801F brand was added in
> commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490
> v2.0 workaround"). But it works only for ids explicitly added to the list.
> As there
Workaround for GPON SFP modules based on VSOL V2801F brand was added in
commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490
v2.0 workaround"). But it works only for ids explicitly added to the list.
As there are more rebraded VSOL V2801F modules and OEM vendors are putting
into
26 matches
Mail list logo
