On Sun, Sep 06, 2020 at 01:36:20AM +0300, Dmitry Osipenko wrote:
> 06.09.2020 01:23, Michał Mirosław пишет:
> > On Sat, Sep 05, 2020 at 11:41:36PM +0300, Dmitry Osipenko wrote:
> >> The "dma" variable of tegra_i2c_xfer_msg() function doesn't bring much in
> >>
static int tegra_i2c_fill_tx_fifo(struct tegra_i2c_dev
> *i2c_dev)
> }
Those first letters don't look consistently capitalized. :-)
Best Regards,
Michał Mirosław
es/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
[...]
> + if (i2c_dev->is_curr_dma_xfer) {
[...]
In this case I like the previous code better: just because there are
less letters to read. :-)
Best Regards,
Michał Mirosław
e doesn't improve the code for me. The problems are: 1) putting two
unrelated parts in one function, 2) silently reordered initialization.
Best Regards,
Michał Mirosław
2c_dev->nclocks = err
[...]
You loose checking whether number of clocks matches the device version.
Is this intended?
Best Regards,
Michał Mirosław
On Thu, Sep 03, 2020 at 04:12:13AM +0300, Dmitry Osipenko wrote:
> 03.09.2020 00:20, Michał Mirosław пишет:
> > BTW, I wonder if you could expose i2c_in_atomic_xfer_mode() and use it
> > to differentiate atomic_xfer from normal and get rid of the internal
> > flag and .master
tristate "MOXART SD/MMC Host Controller support"
> - depends on ARCH_MOXART && MMC
> + depends on MMC
> + depends on ARCH_MOXART || COMPILE_TEST
[...]
You can drop 'MMC' from depends as the whole tree is under 'if MMC' already.
Best Regards,
Michał Mirosław
fer_msg()
For all, but #3 and #9:
Reviewed-by: Michał Mirosław
BTW, I wonder if you could expose i2c_in_atomic_xfer_mode() and use it
to differentiate atomic_xfer from normal and get rid of the internal
flag and .master_xfer_atomic callback.
Best Regards,
Michał Mirosław
, as it seems to require massive code motion.
For eg. runtime PM setup/disable or interrupt setup, I would actually suggest
to drop the parts as they make the code harder to follow (you have
a function doing nothing but calling another one).
Best Regards,
Michał Mirosław
> return 0;
[...]
DMA is an acronym and so I would usually write it in uppercase for grammatical
correctness unless in a function's name.
Best Regards,
Michał Mirosław
On Fri, Aug 28, 2020 at 11:22:25AM -0700, Tom Rix wrote:
>
> On 8/28/20 9:14 AM, Michał Mirosław wrote:
> > dev_err_probe() prepends the message with an error code. Let's make it
> > more readable by translating the code to a more recognisable symbol.
> recognizable
> &
dev_err_probe() prepends the message with an error code. Let's make it
more readable by translating the code to a more recognisable symbol.
Fixes: a787e5400a1c ("driver core: add device probe log helper")
Signed-off-by: Michał Mirosław
---
drivers/base/core.c | 4 ++--
1 file
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;
0x163c
[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> _i->sentry_lock --> >cmd_lock
[...]
Cc: sta...@vger.kernel.org
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Michał Mirosław
-
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
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(+),
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
,
but 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
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")
---
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 insertions(+), 2 deletions(-)
di
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
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!
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
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(+),
,
but 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
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
0x163c
[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> _i->sentry_lock --> >cmd_lock
[...]
Cc: sta...@vger.kernel.org
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Michał Mirosław
-
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
--
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(-)
diff --git a/drivers/regulato
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 changed, 4
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
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
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
> > (followi
m_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 --git a/drivers/regulator/core.c b/dr
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(+),
0x163c
[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> _i->sentry_lock --> >cmd_lock
[...]
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Michał Mirosław
---
d
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:
> > >
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 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 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 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
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
d 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/drivers/reg
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/regulator/da9063
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 locking around
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
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,
> >
ay 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 thoughts?
Best Rega
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
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
--
ine
Hi,
Maybe you could split the meaning of --subjective and --strict, and
enable those checks only for --subjective? The test is really hard to do
right: you would have to consider the context and not only mere occurrence
of a word (heh, I even wrote 'blacklisted' here, since it really is about
a night/danger analogy and not political/ethical one).
Best Regards,
Michał Mirosław
introductions I expect to be actually rare) and not about
existing use in the code or industry. Making a noise about all uses
found surely will generate a lot more irrelevant patches.
[1] https://www.spinics.net/lists/linux-tegra/msg51849.html
Best Regards
Michał Mirosław
s *quirks;
> bool supports_bus_clear;
> bool has_reg_write_buffering;
> + bool has_hs_mode_support;
This field seems redundant: == !clk_multiplier_hs_mode ?
Best Regards,
Michał Mirosław
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
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
Signed-off
Replace open-coded __set_bit() with the function.
Signed-off-by: Michał Mirosław
---
drivers/input/input-mt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c
index a81e14148407..f699538bdac4 100644
--- a/drivers/input/input
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
om patch 1
added a new drive-by cleanup (last patch)
---
Dmitry Osipenko (1):
input: elants: support 0x66 reply opcode for reporting touches
Michał Mirosław (4):
input: elants: document some registers and values
input: elants: support old touch report format
input: elants: r
Add information found in downstream kernels, to make the code less
magic. Fix comment spelling along the way.
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
Two trivial fixes and .pullup implementation for Atmel UDC driver to
make composite gadget happy when handling reconfiguration.
Michał Mirosław (3):
usb: gadget: udc: atmel: remove outdated comment in usba_ep_disable()
usb: gadget: udc: atmel: fix uninitialized read in debug printk
usb
Implement udc->pullup callback, so that udc_connect/disconnect work.
This is needed for composite gadget, as it assumes udc_disconnect()
actually works and calls its ->disconnect callback.
Signed-off-by: Michał Mirosław
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 20 +
Fixed commit moved the assignment of 'req', but did not update a
reference in the DBG() call. Use the argument as it was renamed.
Fixes: 5fb694f96e7c ("usb: gadget: udc: atmel: fix possible oops when unloading
module")
Signed-off-by: Michał Mirosław
---
drivers/usb/gadget/udc/atmel_
Fixed commit removed the offending behaviour from the driver, but missed
the comment and associated test. Remove them now.
Fixes: 38e58986e6fc ("usb: gadget: udc: atmel: don't disable enpdoints we don't
own")
Signed-off-by: Michał Mirosław
---
drivers/usb/gadget/udc/atmel_usba
sc/cb710/sgbuf2.c:131: warning: Function parameter or member
> 'data' not described in 'cb710_sg_dwiter_write_next_block'
[...]
Acked-by: Michał Mirosław
all CPUs.
> +
> + Optional for NVIDIA Tegra194 Carmel CPUs
Hi,
The code (next patches) suggests, that the property is relevant for Tegra194
only. If it is required for compatible=tegra194-ccplex, then maybe you can
mark it so (there is already similar constraint described in the file, just
before the example section).
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
Fixes: 099343c64e16 ("ARM: at91: atmel-ssc: add device tree support")
Signed-off-by: Micha
Dear Developers,
I found a lockdep warning in dmesg some after doing 'mdadm -S' while
also having btrfs mounted (light to none I/O load). Disks under MD and
btrfs are unrelated.
Best Regards,
Michał Mirosław
==
WARNING: possible circular
usleep_range(1000, 1100);
> +
> + mutex_lock(>input->mutex);
> }
Missed an mutex_unlock() here.
>
> writel(0, ADC_V1_CLRINTPNDNUP(info->regs));
Best Regards,
Michał Mirosław
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: sta...@vger.kernel.org
Fixes: 0888c321de70 ("pcm_native: switch to fdget()/fdput()")
Signed-off-by: Michał Mirosł
snd_pcm]
#1: 8883f7a8cf18 (>lock){-...}-{2:2}, at:
snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]
[...]
Cc: sta...@vger.kernel.org
Fixes: f57f3df03a8e ("ALSA: pcm: More fine-grained PCM link locking")
Signed-off-by: Michał Mirosław
---
sound/core/pcm_native.c | 14 +
Two patches fixing locking issues for SNDRV_PCM_IOCTL_LINK handling:
first adds a check preventing linking a stream to itself, second quiets
lockdep warning about nested locks.
Michał Mirosław (2):
ALSA: pcm: disallow linking stream to itself
ALSA: pcm: fix snd_pcm_link() lockdep splat
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: sta...@vger.kernel.org
Fixes: 0888c321de70 ("pcm_native: switch to fdget()/fdput()")
Signed-off-by: Micha
_enabled(info->input);
> + mutex_unlock(>input->mutex);
> }
The mutex doesn't really protect anything here, but I would nevertheless
suggest this sequence instead:
lock()
while (test) {
unlock()
...
lock()
}
unlock()
Best Regards,
Michał Mirosław
> 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
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
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
On Fri, May 29, 2020 at 08:10:40AM +, Peter Chen wrote:
> On 20-05-28 20:30:28, Michał Mirosław wrote:
> > Make debugging real problems easier by not trying to disable an EP that
> > was not yet enabled.
> >
> > Fixes: 4aab757ca44a ("usb: gadget: f_acm: elimina
Fixed commit moved the assignment of 'req', but did not update a
reference in the DBG() call. Use the argument as it was renamed.
Fixes: 5fb694f96e7c ("usb: gadget: udc: atmel: fix possible oops when unloading
module")
Signed-off-by: Michał Mirosław
---
drivers/usb/gadget/udc/atmel_
Implement udc->pullup callback, so that udc_connect/disconnect work.
This is needed for composite gadget, as it assumes udc_disconnect()
actually works and calls gadget's ->disconnect callback.
Signed-off-by: Michał Mirosław
---
drivers/usb/gadget/udc/atmel_usba_udc.
Fixed commit removed the offending behaviour from the driver, but missed
the comment and associated test. Remove them now.
Fixes: 38e58986e6fc ("usb: gadget: udc: atmel: don't disable enpdoints we don't
own")
Signed-off-by: Michał Mirosław
---
drivers/usb/gadget/udc/atmel_usba
Two trivial fixes and .pullup implementation for Atmel UDC driver to
make composite gadget happy when handling reconfiguration.
Michał Mirosław (3):
usb: gadget: udc: atmel: remove outdated comment in usba_ep_disable()
usb: gadget: udc: atmel: fix uninitialized read in debug printk
usb
Make debugging real problems easier by not trying to disable an EP that
was not yet enabled.
Fixes: 4aab757ca44a ("usb: gadget: f_acm: eliminate abuse of ep->driver data")
Signed-off-by: Michał Mirosław
---
drivers/usb/gadget/function/f_acm.c | 8 +---
1 file changed, 5 ins
can remove it?
I would also include your observations about the chip's behaviour in the
commit message so it doesn't get "fixed" later.
Best Regards,
Michał Mirosław
_fromio(spare_bct, bct_ptr, bct_size);
> + bin_attr_boot_config_table.size = bct_size;
[...]
The size isn't checked anywhere. How the maximum is obtained? At least
a comment would be good if the 8k limit is guaranteed by other means.
Best Regards,
Michał Mirosław
timings to another
dtsi file?
BTW, shouldn't EMC timing set match MC? I see more frequencies listed in
MC than EMC nodes.
Best Regards,
Michał Mirosław
set_bits(tps65910, TPS65910_DEVCTRL,
> + DEVCTRL_DEV_OFF_MASK);
> }
Isn't it enough to update the DEVCTRL with just one
tps65910_reg_update_bits()?
Best Regards
Michał Mirosław
unsignedslot_mask;
> unsignedslots;
> spinlock_t irq_lock;
> - struct cb710_slot slot[0];
> + struct cb710_slot slot[];
> };
>
> /* NOTE: cb710_chip.slots is modified only during device init/exit and
>
Acked-by: Michał Mirosław
On Tue, May 05, 2020 at 06:47:39PM +0200, Michał Mirosław wrote:
> On Tue, May 05, 2020 at 05:52:28PM +0200, Wolfram Sang wrote:
[...]
> > > BTW, I found this comment in i2c-core.h:
> > >
> > > * We only allow atomic transfers for very late comm
ke normal atomic context. Do you plan to have it work in other
contexts? What are the idea and use cases for atomic-context transfers?
I guess we might want it for suspend/resume, but I think there is an
early stage (with all non-atomic stuff working) and NOIRQ stage (when
most everything is already shutdown). When a PMIC needs a read, I would
actually do it ("prepare" the PMIC) in the early stage if possible.
Best Regards,
Michał Mirosław
On Tue, May 05, 2020 at 02:37:45PM +0200, Jerome Pouiller wrote:
> From: Jérôme Pouiller
>
> In case of error in wfx_probe(), wdev->hw is freed. Since an error
> occurred, wfx_free_common() is called, then wdev->hw is freed again.
>
> Cc: Michał Mirosław
> Sig
more DTSI pieces, which combined together form the final device-tree.
> Thanks to Zack Pearsall for testing the Ti version!
[...]
Hi Dmitry!
This Ti-based (PM269) version might be very similar to Asus TF300T I have.
I'll have a look on your DT during the weekend.
Best Regards,
Michał Mirosław
This exposes PROGx clocks for use in assigned-clocks DeviceTree property
for selecting PCKx parent clock.
Signed-off-by: Michał Mirosław
---
v2: rebase and update to clk/clk-at91 branch
v3: rebase
v4: no changes
v5: no changes
v6: no changes
v7: push all pmc_data_free() to first patch (fix
Alloc whole data structure in one block. This makes the code shorter,
more efficient and easier to extend in following patch.
Signed-off-by: Michał Mirosław
---
v2: rebase and update to clk/clk-at91 branch
v3: use struct_size() and C99 trailing array
as suggested by Stephen Boyd
v4: fixed
We need to have clocks accessible via phandle to select them
as peripheral clock parent using assigned-clock-parents in DT.
Add support for PLLACK/PLLBCK/AUDIOPLLCK clocks where available.
Signed-off-by: Michał Mirosław
Acked-by: Alexandre Belloni
---
v2: rebase to clk/clk-at91 branch
v3
This series extends AT91 clock support with references to PCKx and
PLLA/PLLB/AUDIOPLL. This makes the DT be able to fully specify (assign)
clock parents when needed.
First patch simplifies clock table allocation. Next two update the table
with missing clock pointers and IDs.
Michał Mirosław (3
On Mon, May 04, 2020 at 10:44:47PM +0200, Alexandre Belloni wrote:
> On 04/05/2020 22:19:17+0200, Michał Mirosław wrote:
> > This exposes PROGx clocks for use in assigned-clocks DeviceTree property
> > for selecting PCKx parent clock.
> >
> > Signed-off-by:
This series extends AT91 clock support with references to PCKx and
PLLA/PLLB/AUDIOPLL. This makes the DT be able to fully specify (assign)
clock parents when needed.
First patch simplifies clock table allocation. Next two update the table
with missing clock pointers and IDs.
Michał Mirosław (3
Alloc whole data structure in one block. This makes the code shorter,
more efficient and easier to extend in following patch.
Signed-off-by: Michał Mirosław
Acked-by: Alexandre Belloni
---
v2: rebase and update to clk/clk-at91 branch
v3: use struct_size() and C99 trailing array
as suggested
This exposes PROGx clocks for use in assigned-clocks DeviceTree property
for selecting PCKx parent clock.
Signed-off-by: Michał Mirosław
Acked-by: Alexandre Belloni
---
v2: rebase and update to clk/clk-at91 branch
v3: rebase
v4: no changes
v5: no changes
v6: no changes
---
drivers/clk/at91
101 - 200 of 384 matches
Mail list logo
