Re: [PATCH] ksz884x: switch from 'pci_' to 'dma_' API

From: Christophe JAILLET Date: Tue, 14 Jul 2020 20:35:01 +0200 > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. > >

Re: [PATCH net-next] ksz884x: mark pcidev_suspend() as __maybe_unused

From: Wei Yongjun Date: Thu, 2 Jul 2020 17:18:10 +0800 > In certain configurations without power management support, gcc report > the following warning: > > drivers/net/ethernet/micrel/ksz884x.c:7182:12: warning: > 'pcidev_suspend' defined but not used [-Wunused-function] > 7182 | static int

Re: [PATCH v2 0/6] seqlock: seqcount_t call sites bugfixes

From: "Ahmed S. Darwish" Date: Wed, 3 Jun 2020 16:49:43 +0200 > Since patch #7 and #8 from the series: > >[PATCH v1 00/25] seqlock: Extend seqcount API with associated locks > > https://lore.kernel.org/lkml/20200519214547.352050-1-a.darw...@linutronix.de > > are now pending on the

Re: [PATCH 07/11] sparc64: constify sysrq_key_op

From: Emil Velikov Date: Wed, 13 May 2020 22:43:47 +0100 > With earlier commits, the API no longer discards the const-ness of the > sysrq_key_op. As such we can add the notation. > > Cc: Greg Kroah-Hartman > Cc: Jiri Slaby > Cc: linux-ker...@vger.kernel.org > Cc: "David S. Miller" > Cc:

Re: [PATCH net-next] net: bnxt: Remove Comparison to bool in bnxt_ethtool.c

From: Jason Yan Date: Tue, 5 May 2020 15:46:08 +0800 > Fix the following coccicheck warning: > > drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:1991:5-46: WARNING: > Comparison to bool > drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:1993:10-54: WARNING: > Comparison to bool >

Re: [PATCH net-next] dpaa2-eth: fix error return code in setup_dpni()

From: Wei Yongjun Date: Mon, 27 Apr 2020 10:43:22 + > Fix to return negative error code -ENOMEM from the error handling > case instead of 0, as done elsewhere in this function. > > Signed-off-by: Wei Yongjun Applied, thanks. ___ dri-devel

Re: [PATCH net-next] net: lpc-enet: fix error return code in lpc_mii_init()

From: Wei Yongjun Date: Mon, 27 Apr 2020 12:15:07 + > Fix to return a negative error code from the error handling > case instead of 0, as done elsewhere in this function. > > Fixes: b7370112f519 ("lpc32xx: Added ethernet driver") > Signed-off-by: Wei Yongjun Applied.

Re: [PATCH 00/12] treewide: Fix GENMASK misuses

From: Joe Perches Date: Tue, 9 Jul 2019 22:04:13 -0700 > These GENMASK uses are inverted argument order and the > actual masks produced are incorrect. Fix them. > > Add checkpatch tests to help avoid more misuses too. Patches #7 and #8 applied to 'net', with appropriate Fixes tags added to

Re: [PATCH v7 0/6] Add support for Orange Pi 3

From: Ondřej Jirman Date: Mon, 24 Jun 2019 19:46:37 +0200 > This series was even longer before, with patches all around for various > maintainers. I'd expect that relevant maintainers pick the range of patches > meant for them. I don't know who's exactly responsible for what, but I think, > this

Re: [PATCH v7 0/6] Add support for Orange Pi 3

From: meg...@megous.com Date: Thu, 20 Jun 2019 15:47:42 +0200 > From: Ondrej Jirman > > This series implements support for Xunlong Orange Pi 3 board. > > - ethernet support (patches 1-3) > - HDMI support (patches 4-6) > > For some people, ethernet doesn't work after reboot (but works on cold

Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h

From: Christoph Hellwig Date: Mon, 10 Dec 2018 20:22:28 +0100 > On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote: >> From: Christoph Hellwig >> Date: Mon, 10 Dec 2018 17:32:56 +0100 >> >> > Dave, can you pick the series up through the sparc tree? I co

Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h

From: Christoph Hellwig Date: Mon, 10 Dec 2018 17:32:56 +0100 > Dave, can you pick the series up through the sparc tree? I could also > merge it through the dma-mapping tree, but given that there is no > dependency on it the sparc tree seem like the better fit. I thought that some of this is a

Re: [PATCH 06/10] sparc64/iommu: implement DMA_ATTR_NON_CONSISTENT

From: Christoph Hellwig Date: Sat, 8 Dec 2018 09:36:58 -0800 > Just allocate the memory and use map_page to map the memory. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller ___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: [PATCH 08/10] sparc64/pci_sun4v: implement DMA_ATTR_NON_CONSISTENT

