What's the expected path to recover from a PHY_HALTED transition?

hi, I'm debugging an issue on the Broadcom parts (using unimac-mdio.c as the mdio bus) where i occasionally see MDIO bus read failures, which causes phy.c to transition the PHY to PHY_HALTED. It stays in this state until the link is bounced. So, what's the expectation to handle this and recover

Re: What's the expected path to recover from a PHY_HALTED transition?

On 16 November 2015 at 11:48, Florian Fainelli <f.faine...@gmail.com> wrote: > On 16/11/15 11:29, Adrian Chadd wrote: >> hi, >> >> I'm debugging an issue on the Broadcom parts (using unimac-mdio.c as >> the mdio bus) where i occasionally see MDIO bus rea

Re: [PATCH 1/3] ath10k: remove ath10k_vif_to_arvif()

hiya, Removing this method makes the diff to FreeBSD larger, as "vif" in FreeBSD is a different pointer. (Yes, I have ath10k on freebsd working and I'd like to find a way to reduce the diff moving forward.) -adrian

Re: [PATCH 1/3] ath10k: remove ath10k_vif_to_arvif()

On 9 February 2017 at 23:37, Joe Perches <j...@perches.com> wrote: > On Thu, 2017-02-09 at 23:14 -0800, Adrian Chadd wrote: > >> If there >> were accessors for the skb data / len fields (like we do for mbufs) >> then porting the code would've involved about 5,000 l

Re: [PATCH 1/3] ath10k: remove ath10k_vif_to_arvif()

On 9 February 2017 at 23:03, Valo, Kalle <kv...@qca.qualcomm.com> wrote: > Ben Greear <gree...@candelatech.com> writes: > >> On 02/07/2017 01:14 AM, Valo, Kalle wrote: >>> Adrian Chadd <adr...@freebsd.org> writes: >>> >>>> Re

Re: [PATCH] ath10k: transmit queued frames after waking queues

On Thu, 17 May 2018 at 16:16, Niklas Cassel wrote: > diff --git a/drivers/net/wireless/ath/ath10k/txrx.c b/drivers/net/wireless/ath/ath10k/txrx.c > index cda164f6e9f6..1d3b2d2c3fee 100644 > --- a/drivers/net/wireless/ath/ath10k/txrx.c > +++