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
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
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
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
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
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
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
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
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
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
Uevents are suppressed during attributes registration, but never
restored, so kobject_uevent() does nothing.
Signed-off-by: Maxime Bizon mbi...@freebox.fr
---
kernel/workqueue.c |1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 6203d29..6f5f9c7
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
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 mbi...@freebox.fr
---
fs/pstore/ram.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions
e 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 a439602..c8dac74 100644
--- a/drivers/
-by: Maxime Bizon mbi...@freebox.fr
---
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 a439602..c8dac74 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base
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
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 version
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
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 goal on
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
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
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
Commit-ID: d7959916026aaae60e1878ae33c7503b2cc4471d
Gitweb: http://git.kernel.org/tip/d7959916026aaae60e1878ae33c7503b2cc4471d
Author: Maxime Bizon mbi...@freebox.fr
AuthorDate: Mon, 29 Oct 2012 14:40:19 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 30 Oct 2012 10:16:46
Commit-ID: 37aeec36220c39f1b2e7118287d951fd9cfdd6b7
Gitweb: http://git.kernel.org/tip/37aeec36220c39f1b2e7118287d951fd9cfdd6b7
Author: Maxime Bizon mbi...@freebox.fr
AuthorDate: Mon, 29 Oct 2012 14:40:20 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 30 Oct 2012 10:16:47
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 +
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 +
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 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
Here is the proposal :
Looks fine
What is your
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 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, ...
>
>
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
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
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 2109
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 allocation
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, ...
Hmm, this
40 matches
Mail list logo