From: Christoph Hellwig Date: Sat, 8 Dec 2018 09:37:00 -0800 > Just allocate the memory and use map_page to map the memory. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller ___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: [PATCH 05/10] sparc64/iommu: move code around a bit

From: Christoph Hellwig Date: Sat, 8 Dec 2018 09:36:57 -0800 > Move the alloc / free routines down the file so that we can easily use > the map / unmap helpers to implement non-consistent allocations. > > Also drop the _coherent postfix to match the method name. > > Signed-off-by: Christoph

Re: [PATCH 07/10] sparc64/pci_sun4v: move code around a bit

From: Christoph Hellwig Date: Sat, 8 Dec 2018 09:36:59 -0800 > Move the alloc / free routines down the file so that we can easily use > the map / unmap helpers to implement non-consistent allocations. > > Also drop the _coherent postfix to match the method name. > > Signed-off-by: Christoph

Re: [PATCH 5/6] sparc: move the leon PCI memory space comment to

From: Christoph Hellwig Date: Sat, 8 Dec 2018 09:41:14 -0800 > It has nothing to do with the content of the pci.h header. > > Suggested by: Sam Ravnborg > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller ___ dri-devel mailing list

Re: [PATCH 4/6] sparc: remove not required includes from dma-mapping.h

From: Christoph Hellwig Date: Sat, 8 Dec 2018 09:41:13 -0800 > The only thing we need to explicitly pull in is the defines for the > CPU type. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller ___ dri-devel mailing list

Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h

From: Christoph Hellwig Date: Sat, 8 Dec 2018 09:41:15 -0800 > There are enough common defintions that a single header seems nicer. > > Also drop the pointless include. > > Signed-off-by: Christoph Hellwig > Acked-by: Sam Ravnborg Acked-by: David S. Miller

Re: [PATCH 3/6] sparc: remove the sparc32_dma_ops indirection

From: Christoph Hellwig Date: Sat, 8 Dec 2018 09:41:12 -0800 > There is no good reason to have a double indirection for the sparc32 > dma ops, so remove the sparc32_dma_ops and define separate dma_map_ops > instance for the different IOMMU types. > > Signed-off-by: Christoph Hellwig

Re: [PATCH 1/6] sparc: remove no needed sbus_dma_ops methods

From: Christoph Hellwig Date: Sat, 8 Dec 2018 09:41:10 -0800 > No need to BUG_ON() on the cache maintainance ops - they are no-ops > by default, and there is nothing in the DMA API contract that prohibits > calling them on sbus devices (even if such drivers are unlikely to > ever appear). > >

Re: [PATCH 2/6] sparc: factor the dma coherent mapping into helper

From: Christoph Hellwig Date: Sat, 8 Dec 2018 09:41:11 -0800 > Factor the code to remap memory returned from the DMA coherent allocator > into two helpers that can be shared by the IOMMU and direct mapping code. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

From: Jarkko Sakkinen Date: Fri, 30 Nov 2018 13:42:33 -0800 > Can you tell how the CoC should be interpreted then? Regardless of what I think, as others have showen the CoC explicitly does not apply to existing code. ___ dri-devel mailing list

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

From: Jarkko Sakkinen Date: Fri, 30 Nov 2018 13:44:05 -0800 > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote: >> No because use of what some people consider to be bad language isn't >> necessarily abusive, offensive or degrading. Our most heavily censored >> medium is TV and

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

From: Jens Axboe Date: Fri, 30 Nov 2018 13:12:26 -0700 > On 11/30/18 12:56 PM, Davidlohr Bueso wrote: >> On Fri, 30 Nov 2018, Kees Cook wrote: >> >>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen >>> wrote: In order to comply with the CoC, replace with a hug. >> >> I hope

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

From: Abuse Date: Fri, 30 Nov 2018 20:39:01 + > I assume I will now be barred. Perhaps, but not because you said fuck. It would be because you're intentionally creating a disturbance on the list and making it more difficult for developers to get their work done and intentionally creating a

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

From: Davidlohr Bueso Date: Fri, 30 Nov 2018 11:56:52 -0800 > I hope this is some kind of joke. Whether or not it is a joke, it is censorship. And because of that I have no intention to apply any patches like this to any code I am in charge of. ___

Re: [PATCH] mach64: detect the dot clock divider correctly on sparc

