On 03.06.2013 10:03, Tommi Rantala wrote:
Hello,
Hit this while fuzzing v3.10-rc4-0-gd683b96 with trinity.
Looks similar to what I reported back in March:
https://lkml.org/lkml/2013/3/13/222
Tommi
[42279.088045] general protection fault: [#1] SMP DEBUG_PAGEALLOC
[42279.091904] CPU: 1 PID
.
Signed-off-by: Lino Sanfilippo
---
fs/notify/fanotify/fanotify_user.c | 49 +++-
1 file changed, 37 insertions(+), 12 deletions(-)
diff --git a/fs/notify/fanotify/fanotify_user.c
b/fs/notify/fanotify/fanotify_user.c
index 5d84442..213f0a1 100644
--- a/fs/notify
Hi,
this patch series fixes a couple of races (fanotify/inotify) or simplifies code
(dnotify) by means of the fsnotify groups mark mutex. The last patch updates the
comments in fs/notify/mark.c concerning the changed fsnotify locking
implementation.
Regards,
Lino
[PATCH 1/5] fanotify: Fix races
The code under the groups mark_mutex in fanotify_add_inode_mark() and
fanotify_add_vfsmount_mark() is almost identical. So put it into a seperate
function.
Signed-off-by: Lino Sanfilippo
---
fs/notify/fanotify/fanotify_user.c | 71 ++--
1 file changed, 35
this is also synchronized by the groups mark mutex now.
Signed-off-by: Lino Sanfilippo
---
fs/notify/inotify/inotify_user.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index e0f7c12..14d7786
There has been changes in the locking scheme of fsnotify but the comments in the
source code have not been updated yet. This patch corrects this.
Signed-off-by: Lino Sanfilippo
---
fs/notify/mark.c | 50 ++
1 file changed, 22 insertions(+), 28
There is no need to use a special mutex to protect against the fcntl/close race
(see dnotify.c for a description of this race). Instead the dnotify_groups mark
mutex can be used.
Signed-off-by: Lino Sanfilippo
---
fs/notify/dnotify/dnotify.c | 25 +
1 file changed, 13
On 22.07.2013 08:53, Dan Carpenter wrote:
My static checker complains that if we drop the last reference then it
would be a use after free. I don't know if it's possible, but really
the atomic_dec(&group->num_marks); should be done while we are holding a
reference to "group".
Signed-off-by: Dan
Hi Krzysztof,
>
> Not really: there is one pool for all ports, but each port uses
> a separate desc_tab (allocated from that pool).
right, but even then using a dma pool seems to be a bit of overhead
for only a few allocations. As far as I understood those pools are
meant for hundrets or thousa
Hi,
this patch series tries to get the slicoss driver code closer to a state in
which it is ready to be moved out of staging.
Patch 1 is a resend of patch I sent a week ago and handles an allocation
failure in slic_init_adapter().
Patch 2 fixes link state notification.
Patch 3 turns the mapping
From: Lino Sanfilippo
Writes to registers should be done uncached for various reasons. Ensure
this by replacing ioremap() with ioremap_nocache().
Signed-off-by: Lino Sanfilippo
---
drivers/staging/slicoss/slicoss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
Introduce the function slic_flush_write() which reads from the HOSTID
register and can be used to avoid PCI write posting. Use the function at
several critical places in the code.
Signed-off-by: Lino Sanfilippo
---
drivers/staging/slicoss/slic.h| 5 +
drivers/staging/slicoss/slicoss.c
There is no reason to delay tx queue activation until a link is detected.
So start the queue when the interface is brought up and stop it when the
interface is brought down.
Signed-off-by: Lino Sanfilippo
---
drivers/staging/slicoss/slicoss.c | 5 +++--
1 file changed, 3 insertions(+), 2
Notify the network stack about link states via netif_carrier_[off|on]().
Also set the link state off initially and when the interface is brought
down.
Signed-off-by: Lino Sanfilippo
---
drivers/staging/slicoss/slicoss.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/staging
a zalloc() version.
Signed-off-by: Lino Sanfilippo
---
drivers/staging/slicoss/slicoss.c | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index ac126d4..dae07410
Use the new register accessors that use offsets instead of the slic_regs
structure to read/write registers. Since not longer needed remove the
structure completley.
Signed-off-by: Lino Sanfilippo
---
drivers/staging/slicoss/slic.h| 1 -
drivers/staging/slicoss/slichw.h | 219
-off-by: Lino Sanfilippo
---
drivers/staging/slicoss/slic.h| 18 ++-
drivers/staging/slicoss/slicoss.c | 267 ++
2 files changed, 136 insertions(+), 149 deletions(-)
diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index 3bba82a
Introduce accessor functions that read and write registers by using a
register offset.
This is in preparation to replace the register addressing by means of the
slic_regs struct with an addressing by means of offsets.
Signed-off-by: Lino Sanfilippo
---
drivers/staging/slicoss/slic.h| 24
Merge several structures for statistics to one structure and remove
unnecessary union nesting.
Signed-off-by: Lino Sanfilippo
---
drivers/staging/slicoss/slic.h| 18 +
drivers/staging/slicoss/slichw.h | 79 ---
drivers/staging/slicoss/slicoss.c
> Gesendet: Dienstag, 26. Juli 2016 um 08:25 Uhr
> Von: "SF Markus Elfring"
>
> >> - if (strncasecmp(buff, "RSSI", length) == 0) {
> >> + if (strncasecmp(buff, "RSSI", 0) == 0) {
> >> + s8 rssi;
> >> +
> >
> > Um, please think a second
-355,7 +355,7 @@ static void slic_xmit_complete(struct slic_device *sdev)
> {
> struct slic_tx_queue *txq = &sdev->txq;
> struct net_device *dev = sdev->netdev;
> - unsigned int idx = txq->done_idx;
> + unsigned int idx;
> struct slic_tx_buff
On 30.10.2017 19:04, Jakub Kicinski wrote:
> On Sun, 29 Oct 2017 13:38:09 +, Colin King wrote:
>> From: Colin Ian King
>>
>> Variable idx is being initialized and later on over-written by
>> a new value in a do-loop without the initial value ever being
>> read. Hence the initializion is redund
frames = 0;
> unsigned int bytes = 0;
> + unsigned int idx;
>
> /* Limit processing to SLIC_MAX_TX_COMPLETIONS frames to avoid that new
>* completions during processing keeps the loop running endlessly.
>
Acked-by: Lino Sanfilippo
Regards,
Lino
gt;
> Detected by CoverityScan, CID#1398313 and CID#1398306 ("Logically
> dead code")
>
> Signed-off-by: Colin Ian King
FWIW:
Reviewed-by: Lino Sanfilippo
Regards,
Lino
Hi,
On 10.05.2017 10:53, Stefan Wahren wrote:
> +static int qcauart_netdev_init(struct net_device *dev)
> +{
> + struct qcauart *qca = netdev_priv(dev);
> + size_t len;
> +
> + /* Finish setting up the device info. */
> + dev->mtu = QCAFRM_MAX_MTU;
> + dev->type = ARPHRD_ETHER
Hi,
On 12.02.21 at 11:59, Jarkko Sakkinen wrote:
>
> One *option*:
>
> 1. You take the Jason's patch.
> 2.
> https://www.kernel.org/doc/html/v5.10/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
>
> Just mentioning this, and spreading the knowledge about co-developed-
detailed
- add fixes tags and kernel logs
Lino Sanfilippo (1):
tpm: fix reference counting for struct tpm_chip
drivers/char/tpm/tpm-chip.c | 80 -
1 file changed, 50 insertions(+), 30 deletions(-)
--
2.7.4
From: Lino Sanfilippo
The following sequence of operations results in a refcount warning:
1. Open device /dev/tpmrm
2. Remove module tpm_tis_spi
3. Write a TPM command to the file descriptor opened at step 1.
[ cut here ]
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25
Hi,
On 16.02.21 at 13:53, Jason Gunthorpe wrote:
> On Tue, Feb 16, 2021 at 01:31:00AM +0100, Lino Sanfilippo wrote:
>>
>> +static int tpm_add_tpm2_char_device(struct tpm_chip *chip)
>> +{
>> +int rc;
>> +
>> +device_initialize(&chip->devs)
ue, Feb 16, 2021 at 01:31:00AM +0100, Lino Sanfilippo wrote:
>>>>>
>>>>> +static int tpm_add_tpm2_char_device(struct tpm_chip *chip)
>>>
>>> BTW, this naming is crap.
>>>
>>> - 2x tpm
>>> - char is useless
>>
Hi
On 16.02.21 at 17:04, Jarkko Sakkinen wrote:
>>> + /*
>>> +* get extra reference on main device to hold on behalf of devs.
>>> +* This holds the chip structure while cdevs is in use. The
>>> +* corresponding put is in the tpm_devs_release.
>>> +*/
>>> + get_device(&chip->de
Hi Stefan,
On 16.02.21 at 17:52, Stefan Berger wrote:
> On 2/15/21 7:31 PM, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo
>>
>> The following sequence of operations results in a refcount warning:
>>
>> 1. Open device /dev/tpmrm
>> 2. Remove module tpm_t
rkko Sakkinen)
- make the commit message for patch 1 more detailed
- add fixes tags and kernel logs
Lino Sanfilippo (1):
The following sequence of operations results in a refcount warning:
drivers/char/tpm/tpm-chip.c | 48 +--
drivers/char/tpm/tpm.
From: Lino Sanfilippo
1. Open device /dev/tpmrm.
2. Remove module tpm_tis_spi.
3. Write a TPM command to the file descriptor opened at step 1.
[ cut here ]
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4
refcount_t: addition on 0; use-after-free
Please ignore this patch, I somehow managed to cut off the head line.
I will resend it shorty.
Regards,
Lino
rkko Sakkinen)
- make the commit message for patch 1 more detailed
- add fixes tags and kernel logs
Lino Sanfilippo (1):
tpm: fix reference counting for struct tpm_chip
drivers/char/tpm/tpm-chip.c | 48 +--
drivers/char/tpm/tpm.h| 1 +
drivers/
From: Lino Sanfilippo
The following sequence of operations results in a refcount warning:
1. Open device /dev/tpmrm.
2. Remove module tpm_tis_spi.
3. Write a TPM command to the file descriptor opened at step 1.
[ cut here ]
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25
In fanotify_mark_remove_from_mask() a mark is destroyed if only one of both
bitmasks (mask or ignored_mask) of a mark is cleared. However the other mask
may still be set and contain information that should not be lost. So only
destroy a mark if both masks are cleared.
Signed-off-by: Lino
If removing bits from a marks ignored mask, the concerning inodes/vfsmounts
mask is not affected. So dont recalculate it.
Signed-off-by: Lino Sanfilippo
Reviewed-by: Jan Kara
---
fs/notify/fanotify/fanotify_user.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs
ent flag and
require FAN_MARK_ONDIR to be set by the user for both event mask and ignore
mask. Furthermore take FAN_MARK_ONDIR into account when set for event removal.
Signed-off-by: Lino Sanfilippo
Reviewed-by: Jan Kara
---
fs/notify/fanotify/fanotify.c | 2 +-
fs/notify/fanotify/
Hi,
On 20.03.2015 21:56, Fabian Frederick wrote:
> ltp/fanotify02 was locked since commit 66ba93c0d7fe
> ("fanotify: don't set FAN_ONDIR implicitly on a marks ignored mask")
>
> Signed-off-by: Fabian Frederick
> ---
> fs/notify/fanotify/fanotify.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
On 20.03.2015 22:09, Andrew Morton wrote:
> On Fri, 20 Mar 2015 21:56:08 +0100 Fabian Frederick wrote:
>
>> ltp/fanotify02 was locked since commit 66ba93c0d7fe
>> ("fanotify: don't set FAN_ONDIR implicitly on a marks ignored mask")
>
> What does "ltp/fanotify02 was locked" mean? That this parti
On 21.03.2015 02:01, Lino Sanfilippo wrote:
>> Should that be (marks_mask & FS_ISDIR & marks_ignored_mask)?
>>
>
> No, the current logic should be correct, since we want events for
> directories if we have FS_ISDIR set in the marks mask but not in its
> ignored_m
On 06.03.2015 19:20, Lino Sanfilippo wrote:
>
>>>
>>
>> Ok, I got a link to the source now. It can be found here:
>>
>> http://tp-lab200/release/gcc/temp/internal/2010q4-113-4.4.5/marvell-gcc.src-2010q4-113.tar.bz2
>>
>
>
> Sigh. Just reali
On 22.03.2015 10:46, Fabian Frederick wrote:
> Let's hope it only breaks ltp tests and no _real_ userland stuff
> (search systems ...)
>
> Regards,
> Fabian
>
Hi Fabian,
yes, that worries me too. I know that there have been discussions on
lkml in which it was made clear that userspace breakage
On 24.04.2015 19:42, Andrew Morton wrote:
> On Thu, 23 Apr 2015 14:25:38 +0800 Huang Ying wrote:
>
>> FYI, we noticed the below changes on
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> commit 66ba93c0d7fe63def447ad0afe380307ff9ebcad ("fanotify: don't set
>> FA
Hi,
> On Wednesday 28 February 2018 05:26 PM, Cornelia Huck wrote:
> > On Wed, 28 Feb 2018 17:14:55 +0530
> > Arvind Yadav wrote:
> >
> >> On Wednesday 28 February 2018 04:00 PM, Cornelia Huck wrote:
> >>> On Wed, 28 Feb 2018 15:24:16 +0530
> >>> Arvind Yadav wrote:
> >>>
> Free memory,
Hi,
On 17.02.21 at 23:18, Jarkko Sakkinen wrote:
>> +
>
> /*
> * Please describe what the heck the function does. No need for full on
> * kdoc.
> */
Ok.
>> +int tpm2_add_device(struct tpm_chip *chip)
>
> Please, rename as tpm_devs_add for coherency sake.
>
Sorry I confused this and rename
From: Lino Sanfilippo
The following sequence of operations results in a refcount warning:
1. Open device /dev/tpmrm.
2. Remove module tpm_tis_spi.
3. Write a TPM command to the file descriptor opened at step 1.
[ cut here ]
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25
t
Changes in v2:
- drop the patch that erroneously cleaned up after failed installation of
an action handler in tpmm_chip_alloc() (pointed out by Jarkko Sakkinen)
- make the commit message for patch 1 more detailed
- add fixes tags and kernel logs
Lino Sanfilippo (1):
tpm: fix reference counti
From: Lino Sanfilippo
In tpm2_del_space() the sessions are flushed by means of the tpm_chip
operations. However the concerning operations pointer my already be NULL at
this time in case that the chip has been unregistered (see
tpm_chip_unregister() which calls tpm_del_char_device() which sets
v2:
- drop the patch that erroneously cleaned up after failed installation of
an action handler ni tpmm_chip_alloc() (pointed out by Jarkko Sakkinen)
- make the commit message for patch 1 more detailed
- add fixes tags and kernel logs
Lino Sanfilippo (3):
tpm: fix reference counting for struct
From: Lino Sanfilippo
The following sequence of operations
1. open device /dev/tpmrm
2. remove the registered tpm chip driver
3. perform a write() to /dev/tpmrm
results in a refcount warning:
[ cut here ]
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0
From: Lino Sanfilippo
Provide a function tpm_chip_free() as a counterpart to tpm_chip_alloc().
The function hides the internals of freeing a struct tpm_chip instance
by putting the device references which are part of this structure.
Use the new function at the appropriate places.
Signed-off-by
Hi,
On 03.02.21 02:09, Jarkko Sakkinen wrote:
> On Tue, Feb 02, 2021 at 11:09:01PM +0100, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo
>>
>> The following sequence of operations
>>
>> 1. open device /dev/tpmrm
>> 2. remove the registered tpm chip driver
Hi
On 03.02.21 02:28, Jarkko Sakkinen wrote:
> On Tue, Feb 02, 2021 at 11:09:02PM +0100, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo
>>
>> Provide a function tpm_chip_free() as a counterpart to tpm_chip_alloc().
>> The function hides the internals of freeing a str
Hi,
On 03.02.21 02:17, Jarkko Sakkinen wrote:
> On Tue, Feb 02, 2021 at 11:09:03PM +0100, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo
>>
>> In tpm2_del_space() the sessions are flushed by means of the tpm_chip
>> operations. However the concerning operations po
cleaned up after failed installation of
an action handler in tpmm_chip_alloc() (pointed out by Jarkko Sakkinen)
- make the commit message for patch 1 more detailed
- add fixes tags and kernel logs
Lino Sanfilippo (2):
tpm: fix reference counting for struct tpm_chip
tpm: in tpm2_del_space check if
From: Lino Sanfilippo
In tpm2_del_space() chip->ops is used for flushing the sessions. However
this function may be called after tpm_chip_unregister() which sets
the chip->ops pointer to NULL.
Avoid a possible NULL pointer dereference by checking if chip->ops is still
valid before acc
From: Lino Sanfilippo
The following sequence of operations results in a refcount warning:
1. Open device /dev/tpmrm
2. Remove module tpm_tis_spi
3. Write a TPM command to the file descriptor opened at step 1.
[ cut here ]
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25
slightly better than it had been done previously.
I tested your patch and it fixes the issue. Your solution seems indeed much
cleaner.
FWIW:
Tested-by: Lino Sanfilippo
Best Regards,
Lino
Hi Stefan,
On 05.02.21 01:46, Stefan Berger wrote:
> On 2/4/21 6:50 PM, Lino Sanfilippo wrote:
>> Signed-off-by: Lino Sanfilippo
>
> Tested-by: Stefan Berger
>
> Steps:
>
> modprobe tpm_vtpm_proxy
>
> swtpm chardev --vtpm-proxy --tpm2 --tpmstate di
Hi,
On 05.02.21 03:01, James Bottomley wrote:
> On Thu, 2021-02-04 at 20:44 -0500, Stefan Berger wrote:
>> To clarify: When I tested this I had *both* patches applied. Without
>> the patches I got the null pointer exception in tpm2_del_space(). The
>> 2nd patch alone solves that issue when using t
On 05.02.21 16:15, Jason Gunthorpe wrote:
>
> No, the cdev layer holds the refcount on the device while open is
> being called.
>
> Jason
>
Yes, but the reference that is responsible for the chip deallocation is
chip->dev
which is linked to chip->cdev and represents /dev/tpm, not /dev/tpmrm.
Hi Jason,
On 05.02.21 18:25, Jason Gunthorpe wrote:
> On Fri, Feb 05, 2021 at 08:48:11AM -0800, James Bottomley wrote:
>>> Thanks for pointing this out. I'd strongly support Jason's proposal:
>>>
>>> https://lore.kernel.org/linux-integrity/20201215175624.gg5...@ziepe.ca/
>>>
>>> It's the best long
On 09.02.21 14:36, Jason Gunthorpe wrote:
>>> EXPORT_SYMBOL_GPL(tpm_chip_unregister);
>>>
>>
>> I tested the solution you scetched and it fixes the issue for me. Will you
>> send a (real) patch for this?
>
> No, feel free to bundle this up with any fixes needed and send it with
> a Signed-of
Hi Uwe,
> Gesendet: Donnerstag, 10. Dezember 2020 um 12:43 Uhr
> Von: "Uwe Kleine-König"
> An: "Lino Sanfilippo"
> Cc: thierry.red...@gmail.com, lee.jo...@linaro.org, nsaenzjulie...@suse.de,
> f.faine...@gmail.com, r...@broadcom.com, s...@mess.org,
> sbra
Hi,
On 07.12.20 at 14:52, Uwe Kleine-König wrote:
>
> Given that the bcm2835 driver is quite trivial I would be happy to
> create a series that "fixes" the driver to round down and provide a
> prototype for pwm_round_nearest for you to test on pwm-ir-tx. A willing
> tester and a real use-case wer
possible max value for the 32 bit register.
This has been tested on a Raspberry PI 4.
Signed-off-by: Lino Sanfilippo
---
v3: Check against period truncation (based on a review by Uwe Kleine-König)
v2: Fix compiler error for 64 bit builds
drivers/pwm/pwm-bcm2835.c | 72
Hi,
On 19.02.21 at 10:13, Jarkko Sakkinen wrote:
>> +rc = cdev_device_add(&chip->cdevs, &chip->devs);
>> +if (rc) {
>> +dev_err(&chip->devs,
>> +"unable to cdev_device_add() %s, major %d, minor %d,
>> err=%d\n",
>> +dev_name(&chip->de
etailed
- add fixes tags and kernel logs
Lino Sanfilippo (1):
tpm: fix reference counting for struct tpm_chip
drivers/char/tpm/tpm-chip.c | 48 -
drivers/char/tpm/tpm.h| 1 +
drivers/char/tpm/tpm2-space.c | 55 +
From: Lino Sanfilippo
The following sequence of operations results in a refcount warning:
1. Open device /dev/tpmrm.
2. Remove module tpm_tis_spi.
3. Write a TPM command to the file descriptor opened at step 1.
[ cut here ]
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25
Lino Sanfilippo (4):
tpm: Use a threaded interrupt handler
tpm: get locality before writing to TPM chip
tpm: Fix test for interrupts
tpm: Only enable supported irqs
drivers/char/tpm/tpm-chip.c | 10
drivers/char/tpm/tpm_tis_core.c | 127
driver startup
and only release it at driver shutdown.
Signed-off-by: Lino Sanfilippo
---
drivers/char/tpm/tpm-chip.c | 10 --
drivers/char/tpm/tpm_tis_core.c | 16 +---
2 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char
Do not set interrupts which are not supported by the hardware. Instead use
the information from the capability query and activate only the reported
interrupts.
Signed-off-by: Lino Sanfilippo
---
drivers/char/tpm/tpm_tis_core.c | 68 ++---
drivers/char/tpm
visibility between the
interrupt handler and threads.
Finally remove one function which is no longer needed.
Signed-off-by: Lino Sanfilippo
---
drivers/char/tpm/tpm_tis_core.c | 37 ++---
drivers/char/tpm/tpm_tis_core.h | 1 -
include/linux/tpm.h | 2
.
Signed-off-by: Lino Sanfilippo
---
drivers/char/tpm/tpm_tis_core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index 92c51c6..2c956a1 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm
Hi Uwe
> Hello Lino,
>
> On Tue, Dec 08, 2020 at 11:01:45PM +0100, Lino Sanfilippo wrote:
> > Use the newer .apply function of pwm_ops instead of .config, .enable,
> > .disable and .set_polarity. This guarantees atomic changes of the pwm
> > controller configuration.
possible max value for the 32 bit register.
This has been tested on a Raspberry PI 4.
Signed-off-by: Lino Sanfilippo
---
v4: Remove a superfluous blank line
Remove an unneeded cast (both requested by Uwe Kleine-König)
v3: Check against period truncation (also based on a review by Uwe)
v2: Fix
Hi Sean,
On 04.12.20 at 09:44, Sean Young wrote:
>> What about an extra check then to make sure that the period has not been
>> truncated,
>> e.g:
>>
>> value = DIV_ROUND_CLOSEST_ULL(state->period, scaler);
>>
>> /* dont accept a period that is too small or has been truncated */
>>
Hi,
On 04.12.20 at 12:21, Uwe Kleine-König wrote:
>
> I'd make value an unsigned long long and check for > 0x instead
> of repeating the (expensive) division. (Hmm, maybe the compiler is smart
> enough to not actually repeat it, but still.)
I also prefer unsigned long long over u64 sinc
Hi Uwe,
First off, thanks for the review!
On 29.11.20 at 19:10, Uwe Kleine-König wrote:
>
> Changelog between review rounds go to below the tripple-dash below.
>
Right, will do so in the next patch version.
>
> You're storing an unsigned long long (i.e. 64 bits) in an u32. If
> you are sure
ted your patch and it fixes the issue. Your solution seems indeed much
> cleaner.
>
> FWIW:
>
> Tested-by: Lino Sanfilippo
>
Are you going to send a patch for this? As stated above I verified that your
solution fixes the issue.
Best regards,
Lino
On 05.02.21 at 16:58, Jason Gunthorpe wrote:
eference in the first place).
>
> No, they are all chained together because they are all in the same
> struct:
>
> struct tpm_chip {
> struct device dev;
> struct device devs;
> struct cdev cdev;
> struct cdev cdevs;
>
> dev holds
Hi,
On 05.02.21 14:05, Jason Gunthorpe wrote:
>>
>> Commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm")
>> already introduced function tpm_devs_release() to release the extra
>> reference but did not implement the required put on chip->devs that results
>> in the call of this
From: Lino Sanfilippo
Provide a function tpm_chip_free() as a counterpart to tpm_chip_alloc().
The function hides the internals of freeing a struct tpm_chip instance
by putting the device references which are part of this structure.
Use the new function at the appropriate places.
Signed-off-by
tpm_chip_free() which is used as a counterpart to
tpm_chip_alloc(). The main reason for this function is to hide the
internals of tpm_chip cleanup by means of multiple reference count
handling.
Lino Sanfilippo (4):
tpm: in case of error properly cleanup in tpmm_chip_alloc
tpm: fix reference
From: Lino Sanfilippo
In tpmm_chip_alloc() a resource management action handler is installed to
release the chip->dev in case of error. This will result in the chip being
freed if it was the last reference. If the installation of the handler was
not successful an error is returned to the cal
From: Lino Sanfilippo
Commit 8979b02aaf1d ("tpm: Fix reference count to main device") tried to
fix a reference count issue which prevented the tpm_chip structure from
being freed in case that no TPM2 was used. The fix was to only get an extra
reference for chip->dev in case of
From: Lino Sanfilippo
In tpm2_del_space() the sessions are flushed by means of the tpm_chip
operations. However the concerning operations pointer my already be NULL at
this time in case that the chip has been unregistered (see
tpm_chip_unregister() which calls tpm_del_char_device() which sets
Hi Jarkko,
On 17.01.21 at 19:13, Jarkko Sakkinen wrote:
>
> I have hard time to believe that any of these patches are based on
> actual regressions.
>
> /Jarko
>
patch 1 is indeed wrong (I oversaw the action call in case of error),
so please ignore it.
However patches 2 and 3 are based on bugs
Hi,
On 26.01.21 16:29, Jarkko Sakkinen wrote:
> On Sun, 2021-01-24 at 17:47 +0100, Lino Sanfilippo wrote:
>> Hi Jarkko,
>>
>> On 17.01.21 at 19:13, Jarkko Sakkinen wrote:
>>> I have hard time to believe that any of these patches are based on
>>> actual reg
Use the newer apply function of pwm_ops instead of config, enable, disable
and set_polarity.
This guarantees atomic changes of the pwm controller configuration. It also
reduces the size of the driver.
This has been tested on a Raspberry PI 4.
Signed-off-by: Lino Sanfilippo
---
drivers/pwm/pwm
Hi Jonathan,
On 28.11.20 at 14:54, Jonathan Cameron wrote:
> A few notes to make it harder for people to do that in future.
> 1. Don't send patch series (or new versions of older patches) in reply
>to an existing thread. They get lost and difficult to pull out.
>b4 can't automatically f
Use the newer apply function of pwm_ops instead of config, enable, disable
and set_polarity.
This guarantees atomic changes of the pwm controller configuration. It also
reduces the size of the driver.
This has been tested on a Raspberry PI 4.
v2: Fixed compiler error
Signed-off-by: Lino
Introduce an unlocked version of iio_map_array_unregister(). This function
can help to unwind in case of error while the iio_map_list_lock mutex is
held.
Signed-off-by: Lino Sanfilippo
Reviewed-by: Andy Shevchenko
---
drivers/iio/inkern.c | 27 ++-
1 file changed, 18
In function iio_map_array_register() properly rewind in case of error.
Signed-off-by: Lino Sanfilippo
Reviewed-by: Andy Shevchenko
---
drivers/iio/inkern.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 39c1d63..fe30bcb 100644
--- a
Hi Elad,
On 02.05.2016 12:21, Elad Kanfi wrote:
Since this driver handles one frame at a time, I couldn't find a case that
requires the paired barrier.
The order of reads is not critical once it is assured that the value is valid.
Please see sections "SMP BARRIER PAIRING" and "EXAMPLES OF
Hi Elad,
On 08.05.2016 15:44, Elad Kanfi wrote:
>
> After reviewing the code and your suggestion, it seems that we can do without
> the flag tx_packet_sent and therefor the first issue becomes irrelevant.
> The indication that a packet was sent is (tx_skb != NULL) , and the sequence
> will b
Hi,
On 27.04.2016 15:18, Elad Kanfi wrote:
From: Elad Kanfi
Below is a description of a possible problematic
sequence. CPU-A is sending a frame and CPU-B handles
the interrupt that indicates the frame was sent. CPU-B
reads an invalid value of tx_packet_sent.
CPU-A
1 - 100 of 225 matches
Mail list logo
