(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
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@quic...
Suzuki
-
Suzuki K Poulose