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