On Wed, 28 Aug 2019 12:56:28 +0200
Bartosz Golaszewski wrote:
> śr., 28 sie 2019 o 10:38 Bartosz Golaszewski
> napisał(a):
> >
> > wt., 27 sie 2019 o 08:46 David Jander napisał(a):
> > >
> > > The type of reg_direction needs to match the t
The type of reg_direction needs to match the type of the regmap, which is
u8.
Signed-off-by: David Jander
---
drivers/gpio/gpio-pca953x.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 378b206d2dc9
The register number needs to be translated for chips with more than 8
ports. This patch fixes a bug causing all chips with more than 8 GPIO pins
to not work correctly.
Signed-off-by: David Jander
---
drivers/gpio/gpio-pca953x.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions
st of the effort will be at cleaning up the mess
and make sure that each one of the many users works well afterwards, and it
definitely takes someone who knows the code (and it's users) very well to pull
this off.
Best regards,
--
David Jander
Protonic Holland.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 17 Dec 2015 12:39:20 +0100
Ulf Hansson wrote:
> On 17 December 2015 at 12:27, Lucas Stach wrote:
> > Am Donnerstag, den 17.12.2015, 12:20 +0100 schrieb David Jander:
> >> Hi Lucas,
> >>
> >> Thanks for reacting.
> >>
> >> On T
Hi Lucas,
Thanks for reacting.
On Thu, 17 Dec 2015 12:03:10 +0100
Lucas Stach wrote:
> Am Donnerstag, den 17.12.2015, 11:28 +0100 schrieb David Jander:
> > Hi all,
> >
> > I was investigating the source of abnormal irq-latency spikes on an i.MX6
> >
e either must be a reason this hasn't been fixed in such a
long time, or I am not understanding this correctly, so please enlighten me.
Before trying a cowboy attempt at "fixing" this, I'd really like to know why am
I seeing this?
I mean... how can such a problem get unnoticed and unfixed for
e
and my knowledge. I think most of the effort will be at cleaning up the mess
and make sure that each one of the many users works well afterwards, and it
definitely takes someone who knows the code (and it's users) very well to pull
this off.
Best regards,
--
David Jander
Protonic Holland.
On Thu, 17 Dec 2015 12:39:20 +0100
Ulf Hansson <ulf.hans...@linaro.org> wrote:
> On 17 December 2015 at 12:27, Lucas Stach <l.st...@pengutronix.de> wrote:
> > Am Donnerstag, den 17.12.2015, 12:20 +0100 schrieb David Jander:
> >> Hi Lucas,
> >>
> >&g
e either must be a reason this hasn't been fixed in such a
long time, or I am not understanding this correctly, so please enlighten me.
Before trying a cowboy attempt at "fixing" this, I'd really like to know why am
I seeing this?
I mean... how can such a problem get unnoticed and unfixed for
Hi Lucas,
Thanks for reacting.
On Thu, 17 Dec 2015 12:03:10 +0100
Lucas Stach <l.st...@pengutronix.de> wrote:
> Am Donnerstag, den 17.12.2015, 11:28 +0100 schrieb David Jander:
> > Hi all,
> >
> > I was investigating the source of abnormal irq-latency spikes
Dear Ulf,
On Thu, 4 Jun 2015 10:31:59 +0200
Ulf Hansson wrote:
> On 3 June 2015 at 10:34, David Jander wrote:
> > In the (not so unlikely) case that the mmc controller timeout budget is
> > enough for exactly one erase-group, the simplification of allowing one
> > s
Dear Ulf,
On Thu, 4 Jun 2015 10:31:59 +0200
Ulf Hansson ulf.hans...@linaro.org wrote:
On 3 June 2015 at 10:34, David Jander da...@protonic.nl wrote:
In the (not so unlikely) case that the mmc controller timeout budget is
enough for exactly one erase-group, the simplification of allowing
can allow trimming more than one sector at a time.
Signed-off-by: David Jander
---
Changes since v1:
- Added more comment
drivers/mmc/core/core.c | 38 ++
include/linux/mmc/card.h | 1 +
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers
can allow trimming more than one sector at a time.
Signed-off-by: David Jander da...@protonic.nl
---
Changes since v1:
- Added more comment
drivers/mmc/core/core.c | 38 ++
include/linux/mmc/card.h | 1 +
2 files changed, 35 insertions(+), 4 deletions
Dear Adrian,
Thanks for reacting.
On Thu, 04 Jun 2015 14:16:23 +0300
Adrian Hunter wrote:
> On 04/06/15 13:20, David Jander wrote:
> > Signed-off-by: David Jander
>
> Please never send delta patches. Always send a new version of the whole
> patch.
Sorry for th
Signed-off-by: David Jander
---
drivers/mmc/core/core.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 6c9611b..b6aa9ad 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
On Thu, 4 Jun 2015 10:31:59 +0200
Ulf Hansson wrote:
> On 3 June 2015 at 10:34, David Jander wrote:
> > In the (not so unlikely) case that the mmc controller timeout budget is
> > enough for exactly one erase-group, the simplification of allowing one
> > sector has an
On Thu, 4 Jun 2015 10:15:28 +0200
Ulf Hansson wrote:
> On 1 June 2015 at 15:32, David Jander wrote:
> > On Mon, 01 Jun 2015 15:38:51 +0300
> > Adrian Hunter wrote:
> >
> >> On 01/06/15 15:30, David Jander wrote:
> >> > On Mon, 01 Jun 2015
On Thu, 4 Jun 2015 10:15:28 +0200
Ulf Hansson ulf.hans...@linaro.org wrote:
On 1 June 2015 at 15:32, David Jander da...@protonic.nl wrote:
On Mon, 01 Jun 2015 15:38:51 +0300
Adrian Hunter adrian.hun...@intel.com wrote:
On 01/06/15 15:30, David Jander wrote:
On Mon, 01 Jun 2015 14:50
On Thu, 4 Jun 2015 10:31:59 +0200
Ulf Hansson ulf.hans...@linaro.org wrote:
On 3 June 2015 at 10:34, David Jander da...@protonic.nl wrote:
In the (not so unlikely) case that the mmc controller timeout budget is
enough for exactly one erase-group, the simplification of allowing one
sector
Signed-off-by: David Jander da...@protonic.nl
---
drivers/mmc/core/core.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 6c9611b..b6aa9ad 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers
Dear Adrian,
Thanks for reacting.
On Thu, 04 Jun 2015 14:16:23 +0300
Adrian Hunter adrian.hun...@intel.com wrote:
On 04/06/15 13:20, David Jander wrote:
Signed-off-by: David Jander da...@protonic.nl
Please never send delta patches. Always send a new version of the whole
patch.
Sorry
can allow trimming more than one sector at a time.
Signed-off-by: David Jander
---
drivers/mmc/core/core.c | 21 +
include/linux/mmc/card.h | 1 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 92e7671
can allow trimming more than one sector at a time.
Signed-off-by: David Jander da...@protonic.nl
---
drivers/mmc/core/core.c | 21 +
include/linux/mmc/card.h | 1 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
On Mon, 01 Jun 2015 15:38:51 +0300
Adrian Hunter wrote:
> On 01/06/15 15:30, David Jander wrote:
> > On Mon, 01 Jun 2015 14:50:47 +0300
> > Adrian Hunter wrote:
> >
> >> On 01/06/15 14:32, David Jander wrote:
> >>> On Mon, 01 Jun 2015
On Mon, 01 Jun 2015 14:50:47 +0300
Adrian Hunter wrote:
> On 01/06/15 14:32, David Jander wrote:
> > On Mon, 01 Jun 2015 13:36:45 +0300
> > Adrian Hunter wrote:
> >
> >> On 01/06/15 12:20, David Jander wrote:
> >>> qty is the maximum numb
On Mon, 01 Jun 2015 13:36:45 +0300
Adrian Hunter wrote:
> On 01/06/15 12:20, David Jander wrote:
> > qty is the maximum number of discard that _do_ fit in the timeout, not
> > the first amount that does _not_ fit anymore.
> > This seemingly harmless error has a very seve
qty is the maximum number of discard that _do_ fit in the timeout, not
the first amount that does _not_ fit anymore.
This seemingly harmless error has a very severe performance impact when
the timeout value is enough for only 1 erase group.
Signed-off-by: David Jander
---
drivers/mmc/core
On Mon, 01 Jun 2015 13:36:45 +0300
Adrian Hunter adrian.hun...@intel.com wrote:
On 01/06/15 12:20, David Jander wrote:
qty is the maximum number of discard that _do_ fit in the timeout, not
the first amount that does _not_ fit anymore.
This seemingly harmless error has a very severe
On Mon, 01 Jun 2015 14:50:47 +0300
Adrian Hunter adrian.hun...@intel.com wrote:
On 01/06/15 14:32, David Jander wrote:
On Mon, 01 Jun 2015 13:36:45 +0300
Adrian Hunter adrian.hun...@intel.com wrote:
On 01/06/15 12:20, David Jander wrote:
qty is the maximum number of discard that _do_
qty is the maximum number of discard that _do_ fit in the timeout, not
the first amount that does _not_ fit anymore.
This seemingly harmless error has a very severe performance impact when
the timeout value is enough for only 1 erase group.
Signed-off-by: David Jander da...@protonic.nl
On Mon, 01 Jun 2015 15:38:51 +0300
Adrian Hunter adrian.hun...@intel.com wrote:
On 01/06/15 15:30, David Jander wrote:
On Mon, 01 Jun 2015 14:50:47 +0300
Adrian Hunter adrian.hun...@intel.com wrote:
On 01/06/15 14:32, David Jander wrote:
On Mon, 01 Jun 2015 13:36:45 +0300
Adrian
this node to overlap with another node. Those nodes should be merged,
but this merge doesn't happen yet, so this patch at least makes the initial
blklen small enough to avoid hitting the wrong node, which may otherwise
lead to severe breakage.
Signed-off-by: David Jander
---
drivers/base/regmap
On Wed, 21 Aug 2013 15:44:42 +0100
Mark Brown wrote:
> On Wed, Aug 21, 2013 at 04:21:43PM +0200, David Jander wrote:
>
> > I hope you can explain to me how regcache_rbtree_node_alloc() is supposed
> > to work, because I start to think that something in there is broken...
>
On Wed, 21 Aug 2013 15:08:16 +0100
Mark Brown wrote:
> On Wed, Aug 21, 2013 at 03:14:23PM +0200, David Jander wrote:
>
> > Here's the explanation:
>
> > 1. If a driver initializes a regmap with a RB-tree cache, and starts
> > writing to registers in some arb
On Wed, 21 Aug 2013 15:08:16 +0100
Mark Brown wrote:
> On Wed, Aug 21, 2013 at 03:14:23PM +0200, David Jander wrote:
>
> > Here's the explanation:
>
> > 1. If a driver initializes a regmap with a RB-tree cache, and starts
> > writing to registers in some arb
On Wed, 21 Aug 2013 14:32:00 +0100
Mark Brown wrote:
> On Wed, Aug 21, 2013 at 03:02:35PM +0200, David Jander wrote:
>
> > rbnode register ranges can overlap, which is not a problem as long as
>
> They can? They aren't supposed to and I'd expect this to cause problems
>
Hi Dimitris,
On Wed, 21 Aug 2013 15:02:35 +0200
David Jander wrote:
> The functionality of rbtree_ctx->cached_rbnode is broken. Remove it to
> avoid hitting the wrong rbnode when locating a register.
> rbnode register ranges can overlap, which is not a problem as long as
&g
rom the top of the rb-tree _always_.
Signed-off-by: David Jander
---
drivers/base/regmap/regcache-rbtree.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/base/regmap/regcache-rbtree.c
b/drivers/base/regmap/regcache-rbtree.c
index 5c1435c..2f9783f 100644
--- a/drivers/base/reg
of the rb-tree _always_.
Signed-off-by: David Jander da...@protonic.nl
---
drivers/base/regmap/regcache-rbtree.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/base/regmap/regcache-rbtree.c
b/drivers/base/regmap/regcache-rbtree.c
index 5c1435c..2f9783f 100644
Hi Dimitris,
On Wed, 21 Aug 2013 15:02:35 +0200
David Jander da...@protonic.nl wrote:
The functionality of rbtree_ctx-cached_rbnode is broken. Remove it to
avoid hitting the wrong rbnode when locating a register.
rbnode register ranges can overlap, which is not a problem as long as
every
On Wed, 21 Aug 2013 14:32:00 +0100
Mark Brown broo...@kernel.org wrote:
On Wed, Aug 21, 2013 at 03:02:35PM +0200, David Jander wrote:
rbnode register ranges can overlap, which is not a problem as long as
They can? They aren't supposed to and I'd expect this to cause problems
On Wed, 21 Aug 2013 15:08:16 +0100
Mark Brown broo...@kernel.org wrote:
On Wed, Aug 21, 2013 at 03:14:23PM +0200, David Jander wrote:
Here's the explanation:
1. If a driver initializes a regmap with a RB-tree cache, and starts
writing to registers in some arbitrary order, you might get
On Wed, 21 Aug 2013 15:08:16 +0100
Mark Brown broo...@kernel.org wrote:
On Wed, Aug 21, 2013 at 03:14:23PM +0200, David Jander wrote:
Here's the explanation:
1. If a driver initializes a regmap with a RB-tree cache, and starts
writing to registers in some arbitrary order, you might get
On Wed, 21 Aug 2013 15:44:42 +0100
Mark Brown broo...@kernel.org wrote:
On Wed, Aug 21, 2013 at 04:21:43PM +0200, David Jander wrote:
I hope you can explain to me how regcache_rbtree_node_alloc() is supposed
to work, because I start to think that something in there is broken...
Specially
this node to overlap with another node. Those nodes should be merged,
but this merge doesn't happen yet, so this patch at least makes the initial
blklen small enough to avoid hitting the wrong node, which may otherwise
lead to severe breakage.
Signed-off-by: David Jander da...@protonic.nl
---
drivers
47 matches
Mail list logo
