[PATCH v4 0/4] devres: Provide krealloc_array

[PATCH v4 0/4] devres: Provide krealloc_array

[James Clark]

Changes since v3:

 * Rebase onto v6.4-rc1

Changes since v2:
 
 * Remove change in qcom_geni_serial.c in the last commmit and replace
   it with a comment instead
 * Whitespace fix

Changes since v1:

 * Style fix

-----------------------

Hi,

I had a use for a devm realloc_array in a separate change, so I've
added one and updated all the obvious existing uses of it that I could
find. This is basically a copy paste of the one in slab.h

Applies to v6.4-rc1

Thanks
James
James Clark (4):
  devres: Provide krealloc_array
  hwmon: pmbus: Use devm_krealloc_array
  iio: adc: Use devm_krealloc_array
  serial: qcom_geni: Comment use of devm_krealloc rather than
    devm_krealloc_array

 .../driver-api/driver-model/devres.rst          |  1 +
 drivers/hwmon/pmbus/pmbus_core.c                |  6 +++---
 drivers/iio/adc/xilinx-ams.c                    |  9 +++------
 drivers/iio/adc/xilinx-xadc-core.c              | 17 +++++++----------
 drivers/tty/serial/qcom_geni_serial.c           |  5 +++++
 include/linux/device.h                          | 11 +++++++++++
 6 files changed, 30 insertions(+), 19 deletions(-)

-- 
2.34.1

[PATCH v4 1/4] devres: Provide krealloc_array

[James Clark]

There is no krealloc_array equivalent in devres. Users would have to
do their own multiplication overflow check so provide one.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: James Clark <james.clark@arm.com>
---
 Documentation/driver-api/driver-model/devres.rst |  1 +
 include/linux/device.h                           | 11 +++++++++++
 2 files changed, 12 insertions(+)

diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index 4249eb4239e0..8be086b3f829 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -364,6 +364,7 @@ MEM
   devm_kmalloc_array()
   devm_kmemdup()
   devm_krealloc()
+  devm_krealloc_array()
   devm_kstrdup()
   devm_kstrdup_const()
   devm_kvasprintf()
diff --git a/include/linux/device.h b/include/linux/device.h
index 472dd24d4823..58f4f5948edb 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -223,6 +223,17 @@ static inline void *devm_kcalloc(struct device *dev,
 {
 	return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
 }
+static inline __realloc_size(3, 4) void * __must_check
+devm_krealloc_array(struct device *dev, void *p, size_t new_n, size_t new_size, gfp_t flags)
+{
+	size_t bytes;
+
+	if (unlikely(check_mul_overflow(new_n, new_size, &bytes)))
+		return NULL;
+
+	return devm_krealloc(dev, p, bytes, flags);
+}
+
 void devm_kfree(struct device *dev, const void *p);
 char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp) __malloc;
 const char *devm_kstrdup_const(struct device *dev, const char *s, gfp_t gfp);
-- 
2.34.1

[PATCH v4 2/4] hwmon: pmbus: Use devm_krealloc_array

[James Clark]

Now that it exists, use it instead of doing the multiplication manually.

Acked-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: James Clark <james.clark@arm.com>
---
 drivers/hwmon/pmbus/pmbus_core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 9d14954da94f..fa06325f5a7c 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -1191,9 +1191,9 @@ static int pmbus_add_attribute(struct pmbus_data *data, struct attribute *attr)
 {
 	if (data->num_attributes >= data->max_attributes - 1) {
 		int new_max_attrs = data->max_attributes + PMBUS_ATTR_ALLOC_SIZE;
-		void *new_attrs = devm_krealloc(data->dev, data->group.attrs,
-						new_max_attrs * sizeof(void *),
-						GFP_KERNEL);
+		void *new_attrs = devm_krealloc_array(data->dev, data->group.attrs,
+						      new_max_attrs, sizeof(void *),
+						      GFP_KERNEL);
 		if (!new_attrs)
 			return -ENOMEM;
 		data->group.attrs = new_attrs;
-- 
2.34.1

[PATCH v4 3/4] iio: adc: Use devm_krealloc_array

[James Clark]

Now that it exists, use it instead of doing the multiplication and
checking for overflow manually.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: James Clark <james.clark@arm.com>
---
 drivers/iio/adc/xilinx-ams.c       |  9 +++------
 drivers/iio/adc/xilinx-xadc-core.c | 17 +++++++----------
 2 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
index 34cf336b3490..f0b71a1220e0 100644
--- a/drivers/iio/adc/xilinx-ams.c
+++ b/drivers/iio/adc/xilinx-ams.c
@@ -1263,7 +1263,7 @@ static int ams_parse_firmware(struct iio_dev *indio_dev)
 	struct device *dev = indio_dev->dev.parent;
 	struct fwnode_handle *child = NULL;
 	struct fwnode_handle *fwnode = dev_fwnode(dev);
-	size_t ams_size, dev_size;
+	size_t ams_size;
 	int ret, ch_cnt = 0, i, rising_off, falling_off;
 	unsigned int num_channels = 0;
 
@@ -1320,11 +1320,8 @@ static int ams_parse_firmware(struct iio_dev *indio_dev)
 		}
 	}
 
