Re: [PATCH v3 2/2] tpm: in tpm2_del_space check if ops pointer is still valid

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

[PATCH 1/4] tpm: Use a threaded interrupt handler

. 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

[PATCH 3/4] tpm: Fix test for interrupts

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

[PATCH 2/4] tpm: get locality before writing to TPM chip

at 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

[PATCH 4/4] tpm: Only enable supported irqs

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

[PATCH 0/4] Fixes for TPM interrupt handling

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

[PATCH v7] tpm: fix reference counting for struct tpm_chip

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

[PATCH v7] TPM fixes

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 +

Re: [PATCH v6] tpm: fix reference counting for struct tpm_chip

Hi, On 19.02.21 at 10:13, Jarkko Sakkinen wrote: >> +rc = cdev_device_add(>cdevs, >devs); >> +if (rc) { >> +dev_err(>devs, >> +"unable to cdev_device_add() %s, major %d, minor %d, >> err=%d\n", >> +dev_name(>devs),

[PATCH v6] TPM fixes

list 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

[PATCH v6] tpm: fix reference counting for struct tpm_chip

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

Re: [PATCH RESEND v5] tpm: fix reference counting for struct tpm_chip

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

[PATCH RESEND v5] tpm: fix reference counting for struct tpm_chip

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

[PATCH RESEND v5] TPM fixes

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/

Re: [PATCH v5] The following sequence of operations results in a refcount warning:

Please ignore this patch, I somehow managed to cut off the head line. I will resend it shorty. Regards, Lino

[PATCH v5] The following sequence of operations results in a refcount warning:

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

[PATCH v5] TPM fixes

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.

Re: [PATCH v4] tpm: fix reference counting for struct tpm_chip

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 modul

Re: [PATCH v4] tpm: fix reference counting for struct tpm_chip

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(>dev);

Re: [PATCH v4] tpm: fix reference counting for struct tpm_chip

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 >>

Re: [PATCH v4] tpm: fix reference counting for struct tpm_chip

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(>devs); &g

[PATCH v4] tpm: fix reference counting for struct tpm_chip

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

[PATCH v4] TPM fixes

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

Re: [PATCH v3 2/2] tpm: in tpm2_del_space check if ops pointer is still valid

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

Re: [PATCH v3 2/2] tpm: in tpm2_del_space check if ops pointer is still valid

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

Re: [PATCH v3 2/2] tpm: in tpm2_del_space check if ops pointer is still valid

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

Re: [PATCH v3 1/2] tpm: fix reference counting for struct tpm_chip

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

Re: [PATCH v3 1/2] tpm: fix reference counting for struct tpm_chip

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

Re: [PATCH v3 1/2] tpm: fix reference counting for struct tpm_chip

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

Re: [PATCH v3 1/2] tpm: fix reference counting for struct tpm_chip

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

Re: [PATCH v3 1/2] tpm: fix reference counting for struct tpm_chip

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

Re: [PATCH v3 2/2] tpm: in tpm2_del_space check if ops pointer is still valid

htly 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

[PATCH v3 1/2] tpm: fix reference counting for struct tpm_chip

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

[PATCH v3 2/2] tpm: in tpm2_del_space check if ops pointer is still valid

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

[PATCH v3 0/2] TPM fixes

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

Re: [PATCH v2 3/3] tpm: in tpm2_del_space check if ops pointer is still valid

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

Re: [PATCH v2 2/3] tpm: Provide a function tpm_chip_free() to free tpm chips

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

Re: [PATCH v2 1/3] tpm: fix reference counting for struct tpm_chip

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

[PATCH v2 1/3] tpm: fix reference counting for struct tpm_chip

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

[PATCH v2 2/3] tpm: Provide a function tpm_chip_free() to free tpm chips

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

[PATCH v2 3/3] tpm: in tpm2_del_space check if ops pointer is still valid

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

[PATCH v2 0/3] TPM fixes

in 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

Re: [PATCH 3/4] tpm: in tpm2_del_space check if ops pointer is still valid

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

Re: [PATCH 3/4] tpm: in tpm2_del_space check if ops pointer is still valid

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

[PATCH 3/4] tpm: in tpm2_del_space check if ops pointer is still valid

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

[PATCH 1/4] tpm: in case of error properly cleanup in tpmm_chip_alloc

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

[PATCH 2/4] tpm: fix reference counting for struct tpm_chip

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

[PATCH 4/4] tpm: Provide a function tpm_chip_free() to free tpm chips

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

[PATCH 0/4] TPM fixes

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

Aw: Re: [PATCH v3] pwm: bcm2835: Support apply function for atomic configuration

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

[PATCH v4] pwm: bcm2835: Support apply function for atomic configuration

the 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

Aw: Re: [PATCH v3] pwm: bcm2835: Support apply function for atomic configuration

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 configuratio

[PATCH v3] pwm: bcm2835: Support apply function for atomic configuration

the 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

Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration

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

Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration

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

Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration

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 */ >>

Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration

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

[RESEND PATCH 2/2] io:core: In iio_map_array_register() cleanup in case of error

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

[RESEND PATCH 1/2] iio:core: Introduce unlocked version of iio_map_array_unregister()

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

[PATCH v2] pwm: bcm2835: Support apply function for atomic configuration

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

Re: [RESEND PATCH 1/2] iio:core: Introduce unlocked version of iio_map_array_unregister()

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

[PATCH] pwm: bcm2835: Support apply function for atomic configuration

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

[PATCH 1/2] iio:core: Introduce unlocked version of iio_map_array_unregister()

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 --- drivers/iio/inkern.c | 27 ++- 1 file changed, 18 insertions(+), 9 deletions

[PATCH 2/2] iio:core: In iio_map_array_register() cleanup in case of error.

In function iio_map_array_register() properly rewind in case of error. Signed-off-by: Lino Sanfilippo --- 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/drivers/iio/inkern.c +++ b/drivers

Re: [PATCH v2] iio:core: In map_array_register() cleanup in case of error

Hi Andy, Thanks for you suggestion. I agree that it is nicer to reuse the cleanup in iio_map_array_unregister() than to reimplement it. However I would like to avoid dropping and regaining the mutex in case of error. What about the attached approach: Introduce an unlocked version of

[PATCH v2] iio:core: In map_array_register() cleanup in case of error

In function map_array_register() properly rewind in case of error. Furthermore remove the now superfluous initialization of "ret" with 0. Signed-off-by: Lino Sanfilippo --- drivers/iio/inkern.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/d

Re: [PATCH] iio:core: In map_array_register() cleanup in case of error

Hi, Am 11.10.20 um 17:07 schrieb Jonathan Cameron: > > Good spot. I'd rather we went with a different code flow though. > See below. > Ok, will adjust the code and send a V2 shortly. Regards, Lino

[PATCH] iio:core: In map_array_register() cleanup in case of error

In function map_array_register() properly rewind in case of error. Furthermore save an extra label by using a break instead of goto to leave the concerning loop. Signed-off-by: Lino Sanfilippo --- drivers/iio/inkern.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff

Aw: Re: [PATCH] net: iucv: Free memory obtained by kzalloc

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

Aw: Re: [PATCH] net: iucv: Free memory obtained by kzalloc

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

Re: [PATCH][V2] net: ethernet: slicoss: remove redundant initialization of idx

buffer *buff; > unsigned int 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 <linosanfili...@gmx.de> Regards, Lino

Re: [PATCH][V2] net: ethernet: slicoss: remove redundant initialization of idx

> 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

Re: [PATCH] net: ethernet: slicoss: remove redundant initialization of idx

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

Re: [PATCH] net: ethernet: slicoss: remove redundant initialization of idx

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

Re: [PATCH] net: ethernet: slicoss: remove redundant initialization of idx

ned int idx; > struct slic_tx_buffer *buff; > unsigned int frames = 0; > unsigned int bytes = 0; > Acked-by: Lino Sanfilippo <linosanfili...@gmx.de> Regards, Lino

Re: [PATCH] net: ethernet: slicoss: remove redundant initialization of idx

55,7 @@ static void slic_xmit_complete(struct slic_device *sdev) > { > struct slic_tx_queue *txq = >txq; > struct net_device *dev = sdev->netdev; > - unsigned int idx = txq->done_idx; > + unsigned int idx; > struct slic_tx_buffer *buff; >

Re: [PATCH RESEND v7 net-next 17/17] net: qualcomm: add QCA7000 UART driver

Hi, > This patch adds the Ethernet over UART driver for the > Qualcomm QCA7000 HomePlug GreenPHY. > > Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com> > --- Reviewed-by: Lino Sanfilippo <linosanfili...@gmx.de> Regards, Lino

Re: [PATCH RESEND v7 net-next 17/17] net: qualcomm: add QCA7000 UART driver

Hi, > This patch adds the Ethernet over UART driver for the > Qualcomm QCA7000 HomePlug GreenPHY. > > Signed-off-by: Stefan Wahren > --- Reviewed-by: Lino Sanfilippo Regards, Lino

Aw: Re: [PATCH v6 net-next 17/17] net: qualcomm: add QCA7000 UART driver

Hi, > Gesendet: Mittwoch, 24. Mai 2017 um 11:06 Uhr > Von: "Stefan Wahren" <stefan.wah...@i2se.com> > An: "Lino Sanfilippo" <linosanfili...@gmx.de>, "Rob Herring" > <robh...@kernel.org>, "Mark Rutland" <mark.rut

Aw: Re: [PATCH v6 net-next 17/17] net: qualcomm: add QCA7000 UART driver

Hi, > Gesendet: Mittwoch, 24. Mai 2017 um 11:06 Uhr > Von: "Stefan Wahren" > An: "Lino Sanfilippo" , "Rob Herring" > , "Mark Rutland" , "David S. > Miller" > Cc: linux-ser...@vger.kernel.org, "Jiri Slaby" , &qu

Re: [PATCH v6 net-next 17/17] net: qualcomm: add QCA7000 UART driver

On 23.05.2017 21:38, Stefan Wahren wrote: > >> Lino Sanfilippo <linosanfili...@gmx.de> hat am 23. Mai 2017 um 20:16 >> geschrieben: >> >> >> Hi, >> >> On 23.05.2017 15:12, Stefan Wahren wrote: >> >> >>> +} >>> + >

Re: [PATCH v6 net-next 17/17] net: qualcomm: add QCA7000 UART driver

On 23.05.2017 21:38, Stefan Wahren wrote: > >> Lino Sanfilippo hat am 23. Mai 2017 um 20:16 >> geschrieben: >> >> >> Hi, >> >> On 23.05.2017 15:12, Stefan Wahren wrote: >> >> >>> +} >>> + >>> +static v

Re: [PATCH v6 net-next 17/17] net: qualcomm: add QCA7000 UART driver

Hi, On 23.05.2017 15:12, Stefan Wahren wrote: > +} > + > +static void qca_uart_remove(struct serdev_device *serdev) > +{ > + struct qcauart *qca = serdev_device_get_drvdata(serdev); > + > + netif_carrier_off(qca->net_dev); > + cancel_work_sync(>tx_work); > +

Re: [PATCH v6 net-next 17/17] net: qualcomm: add QCA7000 UART driver

Hi, On 23.05.2017 15:12, Stefan Wahren wrote: > +} > + > +static void qca_uart_remove(struct serdev_device *serdev) > +{ > + struct qcauart *qca = serdev_device_get_drvdata(serdev); > + > + netif_carrier_off(qca->net_dev); > + cancel_work_sync(>tx_work); > +

Re: [PATCH v5 17/17] net: qualcomm: add QCA7000 UART driver

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 =

Re: [PATCH v5 17/17] net: qualcomm: add QCA7000 UART driver

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 =

Re: [PATCH][V2] ethernet: aquantia: remove redundant checks on error status

s err and the error exit label err_exit. > > Detected by CoverityScan, CID#1398313 and CID#1398306 ("Logically > dead code") > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> FWIW: Reviewed-by: Lino Sanfilippo <linosanfili...@gmx.de> Regards, Lino

Re: [PATCH][V2] ethernet: aquantia: remove redundant checks on error status

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

Re: [PATCH] sky2: Use seq_putc() in sky2_debug_show()

Hi, On 08.05.2017 18:42, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 8 May 2017 18:38:17 +0200 > > A single character (line break) should be put into a sequence. Why? > Thus use the corresponding function "seq_putc". > > This issue was detected

Re: [PATCH] sky2: Use seq_putc() in sky2_debug_show()

Hi, On 08.05.2017 18:42, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 8 May 2017 18:38:17 +0200 > > A single character (line break) should be put into a sequence. Why? > Thus use the corresponding function "seq_putc". > > This issue was detected by using the Coccinelle

Aw: Re: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe

Hi, > This patch doesn't look right to me. I would suggest rejecting it. > > The call to initialize the stats should be done when the ring is > allocated, not in ixgbe_probe(). This should probably be done in > ixgbe_alloc_q_vector() instead. > AFAICS ixgbe_alloc_q_vector() is also called in

Aw: Re: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe

Hi, > This patch doesn't look right to me. I would suggest rejecting it. > > The call to initialize the stats should be done when the ring is > allocated, not in ixgbe_probe(). This should probably be done in > ixgbe_alloc_q_vector() instead. > AFAICS ixgbe_alloc_q_vector() is also called in

Aw: RE: [PATCH net] net: hns: Fix the device being used for dma mapping during TX

> Gesendet: Donnerstag, 09. Februar 2017 um 12:30 Uhr > Von: "Salil Mehta" <salil.me...@huawei.com> > An: "Lino Sanfilippo" <linosanfili...@gmx.de> > Cc: "da...@davemloft.net" <da...@davemloft.net>, "Zhuangyuzeng (Yisen)" &g

Aw: RE: [PATCH net] net: hns: Fix the device being used for dma mapping during TX

> Gesendet: Donnerstag, 09. Februar 2017 um 12:30 Uhr > Von: "Salil Mehta" > An: "Lino Sanfilippo" > Cc: "da...@davemloft.net" , "Zhuangyuzeng (Yisen)" > , "mehta.salil@gmail.com" > , "net...@vger.kernel.org"

Re: [PATCH net] net: hns: Fix the device being used for dma mapping during TX

Hi, > From: Kejian Yan > > This patch fixes the device being used to DMA map skb->data. > Erroneous device assignment causes the crash when SMMU is enabled. > This happens during TX since buffer gets DMA mapped with device > correspondign to net_device and gets unmapped

Re: [PATCH net] net: hns: Fix the device being used for dma mapping during TX

Hi, > From: Kejian Yan > > This patch fixes the device being used to DMA map skb->data. > Erroneous device assignment causes the crash when SMMU is enabled. > This happens during TX since buffer gets DMA mapped with device > correspondign to net_device and gets unmapped using the device >

Re: [PATCH V3 net-next 02/14] net/ena: fix error handling when probe fails

Hi, On 26.01.2017 23:18, Netanel Belgazal wrote: When driver fails in probe, it will release all resources, including adapter. In case of probe failure, ena_remove should not try to free the adapter resources. Signed-off-by: Netanel Belgazal ---

Re: [PATCH V3 net-next 02/14] net/ena: fix error handling when probe fails

Hi, On 26.01.2017 23:18, Netanel Belgazal wrote: When driver fails in probe, it will release all resources, including adapter. In case of probe failure, ena_remove should not try to free the adapter resources. Signed-off-by: Netanel Belgazal --- drivers/net/ethernet/amazon/ena/ena_netdev.c |

Re: Re: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags

Hi, > > > This patch should be enhanced with the smb_xx() calls as suggested by by Lino. > If you do this, please place the smp_rmb() before the if condition in the irq handler like smp_rmb(); if (rtlpci->irq_enabled == 0) { return ret; as I think that the suggestion I made before was

Re: Re: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags

Hi, > > > This patch should be enhanced with the smb_xx() calls as suggested by by Lino. > If you do this, please place the smp_rmb() before the if condition in the irq handler like smp_rmb(); if (rtlpci->irq_enabled == 0) { return ret; as I think that the suggestion I made before was

  1   2   3   4   >