Signed-off-by: Michał Mirosław
---
patch against https://github.com/torvalds/linux.git master
drivers/regulator/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2785843..6b3550a 100644
--- a/drivers
> use of the deprecated APIs.
>
> Cc: Michał Mirosław
> Signed-off-by: Ulf Hansson
Patch looks consistent with commit message. I can't test it on HW, though.
Acked-by: Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Tue, Sep 24, 2013 at 10:40:57AM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> irq allocated with devm_request_irq should not be freed using
> free_irq, because doing so causes a dangling pointer, and a
> subsequent double free.
>
> Signed-off-by: Wei Yongjun
Acke
> application bug.
This is certainly a bug in NM, and a fresh one: commit
b636ea86b1c0a28b77eda311c84d3b2417cad22e from 2013-04-10 14:40:58
(GMT). Userspace is expected to use ETHTOOL_GSTRINGS for
ETH_SS_FEATURES and find a corresponding bit position by feature name
("vlan-challenged&qu
thing cares about the .../eth0/flags value because with the bit
> ordering different for bits 10 and above things break.
Are you sure it's "flags"? /sys/class/net/*/features were removed some
time ago, and flags don't depend on NETIF_F_*.
Best Regards,
Michał Mirosław
--
To
sk.ptr = NULL;
> + } else {
> + ctx->count = count;
> + }
> ctx->flags = flags;
>
> file = anon_inode_getfile("[eventfd]", &eventfd_fops, ctx,
Since EFD_MASK is a persistent flag for a fd's lifetime, maybe
Simple micro-optimization: Don't change any options if the instance is
being destroyed.
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.42007-02-11
20:46:26.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c 2007-
It's nice to log packet arrival time of those little filthy packets. ;)
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.82007-02-11
23:59:01.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c 2007-02-12 00:19:1
Stop reference leaking in nfulnl_log_packet(). If we start a timer we
are already taking another reference.
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.02007-02-11
20:20:27.0 +0100
+++ linux-2.6.20/net/net
Simple micro-optimization: don't call instance_put() on known NULL pointers.
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.32007-02-11
20:46:33.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c 2007-
Dear list,
After meeting a faint-hearted Linux kernel lately I decided to try myself
at persuading it to not be afraid of NFLOG. This chat gave a series of
ten commandments I present today. Take a look and agree or comment.
Here's the list:
1. nfulnl_log_packet() - don't count the same thing t
Paranoia: instance_put() might have freed the inst pointer when we
spin_unlock_bh().
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.22007-02-11
20:43:24.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c 2007-02-11
4/0x51 [nfnetlink_log] SS:ESP 0068:c03f5f30
<0>Kernel panic - not syncing: Fatal exception in interrupt
<0>Rebooting in 5 seconds..
Panic no more!
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.72007-02-11
22:41:18.
We don't need local nlbufsiz (skb size) as nfulnl_alloc_skb() takes
the maximum anyway.
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.orig 2007-02-10
18:25:14.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c 2007-
Kill some duplicate code in nfulnl_log_packet().
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.12007-02-11
20:51:57.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c 2007-02-11 20:43:24.0
+0100
@@ -666,30 +
Shorten instances_lock window at the cost of doing unnecessary work
on the failure case. I don't know if it makes sense actually. ;>
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.62007-02-11
22:31:19.0 +0100
++
Count module references correctly: after instance_destroy() there
might be timer pending and holding a reference for this netlink instance.
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.52007-02-11
22:24:56.0 +0100
+++
Dear list,
As it turned out, not all worms eating nfnetlink_log have been exterminated
by my last patch series. I'll append next four patches to the end of the
series and I hope that it doesn't make your patching scripts unhappy.
Those patches fix two bugs and make two other code beautifications:
get_*() don't need access to seq_file - iter_state is enough for them.
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.92007-02-12
00:19:16.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c 2007-02-12 17:05:1
Eliminate possible NULL pointer dereference in nfulnl_recv_config().
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.10 2007-02-12
17:05:14.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c 2007-02-12 17:35:50.000
Fix reference counting (memory leak) problem in __nfulnl_send() and callers
related to packet queueing.
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.11 2007-02-12
17:35:50.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink
No other function calls __nfulnl_send() with inst->skb == NULL than
nfulnl_timer().
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.12 2007-02-12
17:58:01.0 +0100
+++ linux-2.6.20/net/netfilter/nfnetlink_log.c 2007-02
On Tue, Feb 13, 2007 at 01:58:34PM +0100, Patrick McHardy wrote:
> Micha³ Miros³aw wrote:
> > Fix reference counting (memory leak) problem in __nfulnl_send() and callers
> > related to packet queueing.
> >
> > Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]&
Patch updated to apply after a new version of 13/14:
No other function calls __nfulnl_send() with inst->skb == NULL than
nfulnl_timer().
Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
--- linux-2.6.20/net/netfilter/nfnetlink_log.c.12 2007-02-14
12:27:09.0 +0100
On Thu, Jun 21, 2018 at 02:28:20PM -0700, Matthew Wilcox wrote:
> Eliminates the custom spinlock and the call to ida_pre_get.
>
> Signed-off-by: Matthew Wilcox
Acked-by: Michał Mirosław
On Fri, Feb 12, 2021 at 06:26:41PM +, Michal Rostecki wrote:
> On Wed, Feb 10, 2021 at 05:08:05AM +0100, Michał Mirosław wrote:
> > On Tue, Feb 09, 2021 at 09:30:38PM +0100, Michal Rostecki wrote:
> > > From: Michal Rostecki
> > >
> > > Add the btrfs_ch
On Mon, Feb 08, 2021 at 02:45:51PM +0100, Emil Renner Berthing wrote:
> This converts the driver to use the new tasklet API introduced in
> commit 12cc923f1ccc ("tasklet: Introduce new initialization API")
>
> Signed-off-by: Emil Renner Berthing
Acked-by: Michał Mirosław
rue;
> + if (!fs_devices->mixed)
> + fs_devices->mixed = btrfs_check_mixed(fs_devices, rotating);
Duplication. Maybe pull all this into a function?
Best Regards,
Michał Mirosław
a single mirror will be selected for next reads (until a read on
some other one completes).
Have you tried testing with much more jobs / non-sequential accesses?
Best Reagrds,
Michał Mirosław
On Wed, Feb 10, 2021 at 12:29:25PM +, Michal Rostecki wrote:
> On Wed, Feb 10, 2021 at 05:24:28AM +0100, Michał Mirosław wrote:
> > On Tue, Feb 09, 2021 at 09:30:40PM +0100, Michal Rostecki wrote:
> > [...]
> > > For the array with 3 HDDs, not adding any pena
h to next function elants_i2c_resume()
>
> Reported-by: Randy Dunlap
> Acked-by: Randy Dunlap
> Signed-off-by: Josh Poimboeuf
Reviewed-by: Michał Mirosław
> ---
> drivers/input/touchscreen/elants_i2c.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --
On Wed, Feb 10, 2021 at 07:23:04PM +, Michal Rostecki wrote:
> On Wed, Feb 10, 2021 at 01:58:15PM +0100, Michał Mirosław wrote:
> > On Wed, Feb 10, 2021 at 12:29:25PM +, Michal Rostecki wrote:
> > > On Wed, Feb 10, 2021 at 05:24:28AM +0100, Michał Mirosław wrote:
> >
gt; __u32 pad;
> };
>
> where:
>
> .size = sizeof(struct ptrace_rseq_configuration),
>
> This way, the configuration structure can be expanded in the future. The
> rseq ABI structure is by definition fixed-size, so there is no point in
> having its size here.
>
> Florian, did I understand your request correctly, or am I missing your point ?
In this case returning sizeof(conf) would serve the same purpose, wouldn't it?
Best Regards
Michał Mirosław
[Resent because of HTML mail misfeature...]
rates spurious trace events if you enable them.
> You mean the trace events from core.c? If it is, we could try to improve it
> and indicate it is already enabled or disabled.
It is indicated in return code, but the problem is that this generates
noise and wastes debugging time. The problem I was seeing manifested
itself as disabling disabled EPs and desync of EP state between core
and UDC driver. The patch avoids the noise and makes the code obvious.
(This check was there at some point in time, BTW.)
Best Regards,
Michał Mirosław
Uninterruptible context is not needed in the driver and causes lockdep
warning because of mutex taken in of_alias_get_id(). Convert the lock to
mutex to avoid the issue.
Cc: sta...@vger.kernel.org
Signed-off-by: Michał Mirosław
---
drivers/misc/atmel-ssc.c | 24
1 file
> Would you like to add the tag “Fixes” to the commit message?
I guess we can add:
Fixes: 099343c64e16 ("ARM: at91: atmel-ssc: add device tree support")
Best Regards
Michał Mirosław
On Mon, Aug 10, 2020 at 11:15:28PM +0300, Dmitry Osipenko wrote:
> 10.08.2020 23:09, Michał Mirosław пишет:
> > At first I also thought so, but there's more. Below is a lockdep
> > complaint with your patch applied. I did a similar patch and then two more
> > (follow
On Mon, Aug 10, 2020 at 11:56:13PM +0300, Dmitry Osipenko wrote:
> 10.08.2020 23:21, Dmitry Osipenko пишет:
> > 10.08.2020 23:18, Michał Mirosław пишет:
> >> On Mon, Aug 10, 2020 at 11:15:28PM +0300, Dmitry Osipenko wrote:
> >>> 10.08.2020 23:09, Michał Mirosław
The code modifies rdev, but locks c_rdev instead. The bug remains:
stored c_rdev could be freed just after unlock anyway. This doesn't blow
up because regulator_list_mutex taken outside holds it together.
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 4
1 file chang
ister()")
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 0408c4e1d9a8..a9ff2ad55ee7 100644
--- a/drivers/regulator/core.c
+++ b/drivers
Pull regulator_list_mutex into set_consumer_device_supply() and keep
allocations outside of it. Fourth of the fs_reclaim deadlock case.
Cc: sta...@vger.kernel.org
Fixes: 45389c47526d ("regulator: core: Add early supply resolution for
regulators")
Signed-off-by: Michał Mirosław
--
s context]
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
[this is when the regulator_list_mutex was introduced in reclaim locking path]
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 19 ++-
1 file changed, 14 insertions(+),
please review and test further.
First four patches move allocations out of locked regions, next three
came as a drive-by cleanups.
Michał Mirosław (7):
regulator: push allocation in regulator_init_coupling() outside of
lock
regulator: push allocation in regulator_ena_gpio_request() out of
Since only regulator_ena_gpio_request() allocates rdev->ena_pin, and it
guarantees that same gpiod gets same pin structure, it is enough to
compare just the pointers. Also we know there can be only one matching
entry on the list. Rework the code take advantage of the facts.
Signed-off-by: Mic
ster+0x9c8/0x163c
[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> &sit_i->sentry_lock --> &dcc->cmd_lock
[...]
Cc: sta...@vger.kernel.org
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Sign
, at: __fs_reclaim_acquire+0x0/0x50
[...]
Cc: sta...@vger.kernel.org
Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling
customization")
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
On Tue, Aug 11, 2020 at 07:27:43PM +0300, Dmitry Osipenko wrote:
> 11.08.2020 18:59, Dmitry Osipenko пишет:
> > 11.08.2020 04:07, Michał Mirosław пишет:
> >> Allocating memory with regulator_list_mutex held makes lockdep unhappy
> >> when memory pressure makes the syste
On Tue, Aug 11, 2020 at 01:23:47PM +0800, kernel test robot wrote:
[...]
> New smatch warnings:
> drivers/regulator/core.c:1491 set_consumer_device_supply() warn: overwrite
> may leak 'node'
Ah! Good catch!
The code modifies rdev, but locks c_rdev instead. Remove the lock
as this is held together by regulator_list_mutex taken in the caller.
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
Fixes: f9503385b187 ("regulator: core: Mutually resolve regulators coupling")
---
, at: __fs_reclaim_acquire+0x0/0x50
[...]
Cc: sta...@vger.kernel.org
Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling
customization")
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
---
drivers/regulator/core.c | 5 +++--
1 file changed, 3 ins
ister()")
Signed-off-by: Michał Mirosław
Acked-by: Vladimir Zapolskiy
---
drivers/regulator/core.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 71749f48caee..448a267641df 100644
--- a/drivers/regula
Pull regulator_list_mutex into set_consumer_device_supply() and keep
allocations outside of it. Fourth of the fs_reclaim deadlock case.
Cc: sta...@vger.kernel.org
Fixes: 45389c47526d ("regulator: core: Add early supply resolution for
regulators")
Signed-off-by: Michał Mirosław
---
v
please review and test further.
First four patches move allocations out of locked regions, next three
came as a drive-by cleanups.
---
v2: fix bug in patch #4 spotted by kernel test robot
reworded commit #7 description
Michał Mirosław (7):
regulator: push allocation in
Since only regulator_ena_gpio_request() allocates rdev->ena_pin, and it
guarantees that same gpiod gets same pin structure, it is enough to
compare just the pointers. Also we know there can be only one matching
entry on the list. Rework the code take advantage of the facts.
Signed-off-by: Mic
ster+0x9c8/0x163c
[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> &sit_i->sentry_lock --> &dcc->cmd_lock
[...]
Cc: sta...@vger.kernel.org
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Sign
s context]
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
[this is when the regulator_list_mutex was introduced in reclaim locking path]
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 19 ++-
1 file changed, 14 insertions(+),
On Wed, Aug 12, 2020 at 09:29:12AM +0300, Vladimir Zapolskiy wrote:
> On 8/12/20 4:31 AM, Michał Mirosław wrote:
[...]
> > config = kmemdup(cfg, sizeof(*cfg), GFP_KERNEL);
> > if (config == NULL) {
> > - kfree(rdev);
> > ret = -ENOMEM;
The code allocates sizeof(regulator_dev) for a pointer. Make it less
generous. Let kcalloc() calculate the size, while at it.
Cc: sta...@vger.kernel.org
Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling
customization")
Signed-off-by: Michał Mirosław
--
Simplify regulator locking by removing locking around locking. rdev->ref
is now accessed only when the lock is taken. The code still smells fishy,
but now its obvious why.
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Michał Mirosław
ver way to much (eg. initialization even before making the
regulator visible to the system).
To fix the regulator vs memory reclaim path I tried pushing all allocations
out of protected sections. After doing a few patches, though, I'm not sure
I'm going in the right direction. Your thoug
On Mon, Aug 10, 2020 at 12:40:04AM +0300, Dmitry Osipenko wrote:
> 10.08.2020 00:16, Michał Mirosław пишет:
> > Simplify regulator locking by removing locking around locking. rdev->ref
> > is now accessed only when the lock is taken. The code still smells fishy,
> >
On Mon, Aug 10, 2020 at 03:21:47AM +0300, Dmitry Osipenko wrote:
> 10.08.2020 01:30, Michał Mirosław пишет:
> > On Mon, Aug 10, 2020 at 12:40:04AM +0300, Dmitry Osipenko wrote:
> >> 10.08.2020 00:16, Michał Mirosław пишет:
> >>> Simplify regulator locking by removin
On Mon, Aug 10, 2020 at 03:21:47AM +0300, Dmitry Osipenko wrote:
> 10.08.2020 01:30, Michał Mirosław пишет:
> > On Mon, Aug 10, 2020 at 12:40:04AM +0300, Dmitry Osipenko wrote:
> >> 10.08.2020 00:16, Michał Mirosław пишет:
> >>> Simplify regulator locking by removin
regulator_lock/unlock() was used only to guard
regulator_notifier_call_chain(). As no users remain, make the functions
internal.
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 6 ++
include/linux/regulator/driver.h | 3 ---
2 files changed, 2 insertions(+), 7
forced to be taken recursively.
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index b0662927487c..f4035167e7ba 100644
--- a/drivers/regulator/core.c
+++ b/driver
regulator_notifier_call_chain() doesn't need rdev lock and rdev's
existence is assumed in the code anyway. Remove the locks from drivers.
Signed-off-by: Michał Mirosław
---
drivers/regulator/da9055-regulator.c | 2 --
drivers/regulator/da9062-regulator.c | 2 --
drivers/regula
only client that needed recursive locking from the notifier chain
was drivers/usb/host/ohci-da8xx.c, which responds to over-current
notification by calling regulator_disable().
Michał Mirosław (3):
regulator: don't require mutex for regulator_notifier_call_chain()
regulator: remove lock
On Mon, Aug 10, 2020 at 04:39:28PM +0100, Mark Brown wrote:
> On Mon, Aug 10, 2020 at 12:25:37AM +0200, Michał Mirosław wrote:
>
> > regulator_lock_dependent() starts by taking regulator_list_mutex, The
> > same mutex covers eg. regulator initialization, including memory al
On Mon, Aug 10, 2020 at 08:14:20AM +0300, Dmitry Osipenko wrote:
> 10.08.2020 03:59, Michał Mirosław пишет:
> > On Mon, Aug 10, 2020 at 03:21:47AM +0300, Dmitry Osipenko wrote:
> >> 10.08.2020 01:30, Michał Mirosław пишет:
> >>> On Mon, Aug 10, 2020 at 12:40:04A
On Mon, Aug 10, 2020 at 01:37:47PM +0100, Mark Brown wrote:
> On Sun, Aug 09, 2020 at 10:44:25PM +0300, Dmitry Osipenko wrote:
> > 09.08.2020 22:21, Michał Mirosław пишет:
> > > The code allocates sizeof(regulator_dev) for a pointer. Make it less
> > > generous. Let k
On Mon, Aug 10, 2020 at 06:33:37PM +0100, Mark Brown wrote:
> On Mon, Aug 10, 2020 at 06:25:56PM +0200, Michał Mirosław wrote:
> > On Mon, Aug 10, 2020 at 01:37:47PM +0100, Mark Brown wrote:
> > > Yeah, this is more a performance improvement than a fix.
> > Should I r
On Mon, Aug 10, 2020 at 06:31:36PM +0100, Mark Brown wrote:
> On Mon, Aug 10, 2020 at 06:09:36PM +0200, Michał Mirosław wrote:
> > On Mon, Aug 10, 2020 at 04:39:28PM +0100, Mark Brown wrote:
> > > On Mon, Aug 10, 2020 at 12:25:37AM +0200, Michał Mirosław wrote:
> > >
9c8/0x163c
[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> &sit_i->sentry_lock --> &dcc->cmd_lock
[...]
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Michał Miro
s context]
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
[this is when the regulator_list_mutex was introduced in reclaim locking path]
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 19 ++-
1 file changed, 14 insertions(+),
, at: __fs_reclaim_acquire+0x0/0x50
[...]
Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling
customization")
Signed-off-by: Michał Mirosław
---
drivers/regulator/core.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --
l 10GE MII
> * @PHY_INTERFACE_MODE_10GKR: 10GBASE-KR - with Clause 73 AN
> + * @PHY_INTERFACE_MODE_100BASEX: 100 BaseX
> * @PHY_INTERFACE_MODE_MAX: Book keeping
[...]
This is kernel-internal interface, so maybe the new mode can be
inserted before 1000baseX for easier lookup?
Best Regards
Michał Mirosław
Add information found in downstream kernels, to make the code less
magic.
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
---
drivers/input/touchscreen/elants_i2c.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a
uses for reporting touches.
The calibration replies are handled separately from the the rest of the
commands in the driver by entering into ELAN_WAIT_RECALIBRATION state
and thus this change shouldn't change the old behavior.
Signed-off-by: Dmitry Osipenko
Tested-by: Michał Mirosław
Sig
EKTF3624 as present in Asus TF300T tablet has touchscreen size encoded
in different registers.
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
---
drivers/input/touchscreen/elants_i2c.c | 84 --
1 file changed, 79 insertions(+), 5
Support ELAN touchpad sensor with older firmware as found on eg. Asus
Transformer Pads.
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
---
drivers/input/touchscreen/elants_i2c.c | 36 ++
1 file changed, 25 insertions(+), 11
remove yet unused constants from patch 1
added a new drive-by cleanup (last patch)
v7: rebased onto current dtor/input/for-next
v8: rebased onto current dtor/input/for-linus
v8-resend: rebased again, no changes though
---
Dmitry Osipenko (1):
input: elants: support 0x66 reply opcode for re
On Thu, Dec 10, 2020 at 11:29:40PM -0800, Dmitry Torokhov wrote:
> Hi Michał,
> On Fri, Dec 11, 2020 at 07:53:56AM +0100, Michał Mirosław wrote:
> > @@ -998,17 +1011,18 @@ static irqreturn_t elants_i2c_irq(int irq, void
> > *_dev)
> > }
> >
>
On Thu, Dec 10, 2020 at 11:22:09PM -0800, Dmitry Torokhov wrote:
> Hi Michał,
>
> On Fri, Dec 11, 2020 at 07:53:56AM +0100, Michał Mirosław wrote:
> > +
> > + if (!phy_x || !phy_y) {
> > + dev_warn(&client->dev,
> > +
On Fri, Dec 11, 2020 at 07:39:33PM +0300, Dmitry Osipenko wrote:
> 11.12.2020 19:09, Michał Mirosław пишет:
> > On Thu, Dec 10, 2020 at 11:29:40PM -0800, Dmitry Torokhov wrote:
> >> Hi Michał,
> >> On Fri, Dec 11, 2020 at 07:53:56AM +0100, Michał Mirosław wrote:
> >
On Fri, Mar 05, 2021 at 12:45:51AM +0300, Dmitry Osipenko wrote:
> 04.03.2021 02:08, Michał Mirosław пишет:
> > On Tue, Mar 02, 2021 at 03:44:44PM +0300, Dmitry Osipenko wrote:
> >> Display controller (DC) performs isochronous memory transfers, and thus,
> >> has a requi
t; +
> + tegra_state->peak_memory_bandwidth = peak_bandwidth;
> + tegra_state->avg_memory_bandwidth = avg_bandwidth;
> +
> + return 0;
> +}
[...]
> +static const char * const tegra_plane_icc_names[] = {
> + "wina", "winb", "winc", "", "", "", "cursor",
> +};
> +
> +int tegra_plane_interconnect_init(struct tegra_plane *plane)
> +{
> + const char *icc_name = tegra_plane_icc_names[plane->index];
Is plane->index guaranteed to be <= 6? I would guess so, but maybe
BUILD_BUG_ON(sizeof(icc_names)==TEGRA_DC_LEGACY_PLANES_NUM) or some
other check could document this?
[...]
Best Regards
Michał Mirosław
> This file is concatenation of two files with two include guards.
> Convert it manually.
>
> Signed-off-by: Alexey Dobriyan
Acked-by: Michał Mirosław
off-by: Dmitry Osipenko
> ---
Rewieved-by: Michał Mirosław
> Please note that ASUS TF700T isn't yet supported by upstream kernel,
> hence this is not a critical fix.
>
> drivers/input/touchscreen/elants_i2c.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(
l avoid the
> - * peripheral access after disabling clock
> + * Some clocks are duplicated and some of them are marked as critical,
> + * like fuse and fuse_burn for example, thus the enable_refcnt will
> + * be non-zero here id the "unused" duplicate is disabled by CCF.
s/id/if/ ?
Best Regards
Michał Mirosław
without_filters = false,
> + .has_win_b_vfilter_mem_client = false,
> .has_win_c_without_vert_filter = false,
> + .plane_tiled_memory_bandwidth_x2 = true,
> };
>
> static const struct tegra_dc_soc_info tegra124_dc_soc_info = {
> @@ -2314,7 +2660,9 @@ static const struct tegra_dc_soc_info
> tegra124_dc_soc_info = {
> .overlay_formats = tegra124_overlay_formats,
> .modifiers = tegra124_modifiers,
> .has_win_a_without_filters = false,
> + .has_win_b_vfilter_mem_client = false,
> .has_win_c_without_vert_filter = false,
> + .plane_tiled_memory_bandwidth_x2 = false,
> };
>
> static const struct tegra_dc_soc_info tegra210_dc_soc_info = {
> @@ -2333,7 +2681,9 @@ static const struct tegra_dc_soc_info
> tegra210_dc_soc_info = {
> .overlay_formats = tegra114_overlay_formats,
> .modifiers = tegra124_modifiers,
> .has_win_a_without_filters = false,
> + .has_win_b_vfilter_mem_client = false,
> .has_win_c_without_vert_filter = false,
> + .plane_tiled_memory_bandwidth_x2 = false,
> };
>
> static const struct tegra_windowgroup_soc tegra186_dc_wgrps[] = {
> @@ -2382,6 +2732,7 @@ static const struct tegra_dc_soc_info
> tegra186_dc_soc_info = {
> .has_nvdisplay = true,
> .wgrps = tegra186_dc_wgrps,
> .num_wgrps = ARRAY_SIZE(tegra186_dc_wgrps),
> + .plane_tiled_memory_bandwidth_x2 = false,
> };
>
> static const struct tegra_windowgroup_soc tegra194_dc_wgrps[] = {
> @@ -2430,6 +2781,7 @@ static const struct tegra_dc_soc_info
> tegra194_dc_soc_info = {
> .has_nvdisplay = true,
> .wgrps = tegra194_dc_wgrps,
> .num_wgrps = ARRAY_SIZE(tegra194_dc_wgrps),
> + .plane_tiled_memory_bandwidth_x2 = false,
> };
For globals you will have .x = false by default; I'm not sure those entries
add much value.
Reviewed-by: Michał Mirosław
On Wed, Nov 25, 2020 at 04:48:05AM +0100, Sebastian Krzyszkowiak wrote:
> I've checked bq25890, bq25892, bq25895 and bq25896 datasheets and
> they all define IILIM to be between 100mA-3.25A with 50mA steps.
That's what DS says, indeed.
Reviewed-by: Michał Mirosław
put, struct zstd_in_buffer *input)
> +{
> + ZSTD_outBuffer o;
> + ZSTD_inBuffer i;
> + size_t ret;
> +
> + memcpy(&o, output, sizeof(o));
> + memcpy(&i, input, sizeof(i));
> + ret = ZSTD_compressStream(cstream, &o, &i);
> + memcpy(output, &o, sizeof(o));
> + memcpy(input, &i, sizeof(i));
> + return ret;
> +}
Is all this copying necessary? How is it different from type-punning by
direct pointer cast?
Best Regards
Michał Mirosław
On Thu, Dec 03, 2020 at 01:42:03AM +, Nick Terrell wrote:
>
>
> > On Dec 2, 2020, at 5:16 PM, Michał Mirosław wrote:
> >
> > On Wed, Dec 02, 2020 at 12:32:40PM -0800, Nick Terrell wrote:
> >> From: Nick Terrell
> >>
> >> This patch:
>
On Thu, Dec 03, 2020 at 03:59:21AM +, Nick Terrell wrote:
> On Dec 2, 2020, at 7:14 PM, Michał Mirosław wrote:
> > On Thu, Dec 03, 2020 at 01:42:03AM +, Nick Terrell wrote:
> >> On Dec 2, 2020, at 5:16 PM, Michał Mirosław
> >> wrote:
> >>> On Wed,
reset.
[...]
Looks good. It seems independent from the other patch.
Reviewed-by: Michał Mirosław
mul = 1;
[...]
One point is unexplained yet: why is the multiplier proportional to a
*difference* between src and dst widths? Also, I would expect max (worst
case) is pixclock * read_size when src_w/dst_w >= read_size.
BTW, you could move this below and : if (src > dst_w) peak_bandwidth *= ...
> + /* average bandwidth in bytes/s */
> + avg_bandwidth = (bpp * src_w * src_h * mul + 7) / 8;
> + avg_bandwidth *= drm_mode_vrefresh(&crtc_state->mode);
> +
> + /* mode.clock in kHz, peak bandwidth in kbit/s */
> + peak_bandwidth = crtc_state->mode.clock * bpp * mul;
[...]
Best Regards
Michał Mirosław
On Fri, Jan 22, 2021 at 11:10:52PM +0300, Dmitry Osipenko wrote:
> 08.01.2021 01:06, Dmitry Osipenko пишет:
> > 11.12.2020 21:48, Dmitry Torokhov пишет:
> >> On Fri, Dec 11, 2020 at 06:04:01PM +0100, Michał Mirosław wrote:
> >>> On Fri, Dec 11, 2020 at 07:39:33P
work in the kernel.
> [0]
> https://github.com/terrelln/linux/commit/ac2ee65dcb7318afe426ad08f6a844faf3aebb41
I looks like you could remove a bit more dead code by noting __GNUC__ >= 4
(gcc-4.9 is currently the oldest supported [1]).
[1] Documentation/process/changes.rst
Best Regards
Michał Mirosław
On Sun, Nov 22, 2020 at 03:43:33PM +0100, Jan Kiszka wrote:
> On 09.11.20 00:28, Qu Wenruo wrote:
> > On 2020/11/9 上午1:18, Michał Mirosław wrote:
> >> On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
[...]
> >>> It turns out that, commit aea6cb99703e (&q
you could move cb710_mmc_suspend() (or whatever you'll call it) to one
ifdef block with cb710_mmc_dev_pm_ops.
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo in
1 - 100 of 331 matches
Mail list logo
