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

[David Miller]

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.
> 
> When memory is allocated in 'ksz_alloc_desc()', GFP_KERNEL can be used
> because a few lines below, GFP_KERNEL is also used in the
> 'ksz_alloc_soft_desc()' calls.
 ...
> Signed-off-by: Christophe JAILLET 

Applied, thank you.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 pcidev_suspend(struct device *dev_d)
>   |^~
> 
> Mark pcidev_suspend() as __maybe_unused to make it clear.
> 
> Fixes: 64120615d140 ("ksz884x: use generic power management")
> Reported-by: Hulk Robot 
> Signed-off-by: Wei Yongjun 

Applied.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 lockdep/x86 IRQ state tracking patch series:
> 
>[PATCH 00/14] x86/entry: disallow #DB more and x86/entry lockdep/nmi
>https://lkml.kernel.org/r/20200529212728.795169...@infradead.org
> 
>[PATCH v3 0/5] lockdep: Change IRQ state tracking to use per-cpu variables
>https://lkml.kernel.org/r/20200529213550.683440...@infradead.org
> 
> This is a repost only of the seqcount_t call sites bugfixes that were on
> top of the seqlock patch series.
> 
> These fixes are independent, and can thus be merged on their own. I'm
> reposting them now so they can at least hit -rc2 or -rc3.
> 
> Changelog-v2:
> 
>   - patch #1: Add a missing up_read() on netdev_get_name() error path
>   exit. Thanks to Dan/kbuild-bot report.
> 
>   - patch #4: new patch, invalid preemptible context found by the new
>   lockdep checks added in the seqlock series + kbuild-bot.

I'll apply patches 1-4 to the net tree.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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: sparcli...@vger.kernel.org
> Signed-off-by: Emil Velikov 

Acked-by: David S. Miller 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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
> drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:2380:5-38: WARNING:
> Comparison to bool
> 
> Signed-off-by: Jason Yan 

Applied.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 #8.

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

[David Miller]

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 should work:
> 
> - 2 stmmac patches should go together via some networking tree (is there
>   something specific for stmmac?)
> - all DTS patches should go via sunxi
> - hdmi patches via some drm tree

Thank you.  So I'll merge the first two patches that touch the stmmac
driver via my net-next tree.

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

[David Miller]

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
> boot), when the stmmac driver is built into the kernel. It works when
> the driver is built as a module. It's either some timing issue, or power
> supply issue or a combination of both. Module build induces a power
> cycling of the phy.
> 
> I encourage people with this issue, to build the driver into the kernel,
> and try to alter the reset timings for the phy in DTS or
> startup-delay-us and report the findings.

This is a mixture of networking and non-networking changes so it really
can't go through my tree.

I wonder how you expect this series to be merged?

Thanks.

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

[David Miller]

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 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 prerequisite for the DMA mapping
>> work and overall consolidation you are doing.  So I kinda assumed
>> you wanted to merge it via your tree.
>> 
>> I anticipate no conflicts at all, even until the next merge window,
>> so it could very easily go through your tree.
>> 
>> Let me know if you still want me to merge this.
> 
> These patches are purely cleanups I found while auditing the DMA
> mapping code, at least as of now there are no dependencies.
> 
> That being said now that I looked into it a bit more they do however
> depend on the ->mapping_error removal, so I'll take them through
> the dma-mapping tree.

Ok, thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 prerequisite for the DMA mapping
work and overall consolidation you are doing.  So I kinda assumed
you wanted to merge it via your tree.

I anticipate no conflicts at all, even until the next merge window,
so it could very easily go through your tree.

Let me know if you still want me to merge this.

Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 Hellwig 

Acked-by: David S. Miller 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 Hellwig 

Acked-by: David S. Miller 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 

Acked-by: David S. Miller 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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).
> 
> Similarly a dma_supported method that always returns 0 is rather
> pointless.  The only thing that indicates is that no one ever calls
> the method on sbus devices.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: David S. Miller 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 "fuck" is now considered acceptable in certain
>> contexts on most channels in the UK and EU.
> 
> This makes following the CoC extremely hard to a non-native speaker as
> it is not too explicit on what is OK and what is not. I did through the
> whole thing with an eye glass and this what I deduced from it.

It would be helpful if you could explain what part of the language
is unclear wrt. explaining how CoC does not apply to existing code.

That part seems very explicit to me.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 this is some kind of joke. How would anyone get offended by reading
>> technical comments? This is all beyond me...
> 
> Agree, this is insanity.

And even worse it is censorship.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 distraction and a hostile environment for the discussion at
hand.

That would not be censorship.