-	dev_size = array_size(sizeof(*dev_channels), num_channels);
-	if (dev_size == SIZE_MAX)
-		return -ENOMEM;
-
-	dev_channels = devm_krealloc(dev, ams_channels, dev_size, GFP_KERNEL);
+	dev_channels = devm_krealloc_array(dev, ams_channels, num_channels,
+					   sizeof(*dev_channels), GFP_KERNEL);
 	if (!dev_channels)
 		return -ENOMEM;
 
diff --git a/drivers/iio/adc/xilinx-xadc-core.c b/drivers/iio/adc/xilinx-xadc-core.c
index 292f2892d223..dba73300f894 100644
--- a/drivers/iio/adc/xilinx-xadc-core.c
+++ b/drivers/iio/adc/xilinx-xadc-core.c
@@ -613,20 +613,17 @@ static int xadc_update_scan_mode(struct iio_dev *indio_dev,
 	const unsigned long *mask)
 {
 	struct xadc *xadc = iio_priv(indio_dev);
-	size_t new_size, n;
+	size_t n;
 	void *data;
 
 	n = bitmap_weight(mask, indio_dev->masklength);
 
-	if (check_mul_overflow(n, sizeof(*xadc->data), &new_size))
-		return -ENOMEM;
-
-	data = devm_krealloc(indio_dev->dev.parent, xadc->data,
-			     new_size, GFP_KERNEL);
+	data = devm_krealloc_array(indio_dev->dev.parent, xadc->data,
+				   n, sizeof(*xadc->data), GFP_KERNEL);
 	if (!data)
 		return -ENOMEM;
 
-	memset(data, 0, new_size);
+	memset(data, 0, n * sizeof(*xadc->data));
 	xadc->data = data;
 
 	return 0;
@@ -1281,9 +1278,9 @@ static int xadc_parse_dt(struct iio_dev *indio_dev, unsigned int *conf, int irq)
 	}
 
 	indio_dev->num_channels = num_channels;
-	indio_dev->channels = devm_krealloc(dev, channels,
-					    sizeof(*channels) * num_channels,
-					    GFP_KERNEL);
+	indio_dev->channels = devm_krealloc_array(dev, channels,
+						  num_channels, sizeof(*channels),
+						  GFP_KERNEL);
 	/* If we can't resize the channels array, just use the original */
 	if (!indio_dev->channels)
 		indio_dev->channels = channels;
-- 
2.34.1

[PATCH v4 4/4] serial: qcom_geni: Comment use of devm_krealloc rather than devm_krealloc_array

[James Clark]

Now that devm_krealloc_array is available, add a comment justifying not
changing this occurrence to avoid any future auto fixups.

Link: https://lore.kernel.org/all/20230318173402.20a4f60d@jic23-huawei/
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: James Clark <james.clark@arm.com>
---
 drivers/tty/serial/qcom_geni_serial.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index 08dc3e2a729c..3a6cf762449f 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -1053,6 +1053,11 @@ static int setup_fifos(struct qcom_geni_serial_port *port)
 		(port->tx_fifo_depth * port->tx_fifo_width) / BITS_PER_BYTE;
 
 	if (port->rx_buf && (old_rx_fifo_depth != port->rx_fifo_depth) && port->rx_fifo_depth) {
+		/*
+		 * Use krealloc rather than krealloc_array because rx_buf is
+		 * accessed as 1 byte entries as well as 4 byte entries so it's
+		 * not necessarily an array.
+		 */
 		port->rx_buf = devm_krealloc(uport->dev, port->rx_buf,
 					     port->rx_fifo_depth * sizeof(u32),
 					     GFP_KERNEL);
-- 
2.34.1

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Greg KH]