From: Ville Syrjälä Date: Fri, 24 Aug 2018 14:58:52 +0300 > But yeah, given the V2CLK thing /5 seems like a perfectly good > value to use here. Patch applied. ___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: [PATCH] mach64: detect the dot clock divider correctly on sparc

From: Mikulas Patocka Date: Fri, 17 Aug 2018 15:19:37 -0400 (EDT) > On Sun Ultra 5, it happens that the dot clock is not set up properly for > some videomodes. For example, if we set the videomode "r1024x768x60" in > the firmware, Linux would incorrectly set a videomode with refresh rate > 180Hz

Re: [PATCH v2 0/2] PCI: Sparc 64-bit resource fixups

From: Bjorn Helgaas Date: Tue, 20 Mar 2018 15:14:01 -0500 > These are from an old series from Yinghai [1] that fix some issues on > sparc64. The v1 posting is at [2]. > > [1] https://lkml.kernel.org/r/20170421050500.13957-1-ying...@kernel.org > [2] >

Re: [PATCH v1 0/2] PCI: Sparc 64-bit resource fixups

From: Bjorn Helgaas Date: Mon, 19 Mar 2018 14:38:54 -0500 > I'd be happy to remove both. But I wonder how X init works on > sparc. It's been many years since I worked on this, but I think it mapped and used the PCI ROM resource for this.

Re: [PATCH] video: fbdev: remove dead igafb driver

From: John Paul Adrian Glaubitz Date: Wed, 18 Oct 2017 15:14:27 +0200 > Hi Bartlomiej! > > On 10/18/2017 02:56 PM, Bartlomiej Zolnierkiewicz wrote: >> igafb driver hasn't compiled since at least kernel v2.6.34 as >> commit 6016a363f6b5 ("of: unify phandle name in

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

From: Allen Pais Date: Wed, 13 Sep 2017 13:02:15 +0530 > Signed-off-by: Allen Pais This is quite pointless as the caller doesn't do anything with the value, it just tests whether a negative value is returned or not.

Re: [PATCH 20/44] sparc: implement ->mapping_error

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:45 +0200 > DMA_ERROR_CODE is going to go away, so don't rely on it. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller ___ dri-devel

Re: [PATCH 28/44] sparc: remove arch specific dma_supported implementations

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:53 +0200 > Usually dma_supported decisions are done by the dma_map_ops instance. > Switch sparc to that model by providing a ->dma_supported instance for > sbus that always returns false, and implementations tailored to the sun4u

Re: [PATCH 27/44] sparc: remove leon_dma_ops

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:52 +0200 > We can just use pci32_dma_ops. > > Btw, given that leon is 32-bit and appears to be PCI based, do even need > the special case for it in get_arch_dma_ops at all? I would need to defer to the LEON developers on that,

Re: [PATCH 02/44] ibmveth: properly unwind on init errors

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:27 +0200 > That way the driver doesn't have to rely on DMA_ERROR_CODE, which > is not a public API and going away. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller

Re: clean up and modularize arch dma_mapping interface

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:25 +0200 > for a while we have a generic implementation of the dma mapping routines > that call into per-arch or per-device operations. But right now there > still are various bits in the interfaces where don't clearly operate >