There is a big difference.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 when booting (suprisingly, my LCD monitor can display it, although
> display quality is very low).
> 
> The reason is this: Older mach64 cards set the divider in the register
> VCLK_POST_DIV. The register has four 2-bit fields (the field that is
> actually used is specified in the lowest two bits of the register
> CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards,
> there's another bit added - the top four bits of PLL_EXT_CNTL extend the
> divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12".
> The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets
> them, so it can work regardless if the card supports them. However, the
> sparc64 firmware may set these extended dividers during boot - and the
> mach64 driver detects incorrect dot clock in this case.
> 
> This patch makes the driver read the additional divider bit from
> PLL_EXT_CNTL and calculate the initial refresh rate properly.
> 
> Signed-off-by: Mikulas Patocka 
> Cc: sta...@vger.kernel.org

Acked-by: David S. Miller 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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] 
> https://lkml.kernel.org/r/20180215151118.196756.99622.st...@bhelgaas-glaptop.roam.corp.google.com
> 
> Changes from v1:
> - In v1, I reserved the "Video ROM" and "System ROM" regions from system
>   memory, not from the PCI bus address space.  In v2, I removed those
>   reservations completely because they seem to be copied from x86 and are
>   not applicable on sparc.

For the series:

Acked-by: David S. Miller 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 struct device_node")
>> missed updating igafb.c to use dp->phandle instead of dp->node.
> Would it take a lot of work to port the driver to the new interface?
> 
> I'm not sure which SPARC machines use this particular framebuffer, but
> my plans are to fix up all these old framebuffer drivers. I have
> already
> received several Amiga (Zorro) graphics cards for testing the updated
> drivers on Amiga.
> 
> It could be that I actually have this particular SPARC framebuffer in
> my hardware collection.

Unless you have a 32-bit sparc laptop, you don't have a machine that
will use this driver.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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
> and sun4v cases for sparc64, and leave it unimplemented for PCI on
> sparc32, which means always supported.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: David S. Miller 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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, but they haven't
been very actively lately so whether you'll get a response or not is
hard to predict.

> Signed-off-by: Christoph Hellwig 

Acked-by: David S. Miller 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: clean up and modularize arch dma_mapping interface

[David Miller]

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
> on these ops.  This series tries to clean up a lot of those (but not all
> yet, but the series is big enough).  It gets rid of the DMA_ERROR_CODE
> way of signaling failures of the mapping routines from the
> implementations to the generic code (and cleans up various drivers that
> were incorrectly using it), and gets rid of the ->set_dma_mask routine
> in favor of relying on the ->dma_capable method that can be used in
> the same way, but which requires less code duplication.

There is unlikely to be conflicts for the sparc and net changes, so I
will simply ACK them.

Thanks Christoph.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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
> flows"), but it may be a later patch that introduced the non-recoverable
> behaviour.
> 
> Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
> Cc: Tvrtko Ursulin 
> Cc: Jeff Kirsher 
> Cc: Dave Ertman 
> Cc: Bruce Allan 
> Cc: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org
> Signed-off-by: Chris Wilson 
> [Jani: bikeshed repainted]
> Signed-off-by: Jani Nikula 

Jeff, please make sure this gets submitted to me soon.

Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] topic/e1000e-fix

[David Miller]

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 May 2017 at 08:10, David Miller <da...@davemloft.net> wrote:
>>>> From: Daniel Vetter <daniel.vet...@ffwll.ch>
>>>> 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 certain way, either you
>>>> do it that way or your patch isn't accepted.
>>
>> Consider this pull a regression report, pls handle it.
> 
> And I guess I pile of more cc, to make this regression report
> complete. I mean you got the backtrace, bisect and a proposed fix, and
> the almost-whitespace change demanded is something gcc does in its
> sleep. I'd understand a request to retest if it would be a real
> functional change, but in this situation I have no idea why this
> regression just can't be fixed already.

And we can't understand why respinning with the requested change is
less work than making several postings such as this one.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] topic/e1000e-fix

[David Miller]

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 certain way, either you
do it that way or your patch isn't accepted.

Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] uapi: use wildcards to list files

[David Miller]

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 headers under include/uapi/ should be exported, so let's
> use wildcards.
> 
> After this patch, the following files, which were not exported, are now
> exported:
 ...
> 
> Signed-off-by: Nicolas Dichtel 

Acked-by: David S. Miller 

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

[David Miller]

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: /git/arm-soc/drivers/net/skfp: No such file or directory 
> [-Werror=missing-include-dirs]
> cc1: error: drivers/net/skfp: No such file or directory 
> [-Werror=missing-include-dirs]
> 
> Clearly this include directive is not needed any more, so we can
> just remove it now.
> 
> Signed-off-by: Arnd Bergmann 

Applied.

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

[David Miller]

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 DIV_ROUND_UP in uapi

Series applied, thanks for so thoroughly taking care of this.

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

[David Miller]

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

[David Miller]

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.

[David Miller]

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 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 the specialized IO macros/functions,
>>> otherwise mapping VRAM CPU accessible isn't really possible.
>>>
>>> What's the background of the change? Some problems on a certain CPU
>>> platform? or just general cleanups?
>> It's an _iomem_ pointer, it's not a virtual address.
>>
>> Therefore it is illegal to dereference the pointer.
>>
>> The value is opaque and has values that only make sense when used
>> with the readb() et al. interfaces.
>>
>> This code is relying upon the fact that on x86 it happens to be
>> a virtual address, but this won't work on many other architectures.
> 
> In this case I'm perfectly fine with it and the patch is Reviewed-by:
> Christian König 
> 
> Just wanted to make sure that you're not trying to get Radeon working
> on a platform which will never really support the necessary hardware
> features.

I would like this to get merged via the Radeon DRM maintainer, thanks.

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

[David Miller]

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 the specialized IO macros/functions,
> otherwise mapping VRAM CPU accessible isn't really possible.
> 
> What's the background of the change? Some problems on a certain CPU
> platform? or just general cleanups?

It's an _iomem_ pointer, it's not a virtual address.

Therefore it is illegal to dereference the pointer.

The value is opaque and has values that only make sense when used
with the readb() et al. interfaces.

This code is relying upon the fact that on x86 it happens to be
a virtual address, but this won't work on many other architectures.

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

[David Miller]

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
@@ -76,7 +76,7 @@ static bool igp_read_bios_from_vram(struct radeon_device 
*rdev)

 static bool radeon_read_bios(struct radeon_device *rdev)
 {
-   uint8_t __iomem *bios;
+   uint8_t __iomem *bios, val1, val2;
size_t size;

rdev->bios = NULL;
@@ -86,15 +86,19 @@ static bool radeon_read_bios(struct radeon_device *rdev)
return false;
}

-   if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
+   val1 = readb([0]);
+   val2 = readb([1]);
+
+   if (size == 0 || val1 != 0x55 || val2 != 0xaa) {
pci_unmap_rom(rdev->pdev, bios);
return false;
}
-   rdev->bios = kmemdup(bios, size, GFP_KERNEL);
+   rdev->bios = kzalloc(size, GFP_KERNEL);
if (rdev->bios == NULL) {
pci_unmap_rom(rdev->pdev, bios);
return false;
}
+   memcpy_fromio(rdev->bios, bios, size);
pci_unmap_rom(rdev->pdev, bios);
return true;
 }

PCI Radeon RV100 detection hang on sparc64

[David Miller]

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 sparclinux with you CC:'d right now.

[PATCH 0/25] Replace DEFINE_PCI_DEVICE_TABLE macro use

