linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Ladislav Michl <oss-lists@triops.cz>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>
Subject: Re: [PATCH 00/11] Cleanup Octeon DWC3 glue code
Date: Fri, 30 Jun 2023 21:45:42 +0000	[thread overview]
Message-ID: <20230630214540.bkimnyfpyduqtfak@synopsys.com> (raw)
In-Reply-To: <ZJ6xK7SJ7PwLril7@lenoch>

Hi,

On Fri, Jun 30, 2023, Ladislav Michl wrote:
> Hi,
> 
> On Mon, Jun 26, 2023 at 11:17:57PM +0000, Thinh Nguyen wrote:
> > Hi,
> [snip]
> > For each patch, please include all the emails returned from
> > get_maintainer.pl including Greg's and Thomas's.
> 
> I already explained why is Cc list constructed the way it is. Despite
> formal rules, time is a scarce resource, so let's not draw people's

Now that doesn't sound fair that you think my resource is more
expendable. :)

> attention too early. Anyway, if you think there's something that
> needs someone's special attention, you can still extend Cc list
> yourself.

I'm just asking you to follow the submitting patch process and add the
appropriate maintainers on any code that they maintain. You just ignored
the get_maintainer.pl output and only added what you feel needed.

> 
> Before sending v2, maintainer's review or ack is needed. I already
> collected Thomas' ack for a move, but have not read a single world
> from you. Do you plan to do some actual review, so we can take next
> step or are you willing to wait for a v2 which will add only

Please be patient, I'll get to your changes when I can, and I'm not the
only reviewer here. Your series isn't exactly small or easy to
understand for me to review quickly.

> octeon_get_io_clock_rate stub for non Octeon builds (having clk api
> would be nice here, but that's different story)?
> 
> Also, perhaps it would be reasonable to squash patches 8 and 9.
> Which tree to you want it to be rebased against? Currently I'm at
> linux.git master and changes were retested here.
> 
> I'd prefer to send fewer version if possible, so actual comments
> on code would certainly help.

Well, you can help me and other reviewers by submitting v2 with your
rebased changes. I think it's appropriate here given that this series
touches on 2 separate subsystems.

> 
> [snip]
> > > Also coleagues of mine meanwhile found that PLL indeed ocassionally
> > > fails to lock, so workaround attached to cover letter is really needed.
> > > Naturally it cannot sneak in as it is, so unless you have better idea
> > > I'll just port it to recent driver state and we can start discussion
> > > from there in a separate thread.
> > 
> > If this causes a regression, then please fix it before sending it in. If
> > it's a new found issue, you can create a fix patch at a later point.
> 
> There are few problems with Octeon's DWC3 implementation and none of them
> can be really solved without documentation. Here I come in trouble as
> Sysnopsys tech support pointed to SoC manufacturer which no longer exists.
> Cavium was bought by Marvell, dumped almost all the staff and those
> still providing technical support were unable to find any revelant
> documentation in past few months.

This can be problematic...

> 
> So unless that changes I can send only hackish patches which kinda
> overcome issues found, but I do not think it is viable solution. That's
> something I'll do at later point as you suggested and we'll see if an
> acceptable solution pops up.
> 

If it's hackish because of the lacking of documentation, then just note
how you came to the solution in your patch is totally fine. There's
nothing else we can do in that case.

I notice that there are many magic numbers in your changes. I hope you
have documentations for them. I may need to make some assumption/skip
reviewing some areas because of that.

Thanks,
Thinh

      reply	other threads:[~2023-06-30 21:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-19 20:09 [PATCH 00/11] Cleanup Octeon DWC3 glue code Ladislav Michl
2023-06-19 20:11 ` [PATCH 01/11] MIPS: OCTEON: octeon-usb: add all register offsets Ladislav Michl
2023-06-19 20:11 ` [PATCH 02/11] MIPS: OCTEON: octeon-usb: use bitfields for control register Ladislav Michl
2023-06-19 20:12 ` [PATCH 03/11] MIPS: OCTEON: octeon-usb: use bitfields for host config register Ladislav Michl
2023-06-19 20:12 ` [PATCH 04/11] MIPS: OCTEON: octeon-usb: use bitfields for shim register Ladislav Michl
2023-06-19 20:13 ` [PATCH 05/11] MIPS: OCTEON: octeon-usb: move gpio config to separate function Ladislav Michl
2023-06-19 20:13 ` [PATCH 06/11] MIPS: OCTEON: octeon-usb: introduce dwc3_octeon_{read,write}q Ladislav Michl
2023-06-19 20:14 ` [PATCH 07/11] MIPS: OCTEON: octeon-usb: cleanup divider calculation Ladislav Michl
2023-06-19 20:14 ` [PATCH 08/11] usb: dwc3: Move Octeon glue code from arch/mips Ladislav Michl
2023-06-23 13:15   ` Thomas Bogendoerfer
2023-06-30 22:32   ` Thinh Nguyen
2023-06-19 20:15 ` [PATCH 09/11] usb: dwc3: dwc3-octeon: Convert to glue driver Ladislav Michl
2023-06-30 23:25   ` Thinh Nguyen
2023-06-19 20:15 ` [PATCH 10/11] usb: dwc3: dwc3-octeon: Move node parsing into driver probe Ladislav Michl
2023-06-30 23:27   ` Thinh Nguyen
2023-07-02  0:13     ` Ladislav Michl
2023-07-05 22:55       ` Thinh Nguyen
2023-07-01  5:49   ` kernel test robot
2023-06-19 20:16 ` [PATCH 11/11] usb: dwc3: Add SPDX header and copyright Ladislav Michl
2023-06-22 23:01 ` [PATCH 00/11] Cleanup Octeon DWC3 glue code Thinh Nguyen
2023-06-23  7:57   ` Ladislav Michl
2023-06-23 13:14     ` Thomas Bogendoerfer
2023-06-23 23:24     ` Thinh Nguyen
2023-06-24 13:04       ` Ladislav Michl
2023-06-26 23:17         ` Thinh Nguyen
2023-06-30 10:40           ` Ladislav Michl
2023-06-30 21:45             ` Thinh Nguyen [this message]

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=20230630214540.bkimnyfpyduqtfak@synopsys.com \
    --to=thinh.nguyen@synopsys.com \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oss-lists@triops.cz \
    /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).