linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Lorenzo Carletti <lorenzo.carletti98@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	andrew@lunn.ch, vivien.didelot@gmail.com, f.fainelli@gmail.com,
	davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] net: dsa: rtl8366rb: standardize init jam tables
Date: Wed, 27 Jan 2021 00:28:05 +0200	[thread overview]
Message-ID: <20210126222805.fd7pzt7zenl72mmo@skbuf> (raw)
In-Reply-To: <CABRCJOSzm6s3hv17KFXMZigJjuBEidLLAM8+dqrGk9xTE=FkcQ@mail.gmail.com>

On Tue, Jan 26, 2021 at 11:15:33PM +0100, Lorenzo Carletti wrote:
> > And did you manage to find out what these tables actually do?
>
> I was unable to do so. I was looking for Intel 8051 instructions in them:
> I created a small piece of code that generates an hypotetical
> registers space in which the tables are then jammed, but I didn't
> find anything.
> It's clear that some of the values of the tables are configuration
> parameters for stuff like the bandwidth, but that's the extent of what
> I was able to understand... So not that much.
>
> > Why? What difference does it make?
>
> So, allow me to explain. The kernel jams every "i + 1" value in the array
> tables into the registers at " i", and then increments "i" by 2.
> These can be seen as [n][2] matrixes, just like the ethernet one.
> Having the arrays converted to matrixes can help visualize which
> value is jammed where, or at least that's how I feel like it is.
> I know it's not a big change...

Got it, thanks. It is better, in fact, once you get over that whole
0xBE00 thing...

> > On which RTL8366RB chip revisions did you test for regressions?
>
> I don't have any of the chips to test this. What I agreed on with
> Linus Walleji was to send the patch after making sure everything
> compiled properly and checkpatch was happy with what I produced.
> Once the patch was sent, he said he'd test it.
> I ran some simulations, but that's pretty much it. I know those
> are not enough, so I'm waiting as well.

It is probably a safe change as it is, if you ran some simulations and
the same values at the same register addresses are jammed before and
after, it should be fine. The code looks okay.

  parent reply	other threads:[~2021-01-27 13:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25  4:56 [PATCH 0/1] net: dsa: rtl8366rb: change type of jam tables Lorenzo Carletti
2021-01-25  4:56 ` [PATCH 1/1] net: dsa: rtl8366rb: standardize init " Lorenzo Carletti
2021-01-26 21:08   ` Vladimir Oltean
2021-01-26 21:21     ` Vladimir Oltean
2021-01-26 21:38     ` Vladimir Oltean
     [not found]       ` <CABRCJOSzm6s3hv17KFXMZigJjuBEidLLAM8+dqrGk9xTE=FkcQ@mail.gmail.com>
2021-01-26 22:28         ` Vladimir Oltean [this message]
2021-01-26 22:37           ` Vladimir Oltean
2021-01-26 21:40     ` Linus Walleij
2021-01-26 21:41   ` Linus Walleij
2021-01-28 16:07   ` Andy Shevchenko

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=20210126222805.fd7pzt7zenl72mmo@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.carletti98@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).