Re: [PATCH v2 00/29] y2038: add time64 syscalls
On Fri, 2019-01-18 at 11:57 -0500, Dennis Clarke wrote: > On 1/18/19 11:18 AM, Arnd Bergmann wrote: > > This is a minor update of the patches I posted last week, I > > would like to add this into linux-next now, but would still do > > changes if there are concerns about the contents. The first > > version did not see a lot of replies, which could mean that > > either everyone is happy with it, or that it was largely ignored. > > > > See also the article at https://lwn.net/Articles/776435/. > > I would be happy to read "Approaching the kernel year-2038 end game" > however it is behind a pay wall. Perhaps it may be best to just > host interesting articles about open source idea elsewhere. Hey, this is an unfair characterization: lwn.net operates an early access subscription model, so you can't read the above for 14 days after publication without paying for an lwn.net subscription, but by the time these patches are upstream there will be no paywall because it will expire on 24 January and that URL will then be readable by all. That makes LWN.net a nice, reliable resource for us while still supporting some business model to keep it going. James
Re: [PATCH 22/22] parisc: use generic dma_noncoherent_ops
On Sat, 2018-04-21 at 19:43 +0200, Helge Deller wrote: > On 20.04.2018 10:03, Christoph Hellwig wrote: > > Switch to the generic noncoherent direct mapping implementation. > > > > Parisc previously had two different non-coherent dma ops > > implementation that just different in the way coherent allocations > > were handled or not handled. The different behavior is not > > selected at runtime in the arch_dma_alloc and arch_dma_free > > routines. The non-coherent allocation in the pcx cases now uses > > the dma_direct helpers that are a little more sophisticated and > > used by a lot of other architectures. > > > > Fix sync_single_for_cpu to do skip the cache flush unless the > > transfer is to the device to match the more tested unmap_single > > path which should have the same cache coherency implications. > > > > This also now consistenly uses flush_kernel_dcache_range for cache > > flushing while previously some of the SG based operations used > > flush_kernel_vmap_range instead. > > > This patch breaks a 32bit kernel on a B160L machine (PA7300LC CPU, > "pcxl2"). After applying this patch series the lasi82956 network > driver works unreliable. NIC gets IP, but ping doesn't work. > See drivers/net/ethernet/i825xx/lasi_82596.c, it uses dma*sync() > functions. That's actually a weird result. The 32 bit machines have two cases: those that can make uncached memory by setting the U bit (and thus don't need the sync operations in the lasi and D700 drivers) and those that can't. The latter is basically only the old 700 series. The B180 is in the class of can set pages to uncached, so it sounds like something in our uncached memory allocation for dma areas is failing after this patch set. I still have an old 700 in my box of curiosities, so I can try to dust it off and plug it back in when I get home to see what it makes of the series when it gets fixed. James James -- To unsubscribe from this list: send the line "unsubscribe linux-alpha" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 22/22] parisc: use generic dma_noncoherent_ops
On Fri, 2018-04-20 at 10:03 +0200, Christoph Hellwig wrote: > diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c > index 8d3a7b80ac42..4e87c35c22b7 100644 > --- a/arch/parisc/kernel/setup.c > +++ b/arch/parisc/kernel/setup.c > @@ -97,14 +97,12 @@ void __init dma_ops_init(void) > panic( "PA-RISC Linux currently only supports > machines that conform to\n" > "the PA-RISC 1.1 or 2.0 architecture > specification.\n"); > > - case pcxs: > - case pcxt: > - hppa_dma_ops = _dma_ops; > - break; > case pcxl2: > pa7300lc_init(); > case pcxl: /* falls through */ > - hppa_dma_ops = _dma_ops; > + case pcxs: > + case pcxt: > + hppa_dma_ops = _noncoherent_ops; > break; > default: > break; Well, this is wrong: you just made every 32 bit parisc system unnecessarily use non-coherent. We actually only have a small small set of non-coherent systems. The pxcs and pcxt systems (which are about 99% of the user base) can use coherent dma ops. The problem seems to be in your new world you only have one dma_noncoherent_ops pointer ... we definitely need two on parisc, so whether arch_dma_cache_sync is present or not needs to be dynamic not config defined. James -- To unsubscribe from this list: send the line "unsubscribe linux-alpha" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
