On Monday 16 Mar 2015 à 16:54:54 (+0100), Jonas Gorski wrote:
> So I don't see how this breaks anything. But for the sake of the
> argument, let's give it a spin:
my mistake, you are right, I completely misread the patch.
--
Maxime
--
To unsubscribe from this list: send the line "unsubscribe l
On Thu, 2015-03-12 at 17:00 +0100, Nicolas Schichan wrote:
> When called from prom init code, bcm63xx_gpio_init() will fail as it
> will call gpiochip_add() which relies on a working kmalloc() to alloc
> the gpio_desc array and kmalloc is not useable yet at prom init time.
>
> Move bcm63xx_gpio_
On Thu, 2015-02-19 at 19:12 +0100, Sylvain Rochet wrote:
> Or use a 1-wire or I2C EEPROM to store your board information.
no, you don't reduce the human error probability.
eeprom needs to be preprogrammed, factory will at some point have a lot
of eeprom with different version, and will potentia
On Thu, 2015-02-19 at 19:38 +0200, Pantelis Antoniou wrote:
> Having to boot and tweak the bootloader settings to select the correct
> dtb (even if it’s present on the flash medium) takes time and is
> error-prone.
Dedicate a set of GPIO for board/PCB revision detection (it only costs a
few resi
On Fri, 2014-10-31 at 17:28 +0900, Joonsoo Kim wrote:
> I guess that it is okay that bcm_sysport_open() return -EINTR?
actually, since CMA alloc is hidden behind dma_alloc_coherent(), all you
get back is NULL and then return ENOMEM.
--
Maxime
--
To unsubscribe from this list: send the line "
Uevents are suppressed during attributes registration, but never
restored, so kobject_uevent() does nothing.
Signed-off-by: Maxime Bizon
---
kernel/workqueue.c |1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 6203d29..6f5f9c7 100644
--- a
Previous attempt to fix was b042e47491ba5f487601b5141a3f1d8582304170
Suggested use of is_power_of_2() was bogus because is_power_of_2(0) is
false (documented behaviour).
Signed-off-by: Maxime Bizon
---
fs/pstore/ram.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a
eased.
The proposed fix is to move the list_add() before sysfs attribute
creation.
Signed-off-by: Maxime Bizon
---
drivers/base/firmware_class.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index
On Sat, 2013-07-27 at 11:51 -0700, Tomasz Figa wrote:
> Well, it depends on how we use the DT. There are (at least) two possible
> usage scenarios:
>
> a) using DT as direct replacement for board files - this means that you
> are free to say that DTSes are strictly coupled with kernel ver
On Wed, 2012-11-14 at 13:07 +0100, Jonas Gorski wrote:
Thanks for addressing my concerns
> > We can even build a single kernel that support all SOCs/boards.
>
> That's not going to change with Device Tree, and I'm trying my best to
> keep this.
DT is said to be the solution to achieve this goa
On Sun, 2012-11-11 at 13:50 +0100, Jonas Gorski wrote:
> This patch series adds initial Device Tree support to BCM63XX by adding
> bindings for interrupts, GPIOs and clocks to Device Tree. Finally it adds
> one "real" user, the serial driver, to the device tree boards.
> 51 files changed, 1993 i
Commit-ID: 37aeec36220c39f1b2e7118287d951fd9cfdd6b7
Gitweb: http://git.kernel.org/tip/37aeec36220c39f1b2e7118287d951fd9cfdd6b7
Author: Maxime Bizon
AuthorDate: Mon, 29 Oct 2012 14:40:20 +0100
Committer: Ingo Molnar
CommitDate: Tue, 30 Oct 2012 10:16:47 +0100
x86/ce4100: Fix PCI
Commit-ID: d7959916026aaae60e1878ae33c7503b2cc4471d
Gitweb: http://git.kernel.org/tip/d7959916026aaae60e1878ae33c7503b2cc4471d
Author: Maxime Bizon
AuthorDate: Mon, 29 Oct 2012 14:40:19 +0100
Committer: Ingo Molnar
CommitDate: Tue, 30 Oct 2012 10:16:46 +0100
x86/ce4100: Fix reboot by
On Fri, 2012-10-05 at 17:04 +0200, Eric Dumazet wrote:
>
>
> What I plan is to not shrink size, unless specifically asked.
>
> Its 3.8 material anyway, so a stable fix is needed on skb_recycle()
> and NET_SKB_PAD minimal value.
You think removing skb_recycle() is too big a change for stable ?
On Fri, 2012-10-05 at 15:02 +0200, Eric Dumazet wrote:
> On Fri, 2012-10-05 at 14:51 +0200, Maxime Bizon wrote:
>
> > > New convention would be : pass number of needed bytes after current
> > > tail, not after current end.
> >
> > Fully agree on this
>
On Fri, 2012-10-05 at 14:22 +0200, Eric Dumazet wrote:
> Yes, but the idea of the patch was to _avoid_ next pskb_expand_head()
> calls...
yes but we cannot be sure of that, the caller may not have a good idea
of the headroom needed for the whole lifetime of the skb
it's better to think we will
On Fri, 2012-10-05 at 09:41 +0200, Eric Dumazet wrote:
> By the way, the commit you pointed has no effect on the reallocation
> performed by pskb_expand_head() :
The commit has a side effect, because the problem appeared after it was
merged (and goes away if I revert it)
> int size = nhead + sk
On Thu, 2012-10-04 at 19:17 +0200, Eric Dumazet wrote:
> > yes, on ipv6 forward path the default NET_SKB_PAD is too small, so each
> > packet forwarded has its headroom expanded, it is then recycled and gets
> > its original default headroom back, then it gets forwarded,
> > expanded, ...
>
> Hm
On Thu, 2012-10-04 at 18:50 +0200, Eric Dumazet wrote:
> > Since skb_recycle() resets skb->data using (skb->head + NET_SKB_PAD), a
> > recycled skb going multiple times through a path that needs to expand
> > skb head will get bigger and bigger each time, and you eventually end up
> > with an all
On Fri, 2012-08-31 at 19:21 -0700, Hugh Dickins wrote:
Hi,
> Francois is right that a GFP_ATOMIC allocation from pskb_expand_head()
> is failing, which can easily happen, and cause your "failed to reallocate
> TX buffer" errors; but it's well worth looking up what's actually on
> lines 2108 and
20 matches
Mail list logo
