Hi I'm making another attempt at fixing the qla1280.c driver for ISP1040x on Alpha, while trying not to break anything on other platforms, like IP-30/MIPS. This time I'm using dma_get_required_mask(). Is my understanding that this function should provide the minimum required mask for the platform, assuming this works it should return something greater than 32-bits on IP-30/MIPS. From what I can tell by looking at the kernel source it should return something like a 64-bit MASK for the sgi/octane but I'm not in the possession of such a system so I'm unable to verify this. Maybe Thomas can test the new patch? When I examine other scsi drivers it seems like most of them select bitmasks that are 32-bit on alpha systems. Any bitmask below 40-bits will avoid hitting the "monster window" which is when I see trouble on alpha. Still a much larger mask is required on SGI/Octane, my hopes are that dma_get_required_mask() can assist in sorting this out? Magnus On Mon, Nov 4, 2024 at 8:41 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Thu, Oct 31, 2024 at 05:30:31PM +0000, Maciej W. Rozycki wrote: > > This also means that the ISP_CFG0_1040A check also added in 2.6.9 with > > <https://lore.kernel.org/r/20040606125825.GE31063@xxxxxx/> will never > > match, possibly meaning that this code wasn't actually ever verified with > > affected 1040A hardware. This might also explain why a later change made > > with commit 0888f4c33128 ("[SCSI] qla1280: don't use bitfields for > > hardware access in isp_config") went unnoticed that changed the semantics > > of the workaround from keeping bursts unconditionally disabled with the > > 1040A to making them enabled in the absence of NVRAM. > > > > NB comments for the FIFO threshold surely are suspicious too. > > > > Christoph can you please have a look into it? It seems like something > > you ought to be quite familiar with if not for the passage of time. > > Somewhat surprisingly I don't remember that details of a drive by > cleanup 20 years ago :) > > So whatever fixes you have based on other implementations are probably > correct. >