On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
> There is no krealloc_array equivalent in devres. Users would have to
> do their own multiplication overflow check so provide one.
> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Signed-off-by: James Clark <james.clark@arm.com>
> ---
>  Documentation/driver-api/driver-model/devres.rst |  1 +
>  include/linux/device.h                           | 11 +++++++++++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
> index 4249eb4239e0..8be086b3f829 100644
> --- a/Documentation/driver-api/driver-model/devres.rst
> +++ b/Documentation/driver-api/driver-model/devres.rst
> @@ -364,6 +364,7 @@ MEM
>    devm_kmalloc_array()
>    devm_kmemdup()
>    devm_krealloc()
> +  devm_krealloc_array()
>    devm_kstrdup()
>    devm_kstrdup_const()
>    devm_kvasprintf()
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 472dd24d4823..58f4f5948edb 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -223,6 +223,17 @@ static inline void *devm_kcalloc(struct device *dev,
>  {
>  	return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
>  }
> +static inline __realloc_size(3, 4) void * __must_check

Shouldn't you have a blank line before this one?

> +devm_krealloc_array(struct device *dev, void *p, size_t new_n, size_t new_size, gfp_t flags)
> +{
> +	size_t bytes;
> +
> +	if (unlikely(check_mul_overflow(new_n, new_size, &bytes)))
> +		return NULL;
> +
> +	return devm_krealloc(dev, p, bytes, flags);
> +}

I dislike how we have to keep copying the "real" functions (i.e.
krealloc_array) into something like this, but I can't think of a better
way to do it.

thanks,

greg k-h

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[James Clark]

On 13/05/2023 12:04, Greg KH wrote:
> On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
>> There is no krealloc_array equivalent in devres. Users would have to
>> do their own multiplication overflow check so provide one.
>>
>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>> Signed-off-by: James Clark <james.clark@arm.com>
>> ---
>>  Documentation/driver-api/driver-model/devres.rst |  1 +
>>  include/linux/device.h                           | 11 +++++++++++
>>  2 files changed, 12 insertions(+)
>>
>> diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
>> index 4249eb4239e0..8be086b3f829 100644
>> --- a/Documentation/driver-api/driver-model/devres.rst
>> +++ b/Documentation/driver-api/driver-model/devres.rst
>> @@ -364,6 +364,7 @@ MEM
>>    devm_kmalloc_array()
>>    devm_kmemdup()
>>    devm_krealloc()
>> +  devm_krealloc_array()
>>    devm_kstrdup()
>>    devm_kstrdup_const()
>>    devm_kvasprintf()
>> diff --git a/include/linux/device.h b/include/linux/device.h
>> index 472dd24d4823..58f4f5948edb 100644
>> --- a/include/linux/device.h
>> +++ b/include/linux/device.h
>> @@ -223,6 +223,17 @@ static inline void *devm_kcalloc(struct device *dev,
>>  {
>>  	return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
>>  }
>> +static inline __realloc_size(3, 4) void * __must_check
> 
> Shouldn't you have a blank line before this one?

I was going for consistency with the rest of this section which doesn't
have newlines between the functions for some reason. I can add one and
resubmit but it might look a bit out of place?

> 
>> +devm_krealloc_array(struct device *dev, void *p, size_t new_n, size_t new_size, gfp_t flags)
>> +{
>> +	size_t bytes;
>> +
>> +	if (unlikely(check_mul_overflow(new_n, new_size, &bytes)))
>> +		return NULL;
>> +
>> +	return devm_krealloc(dev, p, bytes, flags);
>> +}
> 
> I dislike how we have to keep copying the "real" functions (i.e.
> krealloc_array) into something like this, but I can't think of a better
> way to do it.
> 

Maybe something could be done with some macro magic, but it would
probably end up being worse than just copying them and would affect the
real ones as well. So yeah I can't think of any easy gains either.

Thanks
James

> thanks,
> 
> greg k-h

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Greg KH]

On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
> 
> 
> On 13/05/2023 12:04, Greg KH wrote:
> > On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
> >> There is no krealloc_array equivalent in devres. Users would have to
> >> do their own multiplication overflow check so provide one.
> >>
> >> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >> Signed-off-by: James Clark <james.clark@arm.com>
> >> ---
> >>  Documentation/driver-api/driver-model/devres.rst |  1 +
> >>  include/linux/device.h                           | 11 +++++++++++
> >>  2 files changed, 12 insertions(+)
> >>
> >> diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
> >> index 4249eb4239e0..8be086b3f829 100644
> >> --- a/Documentation/driver-api/driver-model/devres.rst
> >> +++ b/Documentation/driver-api/driver-model/devres.rst
> >> @@ -364,6 +364,7 @@ MEM
> >>    devm_kmalloc_array()
> >>    devm_kmemdup()
> >>    devm_krealloc()
> >> +  devm_krealloc_array()
> >>    devm_kstrdup()
> >>    devm_kstrdup_const()
> >>    devm_kvasprintf()
> >> diff --git a/include/linux/device.h b/include/linux/device.h
> >> index 472dd24d4823..58f4f5948edb 100644
> >> --- a/include/linux/device.h
> >> +++ b/include/linux/device.h
> >> @@ -223,6 +223,17 @@ static inline void *devm_kcalloc(struct device *dev,
> >>  {
> >>  	return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
> >>  }
> >> +static inline __realloc_size(3, 4) void * __must_check
> > 
> > Shouldn't you have a blank line before this one?
> 
> I was going for consistency with the rest of this section which doesn't
> have newlines between the functions for some reason. I can add one and
> resubmit but it might look a bit out of place?

Ah, wasn't aware of that, given the lack of context.  So nevermind, it's
fine for now.

> >> +devm_krealloc_array(struct device *dev, void *p, size_t new_n, size_t new_size, gfp_t flags)
> >> +{
> >> +	size_t bytes;
> >> +
> >> +	if (unlikely(check_mul_overflow(new_n, new_size, &bytes)))
> >> +		return NULL;
> >> +
> >> +	return devm_krealloc(dev, p, bytes, flags);
> >> +}
> > 
> > I dislike how we have to keep copying the "real" functions (i.e.
> > krealloc_array) into something like this, but I can't think of a better
> > way to do it.
> > 
> 
> Maybe something could be done with some macro magic, but it would
> probably end up being worse than just copying them and would affect the
> real ones as well. So yeah I can't think of any easy gains either.

Ok, that's good.  Given a lack of objections from others, I'll just take
this through my driver core tree in a few days.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Greg KH]

On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
> 
> 
> On 13/05/2023 12:04, Greg KH wrote:
> > On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
> >> There is no krealloc_array equivalent in devres. Users would have to
> >> do their own multiplication overflow check so provide one.
> >>
> >> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >> Signed-off-by: James Clark <james.clark@arm.com>
> >> ---
> >>  Documentation/driver-api/driver-model/devres.rst |  1 +
> >>  include/linux/device.h                           | 11 +++++++++++
> >>  2 files changed, 12 insertions(+)
> >>
> >> diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
> >> index 4249eb4239e0..8be086b3f829 100644
> >> --- a/Documentation/driver-api/driver-model/devres.rst
> >> +++ b/Documentation/driver-api/driver-model/devres.rst
> >> @@ -364,6 +364,7 @@ MEM
> >>    devm_kmalloc_array()
> >>    devm_kmemdup()
> >>    devm_krealloc()
> >> +  devm_krealloc_array()
> >>    devm_kstrdup()
> >>    devm_kstrdup_const()
> >>    devm_kvasprintf()
> >> diff --git a/include/linux/device.h b/include/linux/device.h
> >> index 472dd24d4823..58f4f5948edb 100644
> >> --- a/include/linux/device.h
> >> +++ b/include/linux/device.h
> >> @@ -223,6 +223,17 @@ static inline void *devm_kcalloc(struct device *dev,
> >>  {
> >>  	return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
> >>  }
> >> +static inline __realloc_size(3, 4) void * __must_check
> > 
> > Shouldn't you have a blank line before this one?
> 
> I was going for consistency with the rest of this section which doesn't
> have newlines between the functions for some reason. I can add one and
> resubmit but it might look a bit out of place?

Ah, wasn't aware of that, given the lack of context.  So nevermind, it's
fine for now.

> >> +devm_krealloc_array(struct device *dev, void *p, size_t new_n, size_t new_size, gfp_t flags)
> >> +{
> >> +	size_t bytes;
> >> +
> >> +	if (unlikely(check_mul_overflow(new_n, new_size, &bytes)))
> >> +		return NULL;
> >> +
> >> +	return devm_krealloc(dev, p, bytes, flags);
> >> +}
> > 
> > I dislike how we have to keep copying the "real" functions (i.e.
> > krealloc_array) into something like this, but I can't think of a better
> > way to do it.
> > 
> 
> Maybe something could be done with some macro magic, but it would
> probably end up being worse than just copying them and would affect the
> real ones as well. So yeah I can't think of any easy gains either.

Ok, that's good.  Given a lack of objections from others, I'll just take
this through my driver core tree in a few days.

thanks,

greg k-h

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Suzuki K Poulose]

(Removed irrelevant recipients), +Cc: coresight ml

Hi Greg,

On 15/05/2023 12:55, Greg KH wrote:
> On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
>>
>>
>> On 13/05/2023 12:04, Greg KH wrote:
>>> On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
>>>> There is no krealloc_array equivalent in devres. Users would have to
>>>> do their own multiplication overflow check so provide one.
>>>>
>>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>>> Signed-off-by: James Clark <james.clark@arm.com>
>>>> ---
>>>>   Documentation/driver-api/driver-model/devres.rst |  1 +
>>>>   include/linux/device.h                           | 11 +++++++++++
>>>>   2 files changed, 12 insertions(+)

...

>> Maybe something could be done with some macro magic, but it would
>> probably end up being worse than just copying them and would affect the
>> real ones as well. So yeah I can't think of any easy gains either.
> 
> Ok, that's good.  Given a lack of objections from others, I'll just take
> this through my driver core tree in a few days.

Apologies for hijacking the thread. We have a series for CoreSight[1]
that depends on this series, which I see that, is queued in your
driver-core-next.

I would like to queue [1] for the next version (as there are other
work that depend on this, e.g., [2]). Do you have any 
recommendations/comments on the proposal ? Are you able to share a
stable branch which can be merged to coresight/next and queue the
series ontop ? (PS: I haven't queued anything for coresight/next yet).

Kind regards
Suzuki

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Suzuki K Poulose]

(Removed irrelevant recipients), +Cc: coresight ml

Hi Greg,

On 15/05/2023 12:55, Greg KH wrote:
> On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
>>
>>
>> On 13/05/2023 12:04, Greg KH wrote:
>>> On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
>>>> There is no krealloc_array equivalent in devres. Users would have to
>>>> do their own multiplication overflow check so provide one.
>>>>
>>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>>> Signed-off-by: James Clark <james.clark@arm.com>
>>>> ---
>>>>   Documentation/driver-api/driver-model/devres.rst |  1 +
>>>>   include/linux/device.h                           | 11 +++++++++++
>>>>   2 files changed, 12 insertions(+)

...

>> Maybe something could be done with some macro magic, but it would
>> probably end up being worse than just copying them and would affect the
>> real ones as well. So yeah I can't think of any easy gains either.
> 
> Ok, that's good.  Given a lack of objections from others, I'll just take
> this through my driver core tree in a few days.

Apologies for hijacking the thread. We have a series for CoreSight[1]
that depends on this series, which I see that, is queued in your
driver-core-next.

I would like to queue [1] for the next version (as there are other
work that depend on this, e.g., [2]). Do you have any 
recommendations/comments on the proposal ? Are you able to share a
stable branch which can be merged to coresight/next and queue the
series ontop ? (PS: I haven't queued anything for coresight/next yet).

Kind regards
Suzuki





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Suzuki K Poulose]

Hi Greg,

Links updated to the series.

On 31/05/2023 23:44, Suzuki K Poulose wrote:
> (Removed irrelevant recipients), +Cc: coresight ml
> 
> Hi Greg,
> 
> On 15/05/2023 12:55, Greg KH wrote:
>> On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
>>>
>>>
>>> On 13/05/2023 12:04, Greg KH wrote:
>>>> On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
>>>>> There is no krealloc_array equivalent in devres. Users would have to
>>>>> do their own multiplication overflow check so provide one.
>>>>>
>>>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>>>> Signed-off-by: James Clark <james.clark@arm.com>
>>>>> ---
>>>>>   Documentation/driver-api/driver-model/devres.rst |  1 +
>>>>>   include/linux/device.h                           | 11 +++++++++++
>>>>>   2 files changed, 12 insertions(+)
> 
> ...
> 
>>> Maybe something could be done with some macro magic, but it would
>>> probably end up being worse than just copying them and would affect the
>>> real ones as well. So yeah I can't think of any easy gains either.
>>
>> Ok, that's good.  Given a lack of objections from others, I'll just take
>> this through my driver core tree in a few days.
> 
> Apologies for hijacking the thread. We have a series for CoreSight[1]
> that depends on this series, which I see that, is queued in your
> driver-core-next.
> 
> I would like to queue [1] for the next version (as there are other
> work that depend on this, e.g., [2]). Do you have any 
> recommendations/comments on the proposal ? Are you able to share a
> stable branch which can be merged to coresight/next and queue the
> series ontop ? (PS: I haven't queued anything for coresight/next yet).

[1] https://lkml.kernel.org/r/20230425143542.2305069-1-james.clark@arm.com
[2] 
https://lkml.kernel.org/r/1682586037-25973-1-git-send-email-quic_taozha@quicinc.com


Suzuki

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Suzuki K Poulose]

Hi Greg,

Links updated to the series.

On 31/05/2023 23:44, Suzuki K Poulose wrote:
> (Removed irrelevant recipients), +Cc: coresight ml
> 
> Hi Greg,
> 
> On 15/05/2023 12:55, Greg KH wrote:
>> On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
>>>
>>>
>>> On 13/05/2023 12:04, Greg KH wrote:
>>>> On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
>>>>> There is no krealloc_array equivalent in devres. Users would have to
>>>>> do their own multiplication overflow check so provide one.
>>>>>
>>>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>>>> Signed-off-by: James Clark <james.clark@arm.com>
>>>>> ---
>>>>>   Documentation/driver-api/driver-model/devres.rst |  1 +
>>>>>   include/linux/device.h                           | 11 +++++++++++
>>>>>   2 files changed, 12 insertions(+)
> 
> ...
> 
>>> Maybe something could be done with some macro magic, but it would
>>> probably end up being worse than just copying them and would affect the
>>> real ones as well. So yeah I can't think of any easy gains either.
>>
>> Ok, that's good.  Given a lack of objections from others, I'll just take
>> this through my driver core tree in a few days.
> 
> Apologies for hijacking the thread. We have a series for CoreSight[1]
> that depends on this series, which I see that, is queued in your
> driver-core-next.
> 
> I would like to queue [1] for the next version (as there are other
> work that depend on this, e.g., [2]). Do you have any 
> recommendations/comments on the proposal ? Are you able to share a
> stable branch which can be merged to coresight/next and queue the
> series ontop ? (PS: I haven't queued anything for coresight/next yet).

[1] https://lkml.kernel.org/r/20230425143542.2305069-1-james.clark@arm.com
[2] 
https://lkml.kernel.org/r/1682586037-25973-1-git-send-email-quic_taozha@quicinc.com


Suzuki


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Greg KH]

On Wed, May 31, 2023 at 11:44:55PM +0100, Suzuki K Poulose wrote:
> (Removed irrelevant recipients), +Cc: coresight ml
> 
> Hi Greg,
> 
> On 15/05/2023 12:55, Greg KH wrote:
> > On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
> > > 
> > > 
> > > On 13/05/2023 12:04, Greg KH wrote:
> > > > On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
> > > > > There is no krealloc_array equivalent in devres. Users would have to
> > > > > do their own multiplication overflow check so provide one.
> > > > > 
> > > > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > > > Signed-off-by: James Clark <james.clark@arm.com>
> > > > > ---
> > > > >   Documentation/driver-api/driver-model/devres.rst |  1 +
> > > > >   include/linux/device.h                           | 11 +++++++++++
> > > > >   2 files changed, 12 insertions(+)
> 
> ...
> 
> > > Maybe something could be done with some macro magic, but it would
> > > probably end up being worse than just copying them and would affect the
> > > real ones as well. So yeah I can't think of any easy gains either.
> > 
> > Ok, that's good.  Given a lack of objections from others, I'll just take
> > this through my driver core tree in a few days.
> 
> Apologies for hijacking the thread. We have a series for CoreSight[1]
> that depends on this series, which I see that, is queued in your
> driver-core-next.
> 
> I would like to queue [1] for the next version (as there are other
> work that depend on this, e.g., [2]). Do you have any
> recommendations/comments on the proposal ? Are you able to share a
> stable branch which can be merged to coresight/next and queue the
> series ontop ? (PS: I haven't queued anything for coresight/next yet).

You can pull from my driver-core-next branch just fine and assume it
will be stable.  So just pull in that one commit and all should be good
in the future.

thanks,

greg k-h

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Greg KH]

On Wed, May 31, 2023 at 11:44:55PM +0100, Suzuki K Poulose wrote:
> (Removed irrelevant recipients), +Cc: coresight ml
> 
> Hi Greg,
> 
> On 15/05/2023 12:55, Greg KH wrote:
> > On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
> > > 
> > > 
> > > On 13/05/2023 12:04, Greg KH wrote:
> > > > On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
> > > > > There is no krealloc_array equivalent in devres. Users would have to
> > > > > do their own multiplication overflow check so provide one.
> > > > > 
> > > > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > > > Signed-off-by: James Clark <james.clark@arm.com>
> > > > > ---
> > > > >   Documentation/driver-api/driver-model/devres.rst |  1 +
> > > > >   include/linux/device.h                           | 11 +++++++++++
> > > > >   2 files changed, 12 insertions(+)
> 
> ...
> 
> > > Maybe something could be done with some macro magic, but it would
> > > probably end up being worse than just copying them and would affect the
> > > real ones as well. So yeah I can't think of any easy gains either.
> > 
> > Ok, that's good.  Given a lack of objections from others, I'll just take
> > this through my driver core tree in a few days.
> 
> Apologies for hijacking the thread. We have a series for CoreSight[1]
> that depends on this series, which I see that, is queued in your
> driver-core-next.
> 
> I would like to queue [1] for the next version (as there are other
> work that depend on this, e.g., [2]). Do you have any
> recommendations/comments on the proposal ? Are you able to share a
> stable branch which can be merged to coresight/next and queue the
> series ontop ? (PS: I haven't queued anything for coresight/next yet).

You can pull from my driver-core-next branch just fine and assume it
will be stable.  So just pull in that one commit and all should be good
in the future.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Suzuki K Poulose]

On 01/06/2023 10:33, Greg KH wrote:
> On Wed, May 31, 2023 at 11:44:55PM +0100, Suzuki K Poulose wrote:
>> (Removed irrelevant recipients), +Cc: coresight ml
>>
>> Hi Greg,
>>
>> On 15/05/2023 12:55, Greg KH wrote:
>>> On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
>>>>
>>>>
>>>> On 13/05/2023 12:04, Greg KH wrote:
>>>>> On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
>>>>>> There is no krealloc_array equivalent in devres. Users would have to
>>>>>> do their own multiplication overflow check so provide one.
>>>>>>
>>>>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>>>>> Signed-off-by: James Clark <james.clark@arm.com>
>>>>>> ---
>>>>>>    Documentation/driver-api/driver-model/devres.rst |  1 +
>>>>>>    include/linux/device.h                           | 11 +++++++++++
>>>>>>    2 files changed, 12 insertions(+)
>>
>> ...
>>
>>>> Maybe something could be done with some macro magic, but it would
>>>> probably end up being worse than just copying them and would affect the
>>>> real ones as well. So yeah I can't think of any easy gains either.
>>>
>>> Ok, that's good.  Given a lack of objections from others, I'll just take
>>> this through my driver core tree in a few days.
>>
>> Apologies for hijacking the thread. We have a series for CoreSight[1]
>> that depends on this series, which I see that, is queued in your
>> driver-core-next.
>>
>> I would like to queue [1] for the next version (as there are other
>> work that depend on this, e.g., [2]). Do you have any
>> recommendations/comments on the proposal ? Are you able to share a
>> stable branch which can be merged to coresight/next and queue the
>> series ontop ? (PS: I haven't queued anything for coresight/next yet).
> 
> You can pull from my driver-core-next branch just fine and assume it
> will be stable.  So just pull in that one commit and all should be good
> in the future.

Thanks Greg, I will give it a go

Suzuki

> 
> thanks,
> 
> greg k-h


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Suzuki K Poulose]

On 01/06/2023 10:33, Greg KH wrote:
> On Wed, May 31, 2023 at 11:44:55PM +0100, Suzuki K Poulose wrote:
>> (Removed irrelevant recipients), +Cc: coresight ml
>>
>> Hi Greg,
>>
>> On 15/05/2023 12:55, Greg KH wrote:
>>> On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
>>>>
>>>>
>>>> On 13/05/2023 12:04, Greg KH wrote:
>>>>> On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
>>>>>> There is no krealloc_array equivalent in devres. Users would have to
>>>>>> do their own multiplication overflow check so provide one.
>>>>>>
>>>>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>>>>> Signed-off-by: James Clark <james.clark@arm.com>
>>>>>> ---
>>>>>>    Documentation/driver-api/driver-model/devres.rst |  1 +
>>>>>>    include/linux/device.h                           | 11 +++++++++++
>>>>>>    2 files changed, 12 insertions(+)
>>
>> ...
>>
>>>> Maybe something could be done with some macro magic, but it would
>>>> probably end up being worse than just copying them and would affect the
>>>> real ones as well. So yeah I can't think of any easy gains either.
>>>
>>> Ok, that's good.  Given a lack of objections from others, I'll just take
>>> this through my driver core tree in a few days.
>>
>> Apologies for hijacking the thread. We have a series for CoreSight[1]
>> that depends on this series, which I see that, is queued in your
>> driver-core-next.
>>
>> I would like to queue [1] for the next version (as there are other
>> work that depend on this, e.g., [2]). Do you have any
>> recommendations/comments on the proposal ? Are you able to share a
>> stable branch which can be merged to coresight/next and queue the
>> series ontop ? (PS: I haven't queued anything for coresight/next yet).
> 
> You can pull from my driver-core-next branch just fine and assume it
> will be stable.  So just pull in that one commit and all should be good
> in the future.

Thanks Greg, I will give it a go

Suzuki

> 
> thanks,
> 
> greg k-h

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Suzuki K Poulose]

Hi Greg

On 01/06/2023 10:52, Suzuki K Poulose wrote:
> On 01/06/2023 10:33, Greg KH wrote:
>> On Wed, May 31, 2023 at 11:44:55PM +0100, Suzuki K Poulose wrote:
>>> (Removed irrelevant recipients), +Cc: coresight ml

...

>>> Apologies for hijacking the thread. We have a series for CoreSight[1]
>>> that depends on this series, which I see that, is queued in your
>>> driver-core-next.
>>>
>>> I would like to queue [1] for the next version (as there are other
>>> work that depend on this, e.g., [2]). Do you have any
>>> recommendations/comments on the proposal ? Are you able to share a
>>> stable branch which can be merged to coresight/next and queue the
>>> series ontop ? (PS: I haven't queued anything for coresight/next yet).
>>
>> You can pull from my driver-core-next branch just fine and assume it
>> will be stable.  So just pull in that one commit and all should be good
>> in the future.
> 
> Thanks Greg, I will give it a go

Does this look fine with you ?

https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=tmp/devm_krealloc_array

Suzuki

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Suzuki K Poulose]

Hi Greg

On 01/06/2023 10:52, Suzuki K Poulose wrote:
> On 01/06/2023 10:33, Greg KH wrote:
>> On Wed, May 31, 2023 at 11:44:55PM +0100, Suzuki K Poulose wrote:
>>> (Removed irrelevant recipients), +Cc: coresight ml

...

>>> Apologies for hijacking the thread. We have a series for CoreSight[1]
>>> that depends on this series, which I see that, is queued in your
>>> driver-core-next.
>>>
>>> I would like to queue [1] for the next version (as there are other
>>> work that depend on this, e.g., [2]). Do you have any
>>> recommendations/comments on the proposal ? Are you able to share a
>>> stable branch which can be merged to coresight/next and queue the
>>> series ontop ? (PS: I haven't queued anything for coresight/next yet).
>>
>> You can pull from my driver-core-next branch just fine and assume it
>> will be stable.  So just pull in that one commit and all should be good
>> in the future.
> 
> Thanks Greg, I will give it a go

Does this look fine with you ?

https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=tmp/devm_krealloc_array

Suzuki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Greg KH]

On Mon, Jun 05, 2023 at 02:39:44PM +0100, Suzuki K Poulose wrote:
> Hi Greg
> 
> On 01/06/2023 10:52, Suzuki K Poulose wrote:
> > On 01/06/2023 10:33, Greg KH wrote:
> > > On Wed, May 31, 2023 at 11:44:55PM +0100, Suzuki K Poulose wrote:
> > > > (Removed irrelevant recipients), +Cc: coresight ml
> 
> ...
> 
> > > > Apologies for hijacking the thread. We have a series for CoreSight[1]
> > > > that depends on this series, which I see that, is queued in your
> > > > driver-core-next.
> > > > 
> > > > I would like to queue [1] for the next version (as there are other
> > > > work that depend on this, e.g., [2]). Do you have any
> > > > recommendations/comments on the proposal ? Are you able to share a
> > > > stable branch which can be merged to coresight/next and queue the
> > > > series ontop ? (PS: I haven't queued anything for coresight/next yet).
> > > 
> > > You can pull from my driver-core-next branch just fine and assume it
> > > will be stable.  So just pull in that one commit and all should be good
> > > in the future.
> > 
> > Thanks Greg, I will give it a go
> 
> Does this look fine with you ?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=tmp/devm_krealloc_array

Looks good to me!

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Greg KH]

On Mon, Jun 05, 2023 at 02:39:44PM +0100, Suzuki K Poulose wrote:
> Hi Greg
> 
> On 01/06/2023 10:52, Suzuki K Poulose wrote:
> > On 01/06/2023 10:33, Greg KH wrote:
> > > On Wed, May 31, 2023 at 11:44:55PM +0100, Suzuki K Poulose wrote:
> > > > (Removed irrelevant recipients), +Cc: coresight ml
> 
> ...
> 
> > > > Apologies for hijacking the thread. We have a series for CoreSight[1]
> > > > that depends on this series, which I see that, is queued in your
> > > > driver-core-next.
> > > > 
> > > > I would like to queue [1] for the next version (as there are other
> > > > work that depend on this, e.g., [2]). Do you have any
> > > > recommendations/comments on the proposal ? Are you able to share a
> > > > stable branch which can be merged to coresight/next and queue the
> > > > series ontop ? (PS: I haven't queued anything for coresight/next yet).
> > > 
> > > You can pull from my driver-core-next branch just fine and assume it
> > > will be stable.  So just pull in that one commit and all should be good
> > > in the future.
> > 
> > Thanks Greg, I will give it a go
> 
> Does this look fine with you ?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=tmp/devm_krealloc_array

Looks good to me!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Suzuki K Poulose]

On 05/06/2023 16:20, Greg KH wrote:
> On Mon, Jun 05, 2023 at 02:39:44PM +0100, Suzuki K Poulose wrote:

>> Does this look fine with you ?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=tmp/devm_krealloc_array
> 
> Looks good to me!

Thank you so much for checking ! I will push this to coresight/next.

Suzuki

Re: [PATCH v4 1/4] devres: Provide krealloc_array

[Suzuki K Poulose]

On 05/06/2023 16:20, Greg KH wrote:
> On Mon, Jun 05, 2023 at 02:39:44PM +0100, Suzuki K Poulose wrote:

>> Does this look fine with you ?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=tmp/devm_krealloc_array
> 
> Looks good to me!

Thank you so much for checking ! I will push this to coresight/next.

Suzuki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel