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
>
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
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
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
d
From: Daniel Vetter
Date: Wed, 31 May 2017 08:10:45 +0200
> On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter wrote:
>> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie wrote:
>>> On 31 May 2017 at 08:10, David Miller wrote:
>>>> From: Daniel Vetter
>>>
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 th
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.
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 mail
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'
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 ca
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:
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/ shou
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.
>
> W
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.
__
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
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/
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: sparc
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 p
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 lock
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
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.
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
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
>
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
From: Kjetil Oftedal
Date: Mon, 23 Sep 2013 21:06:11 +0200
> 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 f
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 wind
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/mai
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
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.
___
dr
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
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 thi
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 "fu
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-deve
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
_
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:
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).
>
> S
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
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
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
ht
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 He
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 He
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
ht
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-de
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
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
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 u
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
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.19
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-deve
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
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 regio
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_
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
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 regio
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_
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
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)
> Mes
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
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:
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
>
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
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)
> Mes
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
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
>
From: Meelis Roos
Date: Thu, 10 Oct 2013 18:26:39 +0300 (EEST)
>> On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos 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
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:
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
p
From: David Miller
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 wi
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
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,
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/fun
From: Christian König
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
>>> b
72 matches
Mail list logo