[David Miller]

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 makes this change is as
> follows (http://coccinelle.lip6.fr/):
> 
> // 
> 
> @@
> identifier i;
> declarer name DEFINE_PCI_DEVICE_TABLE;
> initializer z;
> @@
> 
> - DEFINE_PCI_DEVICE_TABLE(i)
> + const struct pci_device_id i[]
> = z;
> 
> // 
> 
> I have 103 patches ready, and will only send a few for you to judge if
> it is useful enough, and to prevent from spamming too much.

I'm fine with this wrt. the networking changes, but I don't think this should
be merged via my tree.

[PATCH 00/22] Add and use pci_zalloc_consistent

[David Miller]

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 typing.

For networking bits:

Acked-by: David S. Miller 

PCI Radeon RV100 detection hang on sparc64

[David Miller]

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 concatenation
>> > of the I/O window physical address for that PCI controller and the
>> > PCI bus assigned address.
>> > 
>> > This is what we store in the resource values.
>> > 
>> > The pci_assign_resource() path must have some bug that causes the
>> > resource values to be set incorrectly or similar.
>> > 
>> > Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
>> > before the pci_map_rom() call?
>> 
>> [drm] radeon_read_bios: pci_resource_start(ROM)=01FF1002
>> 
>> I am a little confused here. ROM addressis OK but after pci_map_rom it 
>> results in address that corresponds to another device?
> 
> I read more code and tried a couple of more things.
> 
> Using ofpci_debug=1 I get sensible output for scsi:
> 
> PCI: scan_bus[/pci at 1f,0/pci at 1] bus no 2
>   * /pci at 1f,0/pci at 1/scsi at 1
> create device, devfn: 8, type: scsi-2
> class: 0x1 device name: :02:01.0
> parse addresses (40 bytes) @ f8003fedc1c0
>   start: 1ff2000, end: 1ff20ff, i: 14
>   start: 1ff0001, end: 1ff0001, i: 30
> adding to system ...
> 
> adding to system refers to pci_device_add(dev, bus) and that does not 
> modify the PCI bus available windows in any way, at least by my reafing 
> of the PCI code, so the PCI code does not know the resource ranges are 
> now busy?

I finally did some digging into this, and I think the issue is that
sparc needs to do pci_claim_resource() calls over all the PCI device
resources which are valid after we finish adding the PCI devices.

I'll try to follow up with a patch some time next week.

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

[David Miller]

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
  detection to move on to next problem.
 
 NACK.  All this function does it attempt to read the rom from the
 framebuffer PCI BAR.  If you get hangs reading the BAR, then you have
 larger problems on your platform.  Also, there are non-x86 platforms
 that IGP chips which this may break.
 
 OK. But the code seems to just dereference addresses returned from 
 ioremap, but to the best of my knowledge, these are not universally 
 (like on each arch) safe to read without readb/readw/readl. Should I 
 convert these to readb for test?

That's correct, ioremap() returned pointers must not be directly
dereferenced, and must be accessed through the appropriate accessors.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI Radeon RV100 detection hang on sparc64

[David Miller]

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 address for that PCI controller and the
 PCI bus assigned address.
 
 This is what we store in the resource values.
 
 The pci_assign_resource() path must have some bug that causes the
 resource values to be set incorrectly or similar.
 
 Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
 before the pci_map_rom() call?
 
 [drm] radeon_read_bios: pci_resource_start(ROM)=01FF1002
 
 I am a little confused here. ROM addressis OK but after pci_map_rom it 
 results in address that corresponds to another device?

That's certainly a bug.

So after pci_map_rom() pci_resource_start(ROM)=01FF, right?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI Radeon RV100 detection hang on sparc64

[David Miller]

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 
 memory region 0 (vram_base=1ff0800 and size=4) and tries to read 
 2 bytes from there and hangs on reading bios[0].

Mappings obtained from ioremap() may not be derefenced directly.

What you get back from ioremap() isn't a pointer.  It's an opaque
__iomem cookie, which must only be used via readl() et al.

On sparc64 ioremap() happens to return a physical address, that's why
this non-portable code crashes.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI Radeon RV100 detection hang on sparc64

[David Miller]

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 igp_read_bios_from_vram() it successfully ioremaps 
 memory region 0 (vram_base=1ff0800 and size=4) and tries to read 
 2 bytes from there and hangs on reading bios[0].
 
 This is probably because...

I think the real issue is that the VRAM bios reading code is buggy, see
my other email.  It deferences ioremap()'d memory, and that's not allowed.

One must use the proper __iomem pointer accessors, such as readl(), readb(),
etc.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI Radeon RV100 detection hang on sparc64

[David Miller]

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 I saw that Sun XVR-100 was detected fine by the 
 kernel, I compiled radeon drm driver with modesetting enabled and tried 
 it:
 
 [drm] radeon defaulting to kernel modesetting.
 [drm] radeon kernel modesetting enabled.
 PCI: Enabling device: (:02:02.0), cmd 82
 [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908).
 [drm] register mmio base: 0x1000
 [drm] register mmio size: 32768
 [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR
 
 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 
 memory region 0 (vram_base=1ff0800 and size=4) and tries to read 
 2 bytes from there and hangs on reading bios[0].
 
 Is the card initialized by OpenFirmware? E.g., does it display anything
 before the kernel boots?

I think Meelis gave you every single detail you need to know to
analyze and fix this bug.

He says it crashes on reading bios[0].

If you look at the function he tells you the crash occurs in, you'll
see clearly that bios is an ioremap()'d pointer.

You cannot dereference ioremap()'d pointers, you must use the proper
accessors such as readl().
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI Radeon RV100 detection hang on sparc64

[David Miller]

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 posts). When I saw that Sun XVR-100 was detected fine by the 
>> kernel, I compiled radeon drm driver with modesetting enabled and tried 
>> it:
>> 
>> [drm] radeon defaulting to kernel modesetting.
>> [drm] radeon kernel modesetting enabled.
>> PCI: Enabling device: (:02:02.0), cmd 82
>> [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908).
>> [drm] register mmio base: 0x1000
>> [drm] register mmio size: 32768
>> [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR
>> 
>> 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 
>> memory region 0 (vram_base=1ff0800 and size=4) and tries to read 
>> 2 bytes from there and hangs on reading bios[0].
> 
> Is the card initialized by OpenFirmware? E.g., does it display anything
> before the kernel boots?

I think Meelis gave you every single detail you need to know to
analyze and fix this bug.

He says it crashes on reading bios[0].

If you look at the function he tells you the crash occurs in, you'll
see clearly that bios is an ioremap()'d pointer.

You cannot dereference ioremap()'d pointers, you must use the proper
accessors such as readl().

PCI Radeon RV100 detection hang on sparc64

[David Miller]

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. Down in igp_read_bios_from_vram() it successfully ioremaps 
>> memory region 0 (vram_base=1ff0800 and size=4) and tries to read 
>> 2 bytes from there and hangs on reading bios[0].
> 
> This is probably because...

I think the real issue is that the VRAM bios reading code is buggy, see
my other email.  It deferences ioremap()'d memory, and that's not allowed.

One must use the proper __iomem pointer accessors, such as readl(), readb(),
etc.

PCI Radeon RV100 detection hang on sparc64

[David Miller]

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 ioremaps 
> memory region 0 (vram_base=1ff0800 and size=4) and tries to read 
> 2 bytes from there and hangs on reading bios[0].

Mappings obtained from ioremap() may not be derefenced directly.

What you get back from ioremap() isn't a pointer.  It's an opaque
__iomem cookie, which must only be used via readl() et al.

On sparc64 ioremap() happens to return a physical address, that's why
this non-portable code crashes.

Re: 3.3-rc4+: Reported regressions from 3.2

[David Miller]

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 7:45 (11 days old)
 Message-ID: alpine.soc.1.00.1202130942030.1...@math.ut.ee
 References: http://marc.info/?l=linux-kernelm=132911916331615w=2

Potential workaround/fix at:

http://marc.info/?l=linux-kernelm=132993294018762w=2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

3.3-rc4+: Reported regressions from 3.2

[David Miller]

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 days old)
> Message-ID: 
> References: http://marc.info/?l=linux-kernel=132911916331615=2

Potential workaround/fix at:

http://marc.info/?l=linux-kernel=132993294018762=2

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

[David Miller]

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 with gcc-4.2 which is
pretty common on non-x86 platforms.

Reported-by: James Bottomley james.bottom...@hansenpartnership.com
Signed-off-by: David S. Miller da...@davemloft.net

and postings that led to this revert including:

http://marc.info/?l=linux-netdevm=130653748205263w=2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[David Miller]

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
pretty common on non-x86 platforms.

Reported-by: James Bottomley 
Signed-off-by: David S. Miller 

and postings that led to this revert including:

http://marc.info/?l=linux-netdev=130653748205263=2

Re: Remaining BKL users, what to do

[David Miller]

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 fairly fixable
 as the lock_kernel just maps to a stack private mutex, or in several
 cases can simply be dropped - its just a push down legacy.

I'll take a stab at IPX and Appletalk.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Remaining BKL users, what to do

[David Miller]

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 take care of the IrDA part.

Thanks a lot Sam.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Remaining BKL users, what to do

[David Miller]

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 also look fairly fixable
> as the lock_kernel just maps to a stack private mutex, or in several
> cases can simply be dropped - its just a push down legacy.

I'll take a stab at IPX and Appletalk.

Remaining BKL users, what to do

[David Miller]

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 care.
> I'll take care of the IrDA part.

Thanks a lot Sam.

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

[David Miller]

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: radeon: Fix unaligned
access in r300_scratch().").

Put it back.

Signed-off-by: David S. Miller 

diff --git a/drivers/gpu/drm/radeon/r300_cmdbuf.c 
b/drivers/gpu/drm/radeon/r300_cmdbuf.c
index ea46d55..c5c2742 100644
--- a/drivers/gpu/drm/radeon/r300_cmdbuf.c
+++ b/drivers/gpu/drm/radeon/r300_cmdbuf.c
@@ -921,7 +921,7 @@ static int r300_scratch(drm_radeon_private_t *dev_priv,

ptr_addr = drm_buffer_read_object(cmdbuf->buffer,
sizeof(stack_ptr_addr), _ptr_addr);
-   ref_age_base = (u32 *)(unsigned long)*ptr_addr;
+   ref_age_base = (u32 *)(unsigned long)get_unaligned(ptr_addr);

for (i=0; i < header.scratch.n_bufs; i++) {
buf_idx = drm_buffer_pointer_to_dword(cmdbuf->buffer, 0);