Re: [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

From: Jani Nikula Date: Wed, 31 May 2017 18:50:43 +0300 > From: Chris Wilson > > An error during suspend (e100e_pm_suspend), ... > lead to complete failure: ... > The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM >

Re: [PULL] topic/e1000e-fix

From: Daniel Vetter <daniel.vet...@ffwll.ch> Date: Wed, 31 May 2017 08:10:45 +0200 > On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote: >> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie <airl...@gmail.com> wrote: >>> On 31

Re: [PULL] topic/e1000e-fix

From: Daniel Vetter Date: Tue, 30 May 2017 22:15:42 +0200 > If the e1000e maintainer wants to coalesce or not return statements > this simple way, that's imo on him to change the color as needed. That's not how things work. If the maintainer wants you to style things a

[PATCH] uapi: use wildcards to list files

From: Nicolas Dichtel Date: Tue, 3 Jan 2017 15:35:44 +0100 > Regularly, when a new header is created in include/uapi/, the developer > forgets to add it in the corresponding Kbuild file. This error is usually > detected after the release is out. > > In fact, all

[PATCH v2 09/11] net: skfb: remove obsolete -I cflag

From: Arnd Bergmann Date: Wed, 15 Jun 2016 17:45:51 +0200 > The skfp driver has been moved to drivers/net/fddi/skfp a long time > ago, but we still attempt to include headers from the old location, > which causes a warning when building with W=1: > > cc1: error:

[PATCH net-next v3 0/4] uapi: consolidate DIV_ROUND_UP definition

From: Nicolas Dichtel Date: Fri, 4 Mar 2016 11:52:15 +0100 > The inital goal was to consolidate ethtool.h uapi header. But I took the > opportunity to remove all duplicate definitions of DIV_ROUND_UP. > > v3: add patch #2 and #3 > > v2: split the patch > define

[PATCH] tree wide: Use kvfree() than conditional kfree()/vfree()

From: Jan Kara Date: Mon, 9 Nov 2015 13:11:26 +0100 > You can add > > Acked-by: Jan Kara > > for the UDF and fs/xattr.c parts. Please do not quote and entire large patch just to give an ACK. Just quote the minimum necessary context, which is usually just the commit message.

[PATCH] treewide: Fix typo compatability -> compatibility

From: Laurent Pinchart Date: Wed, 27 May 2015 15:05:42 +0300 > Even though 'compatability' has a dedicated entry in the Wiktionary, > it's listed as 'Mispelling of compatibility'. Fix it. > > Signed-off-by: Laurent Pinchart Acked-by: David S. Miller

[PATCH] radeon: Do not directly dereference pointers to BIOS area.

From: Christian König <christian.koe...@amd.com> Date: Fri, 20 Mar 2015 10:38:32 +0100 > On 19.03.2015 17:29, David Miller wrote: >> From: Christian König >> Date: Thu, 19 Mar 2015 09:50:58 +0100 >> >>> In general I would say yes, but for this particular

[PATCH] radeon: Do not directly dereference pointers to BIOS area.

From: Christian König Date: Thu, 19 Mar 2015 09:50:58 +0100 > In general I would say yes, but for this particular hardware it's a > bit questionable to do so. > > For radeon hardware to work correctly the CPU access to the PCIE BARs > should work even without using

[PATCH] radeon: Do not directly dereference pointers to BIOS area.

Use readb() and memcpy_fromio() accessors instead. Signed-off-by: David S. Miller diff --git a/drivers/gpu/drm/radeon/radeon_bios.c b/drivers/gpu/drm/radeon/radeon_bios.c index 63ccb8f..d27e4cc 100644 --- a/drivers/gpu/drm/radeon/radeon_bios.c +++ b/drivers/gpu/drm/radeon/radeon_bios.c @@

PCI Radeon RV100 detection hang on sparc64

From: David Miller <da...@davemloft.net> Date: Fri, 04 Apr 2014 16:52:02 -0400 (EDT) > I'll try to follow up with a patch some time next week. And next week became 4 months later, sorry :-/ Meelis, I've coded up a patch series that should take care of this issue, which I'll post to s

[PATCH 0/25] Replace DEFINE_PCI_DEVICE_TABLE macro use

From: Benoit Taine Date: Fri, 18 Jul 2014 17:26:47 +0200 > We should prefer `const struct pci_device_id` over > `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. > This issue was reported by checkpatch. > > A simplified version of the semantic patch that

[PATCH 00/22] Add and use pci_zalloc_consistent

From: Joe Perches Date: Mon, 23 Jun 2014 06:41:28 -0700 > Adding the helper reduces object code size as well as overall > source size line count. > > It's also consistent with all the various zalloc mechanisms > in the kernel. > > Done with a simple cocci script and some

PCI Radeon RV100 detection hang on sparc64

From: Meelis Roos Date: Tue, 1 Oct 2013 11:43:20 +0300 (EEST) >> > > That looks quite strange. I guess the kernel should map the ROM at the >> > > address OpenBoot/OF assigned to it. ( 1002 ). >> > >> > The address you see is a raw physical I/O address, which is a

Re: [PATCH] only try to find radeon IGP ROM on X86

From: Meelis Roos mr...@linux.ee Date: Thu, 10 Oct 2013 18:26:39 +0300 (EEST) On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos mr...@linux.ee wrote: To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon

Re: PCI Radeon RV100 detection hang on sparc64

From: mr...@linux.ee Date: Tue, 24 Sep 2013 00:14:41 +0300 (EEST) That looks quite strange. I guess the kernel should map the ROM at the address OpenBoot/OF assigned to it. ( 1002 ). The address you see is a raw physical I/O address, which is a concatenation of the I/O window physical

Re: PCI Radeon RV100 detection hang on sparc64

From: Meelis Roos mr...@linux.ee Date: Thu, 6 Sep 2012 17:41:13 +0300 (EEST) And here the machine hangs. Debugging printk-s reveal that it does not find any active I/O port resources and then continues into initializing the card. Down in igp_read_bios_from_vram() it successfully ioremaps

Re: PCI Radeon RV100 detection hang on sparc64

From: Adam Jackson a...@redhat.com Date: Thu, 06 Sep 2012 12:51:17 -0400 On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: And here the machine hangs. Debugging printk-s reveal that it does not find any active I/O port resources and then continues into initializing the card. Down in

Re: PCI Radeon RV100 detection hang on sparc64

From: Michel Dänzer mic...@daenzer.net Date: Thu, 06 Sep 2012 18:55:51 +0200 On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in Ultra 10 (clean, without my Video RAM hack that I talked in other sparclinux posts). When

PCI Radeon RV100 detection hang on sparc64

From: Michel D?nzer Date: Thu, 06 Sep 2012 18:55:51 +0200 > On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: >> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in >> Ultra 10 (clean, without my "Video RAM" hack that I talked in other >> sparclinux

PCI Radeon RV100 detection hang on sparc64

From: Adam Jackson Date: Thu, 06 Sep 2012 12:51:17 -0400 > On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: > >> And here the machine hangs. Debugging printk-s reveal that it does not >> find any active I/O port resources and then continues into initializing >> the card.

PCI Radeon RV100 detection hang on sparc64

From: Meelis Roos Date: Thu, 6 Sep 2012 17:41:13 +0300 (EEST) > And here the machine hangs. Debugging printk-s reveal that it does not > find any active I/O port resources and then continues into initializing > the card. Down in igp_read_bios_from_vram() it successfully

Re: 3.3-rc4+: Reported regressions from 3.2

From: Rafael J. Wysocki r...@sisk.pl Date: Thu, 23 Feb 2012 23:51:20 +0100 (CET) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42776 Subject : OF-related boot crash in 3.3.0-rc3-00188-g3ec1e88 Submitter : Meelis Roos mr...@linux.ee Date : 2012-02-13

3.3-rc4+: Reported regressions from 3.2

From: "Rafael J. Wysocki" Date: Thu, 23 Feb 2012 23:51:20 +0100 (CET) > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=42776 > Subject : OF-related boot crash in 3.3.0-rc3-00188-g3ec1e88 > Submitter : Meelis Roos > Date : 2012-02-13 7:45 (11

Re: [PATCH 00/12] Fix various section mismatches and build errors.

See commit: commit 948252cb9e01d65a89ecadf67be5018351eee15e Author: David S. Miller da...@davemloft.net Date: Tue May 31 19:27:48 2011 -0700 Revert net: fix section mismatches This reverts commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4. It causes new build regressions

[PATCH 00/12] Fix various section mismatches and build errors.

See commit: commit 948252cb9e01d65a89ecadf67be5018351eee15e Author: David S. Miller Date: Tue May 31 19:27:48 2011 -0700 Revert "net: fix section mismatches" This reverts commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4. It causes new build regressions with gcc-4.2 which is

Re: Remaining BKL users, what to do

From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Thu, 16 Sep 2010 16:07:59 +0100 net/appletalk: net/ipx/af_ipx.c: net/irda/af_irda.c: Can probably be saved from retirement in drivers/staging if the maintainers still care. IPX and Appletalk both have active users. They also look

Re: Remaining BKL users, what to do

From: Samuel Ortiz sam...@sortiz.org Date: Thu, 16 Sep 2010 18:57:56 +0200 On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote: net/appletalk: net/ipx/af_ipx.c: net/irda/af_irda.c: Can probably be saved from retirement in drivers/staging if the maintainers still care. I'll

Remaining BKL users, what to do

From: Alan Cox Date: Thu, 16 Sep 2010 16:07:59 +0100 >> net/appletalk: >> net/ipx/af_ipx.c: >> net/irda/af_irda.c: >> Can probably be saved from retirement in drivers/staging if the >> maintainers still care. > > IPX and Appletalk both have active users. They

Remaining BKL users, what to do

From: Samuel Ortiz Date: Thu, 16 Sep 2010 18:57:56 +0200 > On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote: >> net/appletalk: >> net/ipx/af_ipx.c: >> net/irda/af_irda.c: >> Can probably be saved from retirement in drivers/staging if the >> maintainers still

[PATCH] drm/radeon: Fix sparc regression in r300_scratch()

Commit b4fe945405e477cded91772b4fec854705443dd5 ("drm/radeon: Fix memory allocation failures in the preKMS command stream checking.") added a regression in that it completely tossed the get_unaligned() done by r300_scratch() which we added in commit 958a6f8ccb1964adc3eec84cf401c5baeb4fbca0 ("drm: