Hi Hauke,
Le 02/21/12 00:38, Hauke Mehrtens a écrit :
When using the bcm5354 with a recent firmware>= 478.104 it runs into a
memory very shortly after doing an active scan or any thing else where
packages are send. This was cased by a gpio misconfiguration, the
firmware triggered the GPIO pins u
Hi Hauke,
On Tuesday 05 June 2012 23:55:02 Hauke Mehrtens wrote:
> This workaround should be triggered based on the chipid and rev and not
> the core id and rev. This is based on code in the Broadcom SDK.
>
> Signed-off-by: Hauke Mehrtens
> ---
> drivers/bcma/driver_chipcommon_pmu.c |3 ++-
Hi Hauke,
On Tuesday 05 June 2012 23:55:05 Hauke Mehrtens wrote:
> The SoCs do not need any special handling in bcma_pmu_pll_init(),
> bcma_pmu_resources_init(), bcma_pmu_swreg_init() and
> bcma_pmu_workarounds. This patches suppresses some warnings in the log.
This does not look like it scales v
2014-07-31 12:59 GMT-07:00 Rafał Miłecki :
> Access to PHY and radio registers is indirect on Broadcom hardware and
> it seems that addressing on MIPS SoCs may require flushing. Broadcom
> code does that unconditionally on MIPS, so let's do the same to make
> sure hardware won't miss anything impor
2014-07-31 13:23 GMT-07:00 Hauke Mehrtens :
> On 07/31/2014 09:59 PM, Rafał Miłecki wrote:
>> Access to PHY and radio registers is indirect on Broadcom hardware and
>> it seems that addressing on MIPS SoCs may require flushing. Broadcom
>> code does that unconditionally on MIPS, so let's do the sam
2014-07-31 13:34 GMT-07:00 Rafał Miłecki :
> On 31 July 2014 22:25, Florian Fainelli wrote:
>>> +static inline void b43_write16f(struct b43_wldev *dev, u16 offset, u16
>>> value)
>>> +{
>>> + b43_write16(dev, offset, value);
>>> +#if d
On 02/04/2018 10:58 AM, Chris Vine wrote:
> I probably should have copied this to the relevant kernel wireless
> mailing lists. Anyway, here it is.
>
> As a further datum point, the b43 driver works fine with the 4.15.0-rc3
> kernel. So something seems to have changed between that and 4.15.0.
D
