Message ID | Zfxlj3pYUk4ys47T@bart.dudau.co.uk (mailing list archive) |
---|---|
State | Changes Requested |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | net: wwan: t7xx: BUG: Unaligned access when loading mtk_t7xx module | expand |
Context | Check | Description |
---|---|---|
netdev/tree_selection | success | Not a local patch |
Liviu Dudau <liviu@dudau.co.uk> writes: > I had a > go at guessing that UL registers are at 0x8 and 0x48 offsets and DL > registers are at 0x0478 and 0x04b8, but while that fixes the alignment > exception, I now get a "CLDMA{0,1} queue 0 is not empty" message. I don't think you can assume the register offsets are wrong. It looks more like the device doesn't care about alignment. But given that the driver includes <linux/io-64-nonatomic-lo-hi.h>, you can probably replace those unaligned 64bit accesses with two nonatomic 32bit accesses. Bjørn
On Fri, Mar 22, 2024 at 01:00:22PM +0100, Bjørn Mork wrote: > Liviu Dudau <liviu@dudau.co.uk> writes: > > > I had a > > go at guessing that UL registers are at 0x8 and 0x48 offsets and DL > > registers are at 0x0478 and 0x04b8, but while that fixes the alignment > > exception, I now get a "CLDMA{0,1} queue 0 is not empty" message. > > I don't think you can assume the register offsets are wrong. It looks > more like the device doesn't care about alignment. Sorry, I should clarify: the offsets are wrong when you're trying to do a 64bit read over PCIe for a MEM64 area. Accessed addresses are expected to be multiples of 8 bytes. t7xx_cldma_hw_set_start_addr() uses the offset for the low register for calculating the address for the write, which is not 64bit aligned for the UL block. > > But given that the driver includes <linux/io-64-nonatomic-lo-hi.h>, you > can probably replace those unaligned 64bit accesses with two nonatomic > 32bit accesses. > I've tried your suggestion and things seem to progress further, thanks for that! I'm getting some errors on not being able to transition from D3hot to D0, but I guess it might be something to do with the PCIe-to-M.2 adaptor that I'm using. Will continue my investigation into the setup and report back with a patch to replace the register accesses with the lo_hi variants. Best regards, Liviu > > Bjørn
diff --git a/arch/arm64/boot/dts/rockchip/rk3588.dtsi b/arch/arm64/boot/dts/rockchip/rk3588.dtsi index 74e8ed4531f0d..75db20440a590 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588.dtsi @@ -219,7 +219,7 @@ pcie3x4: pcie@fe150000 { power-domains = <&power RK3588_PD_PCIE>; ranges = <0x01000000 0x0 0xf0100000 0x0 0xf0100000 0x0 0x00100000>, <0x02000000 0x0 0xf0200000 0x0 0xf0200000 0x0 0x00e00000>, - <0x03000000 0x0 0x40000000 0x9 0x00000000 0x0 0x40000000>; + <0x03000000 0x0 0x40000000 0x9 0x00000000 0x0 0x3fff0000>; reg = <0xa 0x40000000 0x0 0x00400000>, <0x0 0xfe150000 0x0 0x00010000>, <0x0 0xf0000000 0x0 0x00100000>;