From: Tobias Waldekranz <tobias@waldekranz•com>
To: Andrew Lunn <andrew@lunn•ch>
Cc: davem@davemloft•net, kuba@kernel•org, f.fainelli@gmail•com,
olteanv@gmail•com, netdev@vger•kernel.org, linux@armlinux•org.uk,
chris.packham@alliedtelesis•co.nz
Subject: Re: [PATCH net 2/4] net: dsa: mv88e6xxx: Give chips more time to activate their PPUs
Date: Sun, 08 Dec 2024 22:23:53 +0100 [thread overview]
Message-ID: <87ikrt98d2.fsf@waldekranz.com> (raw)
In-Reply-To: <9ba73b5b-1b76-48b2-9b37-fd8246ef577a@lunn.ch>
On lör, dec 07, 2024 at 16:38, Andrew Lunn <andrew@lunn•ch> wrote:
> On Fri, Dec 06, 2024 at 02:39:25PM +0100, Tobias Waldekranz wrote:
>> On fre, dec 06, 2024 at 14:18, Andrew Lunn <andrew@lunn•ch> wrote:
>> > On Fri, Dec 06, 2024 at 02:07:34PM +0100, Tobias Waldekranz wrote:
>> >> In a daisy-chain of three 6393X devices, delays of up to 750ms are
>> >> sometimes observed before completion of PPU initialization (Global 1,
>> >> register 0, bit 15) is signaled. Therefore, allow chips more time
>> >> before giving up.
>> >> static int mv88e6352_g1_wait_ppu_polling(struct mv88e6xxx_chip *chip)
>> >> {
>> >> int bit = __bf_shf(MV88E6352_G1_STS_PPU_STATE);
>> >> + int err, i;
>> >>
>> >> - return mv88e6xxx_g1_wait_bit(chip, MV88E6XXX_G1_STS, bit, 1);
>> >> + for (i = 0; i < 20; i++) {
>> >> + err = _mv88e6xxx_wait_bit(chip, chip->info->global1_addr,
>> >> + MV88E6XXX_G1_STS, bit, 1, NULL);
>> >> + if (err != -ETIMEDOUT)
>> >> + break;
>> >> + }
>> >
>> > The commit message does not indicate why it is necessary to swap to
>> > _mv88e6xxx_wait_bit().
>>
>> It is not strictly necessary, I just wanted to avoid flooding the logs
>> with spurious timeout errors. Do you want me to update the message?
>
> Ah, the previous patch.
>
> I wounder if the simpler fix is just to increase the timeout? I don't
It would certainly be simpler. To me, it just felt a bit dangerous to
have a static 1s timeout buried that deep in the stack.
> think we have any code specifically wanting a timeout, so changing the
> timeout should have no real effect.
I imagine some teardown scenario, in which we typically ignore return
values. In that case, if we're trying to remove lots of objects from
hardware that require waiting on busy bits (ATU/VTU), we could end up
blocking for minutes rather than seconds.
But it is definitely more of a gut feeling - I don't have a concrete
example.
next prev parent reply other threads:[~2024-12-08 21:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 13:07 [PATCH net 0/4] net: dsa: mv88e6xxx: Amethyst (6393X) fixes Tobias Waldekranz
2024-12-06 13:07 ` [PATCH net 1/4] net: dsa: mv88e6xxx: Improve I/O related error logging Tobias Waldekranz
2024-12-06 13:07 ` [PATCH net 2/4] net: dsa: mv88e6xxx: Give chips more time to activate their PPUs Tobias Waldekranz
2024-12-06 13:18 ` Andrew Lunn
2024-12-06 13:39 ` Tobias Waldekranz
2024-12-07 15:38 ` Andrew Lunn
2024-12-08 21:23 ` Tobias Waldekranz [this message]
2024-12-15 23:12 ` Tobias Waldekranz
2024-12-16 9:22 ` Andrew Lunn
2024-12-10 12:10 ` Paolo Abeni
2024-12-10 14:07 ` Tobias Waldekranz
2024-12-06 13:07 ` [PATCH net 3/4] net: dsa: mv88e6xxx: Never force link on in-band managed MACs Tobias Waldekranz
2024-12-06 13:07 ` [PATCH net 4/4] net: dsa: mv88e6xxx: Limit rsvd2cpu policy to user ports on 6393X Tobias Waldekranz
2024-12-08 20:23 ` [PATCH net 0/4] net: dsa: mv88e6xxx: Amethyst (6393X) fixes Chris Packham
2024-12-08 21:32 ` Tobias Waldekranz
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=87ikrt98d2.fsf@waldekranz.com \
--to=tobias@waldekranz$(echo .)com \
--cc=andrew@lunn$(echo .)ch \
--cc=chris.packham@alliedtelesis$(echo .)co.nz \
--cc=davem@davemloft$(echo .)net \
--cc=f.fainelli@gmail$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=linux@armlinux$(echo .)org.uk \
--cc=netdev@vger$(echo .)kernel.org \
--cc=olteanv@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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