Re: [PATCH] staging/ion: Add support to get ion handle from dma buf
Sorry to resend the patch without [RESEND] tag. Actually I had missed
to add de...@driverdev.osuosl.org, linux-ker...@vger.kernel.org in
mail last time.
I will update the commit message with the explanation and send the
PATCHv2 soon.
Thanks,
Rohit
On Tue, 05 Jan 2016 10:12:39 -0800
Laura Abbott wrote:
> On 01/05/2016 05:03 AM, Rohit kumar wrote:
> > Currently we can only import dma buf fd's to get ion_handle.
> > Adding support to import dma buf handles to support kernel
> > specific use cases.
> >
> > Signed-off-by: Rohit kumar
> > ---
> > Currently, ION is the memory manager for graphics in android.
> > However, in other linux platforms such as Tizen, DRM-GEM is used
> > for buffer management for graphics. It has gem_handle corresponding
> > to a buffer and uses gem_name for sharing the buffer with other
> > processes. However, it also uses dma_buf fd for 3d operations. For
> > wayland, there are multiple calls for gem_handle to dma_buf fd
> > conversion. So, we store dma_buf associated with buffer. But, there
> > is no api for getting ion_handle from dma_buf. This patch exposes
> > api to retrieve the ion handle from dma_buf for similar use cases.
> > With this patch, we can integrate ION within DRM-GEM for buffer
> > management and dma_buf sharing.
> >
>
> Is this the same patch that was sent on 12/29? In general it's best to
> wait a bit longer before resending, especially with lots of people
> being off for the holidays. Please also tag your patch with [RESEND]
> so it's easier to tell that this is the same patch being sent again.
>
> This is also a good explanation that should be included in the commit
> text as well. It gives a much more thorough explanation why this
> API is needed. The substance of the patch looks okay to me.
>
> Thanks,
> Laura
>
> > drivers/staging/android/ion/ion.c | 21 +++--
> > drivers/staging/android/ion/ion.h | 20
> > 2 files changed, 31 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/staging/android/ion/ion.c
> > b/drivers/staging/android/ion/ion.c index e237e9f..5509716 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
> > @@ -1151,16 +1151,13 @@ int ion_share_dma_buf_fd(struct ion_client
> > *client, struct ion_handle *handle) }
> > EXPORT_SYMBOL(ion_share_dma_buf_fd);
> >
> > -struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> > int fd) +struct ion_handle *ion_import_dma_buf(struct ion_client
> > *client,
> > + struct dma_buf *dmabuf)
> > {
> > - struct dma_buf *dmabuf;
> > struct ion_buffer *buffer;
> > struct ion_handle *handle;
> > int ret;
> >
> > - dmabuf = dma_buf_get(fd);
> > - if (IS_ERR(dmabuf))
> > - return ERR_CAST(dmabuf);
> > /* if this memory came from ion */
> >
> > if (dmabuf->ops != &dma_buf_ops) {
> > @@ -1199,6 +1196,18 @@ end:
> > }
> > EXPORT_SYMBOL(ion_import_dma_buf);
> >
> > +struct ion_handle *ion_import_dma_buf_fd(struct ion_client
> > *client, int fd) +{
> > + struct dma_buf *dmabuf;
> > +
> > + dmabuf = dma_buf_get(fd);
> > + if (IS_ERR(dmabuf))
> > + return ERR_CAST(dmabuf);
> > +
> > + return ion_import_dma_buf(client, dmabuf);
> > +}
> > +EXPORT_SYMBOL(ion_import_dma_buf_fd);
> > +
> > static int ion_sync_for_device(struct ion_client *client, int fd)
> > {
> > struct dma_buf *dmabuf;
> > @@ -1306,7 +1315,7 @@ static long ion_ioctl(struct file *filp,
> > unsigned int cmd, unsigned long arg) {
> > struct ion_handle *handle;
> >
> > - handle = ion_import_dma_buf(client, data.fd.fd);
> > + handle = ion_import_dma_buf_fd(client, data.fd.fd);
> > if (IS_ERR(handle))
> > ret = PTR_ERR(handle);
> > else
> > diff --git a/drivers/staging/android/ion/ion.h
> > b/drivers/staging/android/ion/ion.h index b860c5f..a1331fc 100644
> > --- a/drivers/staging/android/ion/ion.h
> > +++ b/drivers/staging/android/ion/ion.h
> > @@ -192,14 +192,26 @@ struct dma_buf *ion_share_dma_buf(struct
> > ion_client *client, int ion_share_dma_buf_fd(struct ion_client
> > *client, struct ion_handle *handle);
> >
> > /**
> > - * ion_import_dma_buf() - given an dma-buf fd from the ion
> > exporter get handle
> > + * ion_import_dma_buf() - get ion_handle from dma-buf
> > + * @client:th
Re: [PATCHv2 1/1] staging/ion: Add support to get ion handle from dma buf
Hi Sumit,
On Thu, 07 Jan 2016 19:43:09 +0530
Sumit Semwal wrote:
> Hi Rohit,
>
> On 6 January 2016 at 12:41, Rohit kumar wrote:
> > Currently we can only import dma buf fd's to get ion_handle.
> > Adding support to import dma buf handles to support kernel
> > specific use cases.
> >
> > An example use case is in linux platforms such as Tizen, in which
> > DRM-GEM is used for buffer management for graphics. It has
> > gem_handle corresponding to a buffer and uses gem_name for sharing
> > the buffer with other processes. However,it also uses dma_buf fd
> > for 3d operations. For wayland, there are multiple calls for
> > gem_handle to dma_buf fd conversion. So, we store dma_buf
> > associated with buffer. But, there is no api for getting ion_handle
> > from dma_buf. This patch exposes api to retrieve the ion handle
> > from dma_buf for similar use cases. With this patch, we can
> > integrate ION within DRM-GEM for buffer management and dma_buf
> > sharing.
> >
> > Signed-off-by: Rohit kumar
> > ---
> > v2: Updated commit message with use case explanation, as suggested
> > by Laura Abbott
> >
> Thanks for this patch.
>
> In general it looks good to me, but perhaps you should add related ION
> tests for this as well? Once you add that and share for review, feel
> free to add
Thanks for the suggestion. I would add related ION test and share for
review sooner.
> Reviewed-by: Sumit Semwal
>
> > drivers/staging/android/ion/ion.c | 21 +++--
> > drivers/staging/android/ion/ion.h | 20
> > 2 files changed, 31 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/staging/android/ion/ion.c
> > b/drivers/staging/android/ion/ion.c index e237e9f..5509716 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
> > @@ -1151,16 +1151,13 @@ int ion_share_dma_buf_fd(struct ion_client
> > *client, struct ion_handle *handle) }
> > EXPORT_SYMBOL(ion_share_dma_buf_fd);
> >
> > -struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> > int fd) +struct ion_handle *ion_import_dma_buf(struct ion_client
> > *client,
> > + struct dma_buf *dmabuf)
> > {
> > - struct dma_buf *dmabuf;
> > struct ion_buffer *buffer;
> > struct ion_handle *handle;
> > int ret;
> >
> > - dmabuf = dma_buf_get(fd);
> > - if (IS_ERR(dmabuf))
> > - return ERR_CAST(dmabuf);
> > /* if this memory came from ion */
> >
> > if (dmabuf->ops != &dma_buf_ops) {
> > @@ -1199,6 +1196,18 @@ end:
> > }
> > EXPORT_SYMBOL(ion_import_dma_buf);
> >
> > +struct ion_handle *ion_import_dma_buf_fd(struct ion_client
> > *client, int fd) +{
> > + struct dma_buf *dmabuf;
> > +
> > + dmabuf = dma_buf_get(fd);
> > + if (IS_ERR(dmabuf))
> > + return ERR_CAST(dmabuf);
> > +
> > + return ion_import_dma_buf(client, dmabuf);
> > +}
> > +EXPORT_SYMBOL(ion_import_dma_buf_fd);
> > +
> > static int ion_sync_for_device(struct ion_client *client, int fd)
> > {
> > struct dma_buf *dmabuf;
> > @@ -1306,7 +1315,7 @@ static long ion_ioctl(struct file *filp,
> > unsigned int cmd, unsigned long arg) {
> > struct ion_handle *handle;
> >
> > - handle = ion_import_dma_buf(client, data.fd.fd);
> > + handle = ion_import_dma_buf_fd(client, data.fd.fd);
> > if (IS_ERR(handle))
> > ret = PTR_ERR(handle);
> > else
> > diff --git a/drivers/staging/android/ion/ion.h
> > b/drivers/staging/android/ion/ion.h index b860c5f..a1331fc 100644
> > --- a/drivers/staging/android/ion/ion.h
> > +++ b/drivers/staging/android/ion/ion.h
> > @@ -192,14 +192,26 @@ struct dma_buf *ion_share_dma_buf(struct
> > ion_client *client, int ion_share_dma_buf_fd(struct ion_client
> > *client, struct ion_handle *handle);
> >
> > /**
> > - * ion_import_dma_buf() - given an dma-buf fd from the ion
> > exporter get handle
> > + * ion_import_dma_buf() - get ion_handle from dma-buf
> > + * @client:the client
> > + * @dmabuf:the dma-buf
> > + *
> > + * Get the ion_buffer associated with the dma-buf and return the
> > ion_handle.
> > + * If no ion_handle exists for this buffer, return newly created
> > ion_handle.
> > + * If dma-buf from another exporter is p
Re: [PATCHv3 1/1] staging/ion: Add support to get ion handle from dma buf
Kindly review the patch. Patchv2 had refcount issue which is fixed here.
On Tue, 12 Jan 2016 09:31:46 +0530
Rohit kumar wrote:
> Currently we can only import dma buf fd's to get ion_handle.
> Adding support to import dma buf handles to support kernel
> specific use cases.
>
> An example use case is in linux platforms such as Tizen, in which
> DRM-GEM is used for buffer management for graphics. It has gem_handle
> corresponding to a buffer and uses gem_name for sharing the buffer
> with other processes. However,it also uses dma_buf fd for 3d
> operations. For wayland, there are multiple calls for gem_handle to
> dma_buf fd conversion. So, we store dma_buf associated with buffer.
> But, there is no api for getting ion_handle from dma_buf. This patch
> exposes api to retrieve the ion handle from dma_buf for similar use
> cases. With this patch, we can integrate ION within DRM-GEM for
> buffer management and dma_buf sharing.
>
> Signed-off-by: Rohit kumar
> ---
> v2: Updated commit message with use case explanation, as suggested by
> Laura Abbott
> v3: Fixed dmabuf refcount issue in ion_import_dma_buf. dma_buf_put()
> was being called without dma_buf_get(), so moving it to
> ion_import_dma_buf_fd().
>
> drivers/staging/android/ion/ion.c | 26 ++
> drivers/staging/android/ion/ion.h | 20
> 2 files changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c index e237e9f..7e86e18 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -1151,22 +1151,18 @@ int ion_share_dma_buf_fd(struct ion_client
> *client, struct ion_handle *handle) }
> EXPORT_SYMBOL(ion_share_dma_buf_fd);
>
> -struct ion_handle *ion_import_dma_buf(struct ion_client *client, int
> fd) +struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> + struct dma_buf *dmabuf)
> {
> - struct dma_buf *dmabuf;
> struct ion_buffer *buffer;
> struct ion_handle *handle;
> int ret;
>
> - dmabuf = dma_buf_get(fd);
> - if (IS_ERR(dmabuf))
> - return ERR_CAST(dmabuf);
> /* if this memory came from ion */
>
> if (dmabuf->ops != &dma_buf_ops) {
> pr_err("%s: can not import dmabuf from another
> exporter\n", __func__);
> - dma_buf_put(dmabuf);
> return ERR_PTR(-EINVAL);
> }
> buffer = dmabuf->priv;
> @@ -1194,11 +1190,25 @@ struct ion_handle *ion_import_dma_buf(struct
> ion_client *client, int fd) }
>
> end:
> - dma_buf_put(dmabuf);
> return handle;
> }
> EXPORT_SYMBOL(ion_import_dma_buf);
>
> +struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client,
> int fd) +{
> + struct dma_buf *dmabuf;
> + struct ion_handle *handle;
> +
> + dmabuf = dma_buf_get(fd);
> + if (IS_ERR(dmabuf))
> + return ERR_CAST(dmabuf);
> +
> + handle = ion_import_dma_buf(client, dmabuf);
> + dma_buf_put(dmabuf);
> + return handle;
> +}
> +EXPORT_SYMBOL(ion_import_dma_buf_fd);
> +
> static int ion_sync_for_device(struct ion_client *client, int fd)
> {
> struct dma_buf *dmabuf;
> @@ -1306,7 +1316,7 @@ static long ion_ioctl(struct file *filp,
> unsigned int cmd, unsigned long arg) {
> struct ion_handle *handle;
>
> - handle = ion_import_dma_buf(client, data.fd.fd);
> + handle = ion_import_dma_buf_fd(client, data.fd.fd);
> if (IS_ERR(handle))
> ret = PTR_ERR(handle);
> else
> diff --git a/drivers/staging/android/ion/ion.h
> b/drivers/staging/android/ion/ion.h index b860c5f..a1331fc 100644
> --- a/drivers/staging/android/ion/ion.h
> +++ b/drivers/staging/android/ion/ion.h
> @@ -192,14 +192,26 @@ struct dma_buf *ion_share_dma_buf(struct
> ion_client *client, int ion_share_dma_buf_fd(struct ion_client
> *client, struct ion_handle *handle);
> /**
> - * ion_import_dma_buf() - given an dma-buf fd from the ion exporter
> get handle
> + * ion_import_dma_buf() - get ion_handle from dma-buf
> + * @client: the client
> + * @dmabuf: the dma-buf
> + *
> + * Get the ion_buffer associated with the dma-buf and return the
> ion_handle.
> + * If no ion_handle exists for this buffer, return newly created
> ion_handle.
> + * If dma-buf from another exporter is passed, return
> ERR_PTR(-EINVAL)
> + */
> +struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> + struct dma_buf *dmabuf);
> +
> +/**
>
Re: [PATCH] staging: gasket: Use octal permissions instead of symbolic.
On Tue, Nov 06, 2018 at 09:12:45PM +0100, Greg KH wrote:
> On Tue, Nov 06, 2018 at 04:33:47PM +0530, Rohit Sarkar wrote:
> > Replace S_IRUGO with 0444. Issue found by checkpatch.
> >
> > Signed-off-by: Rohit Sarkar
> > ---
> > drivers/staging/gasket/gasket_sysfs.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/gasket/gasket_sysfs.h
> > b/drivers/staging/gasket/gasket_sysfs.h
> > index 151e8edd28ea..60590ea4b760 100644
> > --- a/drivers/staging/gasket/gasket_sysfs.h
> > +++ b/drivers/staging/gasket/gasket_sysfs.h
> > @@ -40,7 +40,7 @@
> > */
> > #define GASKET_END_OF_ATTR_ARRAY
> > \
> > { \
> > - .attr = __ATTR(GASKET_ARRAY_END_TOKEN, S_IRUGO, NULL, NULL), \
> > + .attr = __ATTR(GASKET_ARRAY_END_TOKEN, 0444, NULL, NULL), \
> > .data.attr_type = 0, \
>
> No, this horrid #define needs to just be removed entirely, it's not
> really needed at all.
>
> > }
> >
> > @@ -75,7 +75,7 @@ struct gasket_sysfs_attribute {
> >
> > #define GASKET_SYSFS_RO(_name, _show_function, _attr_type)
> > \
> > { \
> > - .attr = __ATTR(_name, S_IRUGO, _show_function, NULL), \
> > + .attr = __ATTR(_name, 0444, _show_function, NULL), \
>
> __ATTR_RO() please.
>
> Or just fix it up so this isn't needed at all, the sysfs usage in this
> driver needs major work (i.e. almost deleted entirely...)
>
> thanks,
>
> greg k-h
Hey,
I am relatively new to the community and I was searching for things
to work on. I would love to help with this. Do you think this would be
a good task for me to get started with as I cannot seem to guage the
difficulty of this.
Thanks,
Rohit Sarkar
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: pi433: Fix typo in documentation
Fixes a typo in the documentation. Signed-off-by: Rohit Sarkar --- drivers/staging/pi433/Documentation/pi433.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/pi433/Documentation/pi433.txt b/drivers/staging/pi433/Documentation/pi433.txt index 21cffdb86ecf..4a0d34b4ad37 100644 --- a/drivers/staging/pi433/Documentation/pi433.txt +++ b/drivers/staging/pi433/Documentation/pi433.txt @@ -14,7 +14,7 @@ until something gets received terminates the read request. The driver supports on the fly reloading of the hardware fifo of the rf chip, thus enabling for much longer telegrams than the hardware fifo size. -Discription of driver operation +Description of driver operation === a) transmission -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192u: ieee80211: Replace snprintf with scnprintf
When the number of bytes to be printed exceeds the limit snprintf
returns the number of bytes that would have been printed (if there was
no truncation). This might cause issues, hence use scnprintf which
returns the actual number of bytes printed to buffer always.
Signed-off-by: Rohit Sarkar
---
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 4 ++--
drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index 0a3e478fccd6..b0a78508f378 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -1647,7 +1647,7 @@ int ieee80211_parse_info_param(struct ieee80211_device
*ieee,
for (i = 0; i < network->rates_len; i++) {
network->rates[i] = info_element->data[i];
#ifdef CONFIG_IEEE80211_DEBUG
- p += snprintf(p, sizeof(rates_str) -
+ p += scnprintf(p, sizeof(rates_str) -
(p - rates_str), "%02X ",
network->rates[i]);
#endif
@@ -1674,7 +1674,7 @@ int ieee80211_parse_info_param(struct ieee80211_device
*ieee,
for (i = 0; i < network->rates_ex_len; i++) {
network->rates_ex[i] = info_element->data[i];
#ifdef CONFIG_IEEE80211_DEBUG
- p += snprintf(p, sizeof(rates_str) -
+ p += scnprintf(p, sizeof(rates_str) -
(p - rates_str), "%02X ",
network->rates_ex[i]);
#endif
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index be08cd1d37a7..8f378ba0e62a 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -109,7 +109,7 @@ static inline char *rtl819x_translate_scan(struct
ieee80211_device *ieee,
/* Add basic and extended rates */
max_rate = 0;
p = custom;
- p += snprintf(p, MAX_CUSTOM_LEN - (p - custom), " Rates (Mb/s): ");
+ p += scnprintf(p, MAX_CUSTOM_LEN - (p - custom), " Rates (Mb/s): ");
for (i = 0, j = 0; i < network->rates_len; ) {
if (j < network->rates_ex_len &&
((network->rates_ex[j] & 0x7F) <
@@ -119,12 +119,12 @@ static inline char *rtl819x_translate_scan(struct
ieee80211_device *ieee,
rate = network->rates[i++] & 0x7F;
if (rate > max_rate)
max_rate = rate;
- p += snprintf(p, MAX_CUSTOM_LEN - (p - custom),
+ p += scnprintf(p, MAX_CUSTOM_LEN - (p - custom),
"%d%s ", rate >> 1, (rate & 1) ? ".5" : "");
}
for (; j < network->rates_ex_len; j++) {
rate = network->rates_ex[j] & 0x7F;
- p += snprintf(p, MAX_CUSTOM_LEN - (p - custom),
+ p += scnprintf(p, MAX_CUSTOM_LEN - (p - custom),
"%d%s ", rate >> 1, (rate & 1) ? ".5" : "");
if (rate > max_rate)
max_rate = rate;
@@ -215,7 +215,7 @@ static inline char *rtl819x_translate_scan(struct
ieee80211_device *ieee,
* for given network. */
iwe.cmd = IWEVCUSTOM;
p = custom;
- p += snprintf(p, MAX_CUSTOM_LEN - (p - custom),
+ p += scnprintf(p, MAX_CUSTOM_LEN - (p - custom),
" Last beacon: %lums ago", (jiffies -
network->last_scanned) / (HZ / 100));
iwe.u.data.length = p - custom;
if (iwe.u.data.length)
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8712: Replace snprintf with scnprintf
When the number of bytes to be printed exceeds the limit snprintf
returns the number of bytes that would have been printed (if there was
no truncation). This might cause issues, hence use scnprintf which
returns the actual number of bytes printed to buffer always.
Signed-off-by: Rohit Sarkar
---
drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index b08b9a191a34..ff5edcaba64d 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -142,7 +142,7 @@ static noinline_for_stack char *translate_scan_wpa(struct
iw_request_info *info,
memset(buf, 0, MAX_WPA_IE_LEN);
n = sprintf(buf, "wpa_ie=");
for (i = 0; i < wpa_len; i++) {
- n += snprintf(buf + n, MAX_WPA_IE_LEN - n,
+ n += scnprintf(buf + n, MAX_WPA_IE_LEN - n,
"%02x", wpa_ie[i]);
if (n >= MAX_WPA_IE_LEN)
break;
@@ -162,7 +162,7 @@ static noinline_for_stack char *translate_scan_wpa(struct
iw_request_info *info,
memset(buf, 0, MAX_WPA_IE_LEN);
n = sprintf(buf, "rsn_ie=");
for (i = 0; i < rsn_len; i++) {
- n += snprintf(buf + n, MAX_WPA_IE_LEN - n,
+ n += scnprintf(buf + n, MAX_WPA_IE_LEN - n,
"%02x", rsn_ie[i]);
if (n >= MAX_WPA_IE_LEN)
break;
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8712: Replace snprintf with scnprintf
Resending as I made a typo in Larry's email id.
On Wed, Sep 11, 2019 at 12:19:31AM +0530, Rohit Sarkar wrote:
> When the number of bytes to be printed exceeds the limit snprintf
> returns the number of bytes that would have been printed (if there was
> no truncation). This might cause issues, hence use scnprintf which
> returns the actual number of bytes printed to buffer always.
>
> Signed-off-by: Rohit Sarkar
> ---
> drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> index b08b9a191a34..ff5edcaba64d 100644
> --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> @@ -142,7 +142,7 @@ static noinline_for_stack char *translate_scan_wpa(struct
> iw_request_info *info,
> memset(buf, 0, MAX_WPA_IE_LEN);
> n = sprintf(buf, "wpa_ie=");
> for (i = 0; i < wpa_len; i++) {
> - n += snprintf(buf + n, MAX_WPA_IE_LEN - n,
> + n += scnprintf(buf + n, MAX_WPA_IE_LEN - n,
> "%02x", wpa_ie[i]);
> if (n >= MAX_WPA_IE_LEN)
> break;
> @@ -162,7 +162,7 @@ static noinline_for_stack char *translate_scan_wpa(struct
> iw_request_info *info,
> memset(buf, 0, MAX_WPA_IE_LEN);
> n = sprintf(buf, "rsn_ie=");
> for (i = 0; i < rsn_len; i++) {
> - n += snprintf(buf + n, MAX_WPA_IE_LEN - n,
> + n += scnprintf(buf + n, MAX_WPA_IE_LEN - n,
> "%02x", rsn_ie[i]);
> if (n >= MAX_WPA_IE_LEN)
> break;
> --
> 2.17.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vhciq_core: replace snprintf with scnprintf
When the number of bytes to be printed exceeds the limit snprintf
returns the number of bytes that would have been printed (if there was
no truncation). This might cause issues, hence use scnprintf which
returns the actual number of bytes printed to buffer always
Signed-off-by: Rohit Sarkar
---
.../interface/vchiq_arm/vchiq_core.c | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 183f5cf887e0..56a23a297fa4 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -3322,13 +3322,13 @@ vchiq_dump_shared_state(void *dump_context, struct
vchiq_state *state,
char buf[80];
int len;
- len = snprintf(buf, sizeof(buf),
+ len = scnprintf(buf, sizeof(buf),
" %s: slots %d-%d tx_pos=%x recycle=%x",
label, shared->slot_first, shared->slot_last,
shared->tx_pos, shared->slot_queue_recycle);
vchiq_dump(dump_context, buf, len + 1);
- len = snprintf(buf, sizeof(buf),
+ len = scnprintf(buf, sizeof(buf),
"Slots claimed:");
vchiq_dump(dump_context, buf, len + 1);
@@ -3336,7 +3336,7 @@ vchiq_dump_shared_state(void *dump_context, struct
vchiq_state *state,
struct vchiq_slot_info slot_info =
*SLOT_INFO_FROM_INDEX(state, i);
if (slot_info.use_count != slot_info.release_count) {
- len = snprintf(buf, sizeof(buf),
+ len = scnprintf(buf, sizeof(buf),
" %d: %d/%d", i, slot_info.use_count,
slot_info.release_count);
vchiq_dump(dump_context, buf, len + 1);
@@ -3344,7 +3344,7 @@ vchiq_dump_shared_state(void *dump_context, struct
vchiq_state *state,
}
for (i = 1; i < shared->debug[DEBUG_ENTRIES]; i++) {
- len = snprintf(buf, sizeof(buf), "DEBUG: %s = %d(%x)",
+ len = scnprintf(buf, sizeof(buf), "DEBUG: %s = %d(%x)",
debug_names[i], shared->debug[i], shared->debug[i]);
vchiq_dump(dump_context, buf, len + 1);
}
@@ -3357,11 +3357,11 @@ vchiq_dump_state(void *dump_context, struct vchiq_state
*state)
int len;
int i;
- len = snprintf(buf, sizeof(buf), "State %d: %s", state->id,
+ len = scnprintf(buf, sizeof(buf), "State %d: %s", state->id,
conn_state_names[state->conn_state]);
vchiq_dump(dump_context, buf, len + 1);
- len = snprintf(buf, sizeof(buf),
+ len = scnprintf(buf, sizeof(buf),
" tx_pos=%x(@%pK), rx_pos=%x(@%pK)",
state->local->tx_pos,
state->tx_data + (state->local_tx_pos & VCHIQ_SLOT_MASK),
@@ -3369,13 +3369,13 @@ vchiq_dump_state(void *dump_context, struct vchiq_state
*state)
state->rx_data + (state->rx_pos & VCHIQ_SLOT_MASK));
vchiq_dump(dump_context, buf, len + 1);
- len = snprintf(buf, sizeof(buf),
+ len = scnprintf(buf, sizeof(buf),
" Version: %d (min %d)",
VCHIQ_VERSION, VCHIQ_VERSION_MIN);
vchiq_dump(dump_context, buf, len + 1);
if (VCHIQ_ENABLE_STATS) {
- len = snprintf(buf, sizeof(buf),
+ len = scnprintf(buf, sizeof(buf),
" Stats: ctrl_tx_count=%d, ctrl_rx_count=%d, "
"error_count=%d",
state->stats.ctrl_tx_count, state->stats.ctrl_rx_count,
@@ -3383,7 +3383,7 @@ vchiq_dump_state(void *dump_context, struct vchiq_state
*state)
vchiq_dump(dump_context, buf, len + 1);
}
- len = snprintf(buf, sizeof(buf),
+ len = scnprintf(buf, sizeof(buf),
" Slots: %d available (%d data), %d recyclable, %d stalls "
"(%d data)",
((state->slot_queue_available * VCHIQ_SLOT_SIZE) -
@@ -3416,7 +3416,7 @@ vchiq_dump_service_state(void *dump_context, struct
vchiq_service *service)
char buf[80];
int len;
- len = snprintf(buf, sizeof(buf), "Service %u: %s (ref %u)",
+ len = scnprintf(buf, sizeof(buf), "Service %u: %s (ref %u)",
service->localport, srvstate_names[service->srvstate],
service->ref_count - 1); /*Don't include the lock just taken*/
@@ -3428,17 +3428,17 @@ vchiq_dump_service_state(void *dump_context, struct
vchiq_service *service)
Re: [PATCH] staging: vhciq_core: replace snprintf with scnprintf
On Wed, Sep 11, 2019 at 04:17:25PM +0200, Stefan Wahren wrote: > Hi Rohit, > > On 11.09.19 15:51, Rohit Sarkar wrote: > > When the number of bytes to be printed exceeds the limit snprintf > > returns the number of bytes that would have been printed (if there was > > no truncation). This might cause issues, hence use scnprintf which > > returns the actual number of bytes printed to buffer always > > > > Signed-off-by: Rohit Sarkar > thanks for your patch. Did you test your change on the Raspberry Pi? Hey Stefan, No I haven't done so as I thought this is a generic change? Will that be necessary? I am relatively new to kernel development Thanks, Rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vhciq_core: replace snprintf with scnprintf
On Wed, Sep 11, 2019 at 05:46:12PM +0300, Dan Carpenter wrote: > On Wed, Sep 11, 2019 at 07:55:43PM +0530, Rohit Sarkar wrote: > > On Wed, Sep 11, 2019 at 04:17:25PM +0200, Stefan Wahren wrote: > > > Hi Rohit, > > > > > > On 11.09.19 15:51, Rohit Sarkar wrote: > > > > When the number of bytes to be printed exceeds the limit snprintf > > > > returns the number of bytes that would have been printed (if there was > > > > no truncation). This might cause issues, hence use scnprintf which > > > > returns the actual number of bytes printed to buffer always > > > > > > > > Signed-off-by: Rohit Sarkar > > > thanks for your patch. Did you test your change on the Raspberry Pi? > > > > Hey Stefan, > > No I haven't done so as I thought this is a generic change? > > Will that be necessary? > > No. It's not required. The patch is easy to audit and clearly > harmless. > > The question would be does it actually fix a bug? I looked at it and > some of the strings are definitely a bit long. The longest one I saw > was: > " Slots: %d available (%d data), %d recyclable, %d stalls (%d data)", > 123456789 123456789 123456789 123456789 123456789 123456789 123456789 > > If you get a lot of stalls, then that looks like it could lead to a > read overflow (an information leak). Either way this does make the > code a bit easier to audit so it seems like a nice cleanup. Next time > though, I really would prefer if you put this sort analysis in your > commit message so I can just glance over it. (I'm lazy). > > Reviewed-by: Dan Carpenter > > regards, > dan carpenter Hey Dan, Thanks for reviewing this :) I will make sure to add some analysis the next time I do a clean up like this. There are a lot of usages of "snprintf" throughout the staging directory (315 to be exact) Would it be worthwhile to find ones that may cause an information leak and replace them with "scnprintf"? Thanks, Rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vhciq_core: replace snprintf with scnprintf
On Wed, Sep 11, 2019 at 08:24:22PM +0300, Dan Carpenter wrote: > On Wed, Sep 11, 2019 at 08:33:00PM +0530, Rohit Sarkar wrote: > > There are a lot of usages of "snprintf" throughout the staging > > directory (315 to be exact) > > Would it be worthwhile to find ones that may cause an information leak > > and replace them with "scnprintf"? > > A lot of times it's really easy to see that the uses are safe, so > snprintf() is fine in that case. If it's not obviously safe then change > it. > > regards, > dan carpenter > Sure, thanks a ton! regards, Rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: iio: ADIS16240: Remove unused include
Bcc: Subject: [PATCH] staging: iio: adis16240: remove unused include Reply-To: '#include' isn't being used anywhere. Remove it. Signed-off-by: Rohit Sarkar --- drivers/staging/iio/accel/adis16240.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/iio/accel/adis16240.c b/drivers/staging/iio/accel/adis16240.c index 82099db4bf0c..a480409090c0 100644 --- a/drivers/staging/iio/accel/adis16240.c +++ b/drivers/staging/iio/accel/adis16240.c @@ -7,7 +7,6 @@ #include #include -#include #include #include #include -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ADIS16240: Remove unused include
On Sun, Sep 15, 2019 at 10:53:00AM +0100, Jonathan Cameron wrote: > On Sat, 14 Sep 2019 02:06:27 +0530 > Rohit Sarkar wrote: > > > Bcc: > > Subject: [PATCH] staging: iio: adis16240: remove unused include > > Reply-To: > Something odd happened here with patch formatting. I fixed it up and > applied to the togreg branch of iio.git and pushed out as testing > for the autobuilders to play with it. > > Thanks, > > Jonathan > That's my bad, must have messed up while copying over the recipients from another thread. Thanks, Rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hardware prerequisites for driver development
Hi, This is probably a real rookie question. I have been interested in contributing to the driver subsystems such as iio. I have submitted some minor patches but nothing substantial. I feel that I need some hardware to be able to contribute more. What hardware would I need to get started? Where would I get this from? Thanks, Rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Hardware prerequisites for driver development
On Wed, Sep 25, 2019 at 10:32:02AM +0200, Crt Mori wrote: > Hi Rohit, > There are many companies for hobbyists which sell sensors included in > IIO subsystem and for sure some electronic component store in your > local area. Price of sensor can be from 0.10 USD to 10 USD. Then you > plug this sensor to your Linux board (Beaglebone Black is Linux > Foundation preferred, although there are others including Raspberry PI > - can even be RPI Zero if you are on a budget, Odroid, Linaro, ...) > and you will need to provide correct voltage/current for the sensor. > Easiests is that you pick sensors which are 3.3V or 5V domains, > because you have pins on most Linux boards with this voltages and > these pins supply enough current for most iio sensors. Then you just > connect (wire) power pin on sensor to power pin on your board, and > then communication pins from sensor to board and ground from sensor to > board. Some addition into dts will be needed for the Linux to know > where your sensor is connected at, but then it should work as > plug-and-play. > > I hope I did not miss too many steps in between :) > > Crt Hi Crt, Thanks for replying, your answer was super detailed and helpful. Thanks, Rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8712: Replace snprintf with scnprintf
On Tue, Oct 01, 2019 at 11:45:14AM +0300, Dan Carpenter wrote:
> > diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > index b08b9a191a34..ff5edcaba64d 100644
> > --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> > @@ -142,7 +142,7 @@ static noinline_for_stack char
> > *translate_scan_wpa(struct iw_request_info *info,
> > memset(buf, 0, MAX_WPA_IE_LEN);
> > n = sprintf(buf, "wpa_ie=");
> > for (i = 0; i < wpa_len; i++) {
> > - n += snprintf(buf + n, MAX_WPA_IE_LEN - n,
> > + n += scnprintf(buf + n, MAX_WPA_IE_LEN - n,
> > "%02x", wpa_ie[i]);
> > if (n >= MAX_WPA_IE_LEN)
> ^^^
> It checks for overflow here. This check is impossible now and doesn't
> make sense. The other loop is similar.
Good catch! I must have overlooked this.
"n" cannot be greater than MAX_WPA_IE_LEN but it can be equal to that
value. We can replace the '>=' with '==' so that we don't loop
unnecessarily when n has reached it's threshold.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8712: Replace snprintf with scnprintf
On Tue, Oct 01, 2019 at 10:00:56PM +0300, Dan Carpenter wrote: > > No. scnprintf() returns the number of characters *not counting the > NUL terminator*. So it can be a maximum of MAX_WPA_IE_LEN - 1. > > regards, > dan carpenter TIL :) Would the better approach be to just remove the loop or break when n == MAX_WPA_IE_LEN - 1. regards, rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8712: Replace snprintf with scnprintf
On Wed, Oct 02, 2019 at 01:57:22PM +0300, Dan Carpenter wrote: > > We could leave it as is or change it to "MAX_WPA_IE_LEN - 1". But I > feel like the default should be to leave it as is unless there is a good > reason. Makes sense, although greg has already merged this. I guess I will remove the redundant check then. thanks, rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8712: Replace snprintf with scnprintf
On Wed, Oct 02, 2019 at 03:06:22PM +0300, Dan Carpenter wrote: > You could remove it, but I feel like it's better to check for > "== MAX_WPA_IE_LEN - 1". They're effectively the same, but to me it > feels cleaner to be explicit how we're handling truncated data. > > regards, > dan carpenter I feel the same way. Plus we would also avoid looping unnecessarily if "n" exceeds the threshold. Will send a patch asap. regards, rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8712: fix boundary condition for n
Now that snprintf is replaced by scnprintf n >= MAX_WPA_IE_LEN doesn't
make sense as the maximum value n can take is MAX_WPA_IE_LEN.
Signed-off-by: Rohit Sarkar
---
drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index b3263e953f05..363b82e3e7c6 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -144,7 +144,7 @@ static noinline_for_stack char *translate_scan_wpa(struct
iw_request_info *info,
for (i = 0; i < wpa_len; i++) {
n += scnprintf(buf + n, MAX_WPA_IE_LEN - n,
"%02x", wpa_ie[i]);
- if (n >= MAX_WPA_IE_LEN)
+ if (n == MAX_WPA_IE_LEN-1)
break;
}
memset(iwe, 0, sizeof(*iwe));
@@ -164,7 +164,7 @@ static noinline_for_stack char *translate_scan_wpa(struct
iw_request_info *info,
for (i = 0; i < rsn_len; i++) {
n += scnprintf(buf + n, MAX_WPA_IE_LEN - n,
"%02x", rsn_ie[i]);
- if (n >= MAX_WPA_IE_LEN)
+ if (n == MAX_WPA_IE_LEN-1)
break;
}
memset(iwe, 0, sizeof(*iwe));
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: iio: update TODO
gre...@linuxfoundation.org, ji...@kernel.org Bcc: Subject: [PATCH] staging: iio: update TODO Reply-To: Since there are no more uses of the old GPIO API in iio staging drivers remove that work item from the TODO. Add other work items with reference to the conversation in [1] [1]: https://marc.info/?l=linux-iio&m=158256721009892&w=2 Thanks, Rohit Signed-off-by: Rohit Sarkar --- drivers/staging/iio/TODO | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/staging/iio/TODO b/drivers/staging/iio/TODO index 1b8ebf2c1b69..783878f25f08 100644 --- a/drivers/staging/iio/TODO +++ b/drivers/staging/iio/TODO @@ -1,11 +1,13 @@ -2018-04-15 +2020-02-25 -All affected drivers: -Convert all uses of the old GPIO API from to the -GPIO descriptor API in and look up GPIO -lines from device tree, ACPI or board files, board files should -use . +- Documentation + - Binding docs for devices that are obviously used via device tree + - Yaml conversions for abandoned drivers + - ABI Documentation + - Audit driviers/iio/staging/Documentation +- Replace iio_dev->mlock by either a local lock or use iio_claim_direct. +(Requires analysis of the purpose of the lock.) ADI Drivers: CC the device-drivers-de...@blackfin.uclinux.org mailing list when -- 2.23.0.385.gbc12974a89 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: iio: update TODO
Since there are no uses of the old GPIO API, remove the item from the TODO and some new items. Changes from v1: Add work item mentioned by Alexandru in https://marc.info/?l=linux-iio&m=158261515624212&w=2 Signed-off-by: Rohit Sarkar --- drivers/staging/iio/TODO | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/staging/iio/TODO b/drivers/staging/iio/TODO index 1b8ebf2c1b69..e54510c2ef5f 100644 --- a/drivers/staging/iio/TODO +++ b/drivers/staging/iio/TODO @@ -1,11 +1,17 @@ -2018-04-15 +2020-02-25 -All affected drivers: -Convert all uses of the old GPIO API from to the -GPIO descriptor API in and look up GPIO -lines from device tree, ACPI or board files, board files should -use . +- Documentation + - Binding docs for devices that are obviously used via device tree + - Yaml conversions for abandoned drivers + - ABI Documentation + - Audit driviers/iio/staging/Documentation +- Replace iio_dev->mlock by either a local lock or use iio_claim_direct. + (Requires analysis of the purpose of the lock.) + +- Converting drivers from device tree centric to more generic property handlers + Refactor old platform_data constructs from drivers and convert it to state + struct and using property handlers and readers. ADI Drivers: CC the device-drivers-de...@blackfin.uclinux.org mailing list when -- 2.23.0.385.gbc12974a89 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: iio: update TODO
Since there are no uses of the old GPIO API, remove the item from the TODO. Changelog v3: Remove new items added. v2: Add work item mentioned by Alexandru in https://marc.info/?l=linux-iio&m=158261515624212&w=2 Signed-off-by: Rohit Sarkar --- drivers/staging/iio/TODO | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/staging/iio/TODO b/drivers/staging/iio/TODO index 1b8ebf2c1b69..4d469016a13a 100644 --- a/drivers/staging/iio/TODO +++ b/drivers/staging/iio/TODO @@ -1,10 +1,4 @@ -2018-04-15 - -All affected drivers: -Convert all uses of the old GPIO API from to the -GPIO descriptor API in and look up GPIO -lines from device tree, ACPI or board files, board files should -use . +2020-02-25 ADI Drivers: -- 2.23.0.385.gbc12974a89 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: iio: update TODO
On Sun, Mar 01, 2020 at 11:49:22AM +, Jonathan Cameron wrote: > On Sat, 29 Feb 2020 19:35:45 +0530 > Rohit Sarkar wrote: > > > Since there are no uses of the old GPIO API, remove the item from > > the TODO. > > > > Changelog > > v3: Remove new items added. > > v2: Add work item mentioned by Alexandru in > > https://marc.info/?l=linux-iio&m=158261515624212&w=2 > Change log belongs below the --- as we don't want this info in the > git history. I've tidied up and applied to the togreg branch of iio.git > (pushed out as testing for the autobuilders to play with it). Will keep that in mind, Thanks! > Thanks, > > Jonathan > > > > > Signed-off-by: Rohit Sarkar > > --- > > drivers/staging/iio/TODO | 8 +--- > > 1 file changed, 1 insertion(+), 7 deletions(-) > > > > diff --git a/drivers/staging/iio/TODO b/drivers/staging/iio/TODO > > index 1b8ebf2c1b69..4d469016a13a 100644 > > --- a/drivers/staging/iio/TODO > > +++ b/drivers/staging/iio/TODO > > @@ -1,10 +1,4 @@ > > -2018-04-15 > > - > > -All affected drivers: > > -Convert all uses of the old GPIO API from to the > > -GPIO descriptor API in and look up GPIO > > -lines from device tree, ACPI or board files, board files should > > -use . > > +2020-02-25 > > > > > > ADI Drivers: > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging/ion: Add support to get ion handle from dma buf
Currently we can only import dma buf fd's to get ion_handle.
Adding support to import dma buf handles to support kernel
specific use cases.
Signed-off-by: Rohit kumar
---
Currently, ION is the memory manager for graphics in android. However,
in other linux platforms such as Tizen, DRM-GEM is used for buffer
management for graphics. It has gem_handle corresponding to a buffer
and uses gem_name for sharing the buffer with other processes. However,
it also uses dma_buf fd for 3d operations. For wayland, there are
multiple calls for gem_handle to dma_buf fd conversion. So, we store
dma_buf associated with buffer. But, there is no api for getting
ion_handle from dma_buf. This patch exposes api to retrieve the ion
handle from dma_buf for similar use cases. With this patch, we can
integrate ION within DRM-GEM for buffer management and dma_buf sharing.
drivers/staging/android/ion/ion.c | 21 +++--
drivers/staging/android/ion/ion.h | 20
2 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index e237e9f..5509716 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1151,16 +1151,13 @@ int ion_share_dma_buf_fd(struct ion_client *client,
struct ion_handle *handle)
}
EXPORT_SYMBOL(ion_share_dma_buf_fd);
-struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd)
+struct ion_handle *ion_import_dma_buf(struct ion_client *client,
+ struct dma_buf *dmabuf)
{
- struct dma_buf *dmabuf;
struct ion_buffer *buffer;
struct ion_handle *handle;
int ret;
- dmabuf = dma_buf_get(fd);
- if (IS_ERR(dmabuf))
- return ERR_CAST(dmabuf);
/* if this memory came from ion */
if (dmabuf->ops != &dma_buf_ops) {
@@ -1199,6 +1196,18 @@ end:
}
EXPORT_SYMBOL(ion_import_dma_buf);
+struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
+{
+ struct dma_buf *dmabuf;
+
+ dmabuf = dma_buf_get(fd);
+ if (IS_ERR(dmabuf))
+ return ERR_CAST(dmabuf);
+
+ return ion_import_dma_buf(client, dmabuf);
+}
+EXPORT_SYMBOL(ion_import_dma_buf_fd);
+
static int ion_sync_for_device(struct ion_client *client, int fd)
{
struct dma_buf *dmabuf;
@@ -1306,7 +1315,7 @@ static long ion_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
{
struct ion_handle *handle;
- handle = ion_import_dma_buf(client, data.fd.fd);
+ handle = ion_import_dma_buf_fd(client, data.fd.fd);
if (IS_ERR(handle))
ret = PTR_ERR(handle);
else
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index b860c5f..a1331fc 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -192,14 +192,26 @@ struct dma_buf *ion_share_dma_buf(struct ion_client
*client,
int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle);
/**
- * ion_import_dma_buf() - given an dma-buf fd from the ion exporter get handle
+ * ion_import_dma_buf() - get ion_handle from dma-buf
+ * @client:the client
+ * @dmabuf:the dma-buf
+ *
+ * Get the ion_buffer associated with the dma-buf and return the ion_handle.
+ * If no ion_handle exists for this buffer, return newly created ion_handle.
+ * If dma-buf from another exporter is passed, return ERR_PTR(-EINVAL)
+ */
+struct ion_handle *ion_import_dma_buf(struct ion_client *client,
+ struct dma_buf *dmabuf);
+
+/**
+ * ion_import_dma_buf_fd() - given a dma-buf fd from the ion exporter get
handle
* @client:the client
* @fd:the dma-buf fd
*
- * Given an dma-buf fd that was allocated through ion via ion_share_dma_buf,
- * import that fd and return a handle representing it. If a dma-buf from
+ * Given an dma-buf fd that was allocated through ion via ion_share_dma_buf_fd,
+ * import that fd and return a handle representing it. If a dma-buf from
* another exporter is passed in this function will return ERR_PTR(-EINVAL)
*/
-struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd);
+struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd);
#endif /* _LINUX_ION_H */
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2 1/1] staging/ion: Add support to get ion handle from dma buf
Currently we can only import dma buf fd's to get ion_handle.
Adding support to import dma buf handles to support kernel
specific use cases.
An example use case is in linux platforms such as Tizen, in which
DRM-GEM is used for buffer management for graphics. It has gem_handle
corresponding to a buffer and uses gem_name for sharing the buffer
with other processes. However,it also uses dma_buf fd for 3d operations.
For wayland, there are multiple calls for gem_handle to dma_buf fd
conversion. So, we store dma_buf associated with buffer. But, there is
no api for getting ion_handle from dma_buf. This patch exposes api to
retrieve the ion handle from dma_buf for similar use cases. With this
patch, we can integrate ION within DRM-GEM for buffer management and
dma_buf sharing.
Signed-off-by: Rohit kumar
---
v2: Updated commit message with use case explanation, as suggested by
Laura Abbott
drivers/staging/android/ion/ion.c | 21 +++--
drivers/staging/android/ion/ion.h | 20
2 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index e237e9f..5509716 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1151,16 +1151,13 @@ int ion_share_dma_buf_fd(struct ion_client *client,
struct ion_handle *handle)
}
EXPORT_SYMBOL(ion_share_dma_buf_fd);
-struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd)
+struct ion_handle *ion_import_dma_buf(struct ion_client *client,
+ struct dma_buf *dmabuf)
{
- struct dma_buf *dmabuf;
struct ion_buffer *buffer;
struct ion_handle *handle;
int ret;
- dmabuf = dma_buf_get(fd);
- if (IS_ERR(dmabuf))
- return ERR_CAST(dmabuf);
/* if this memory came from ion */
if (dmabuf->ops != &dma_buf_ops) {
@@ -1199,6 +1196,18 @@ end:
}
EXPORT_SYMBOL(ion_import_dma_buf);
+struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
+{
+ struct dma_buf *dmabuf;
+
+ dmabuf = dma_buf_get(fd);
+ if (IS_ERR(dmabuf))
+ return ERR_CAST(dmabuf);
+
+ return ion_import_dma_buf(client, dmabuf);
+}
+EXPORT_SYMBOL(ion_import_dma_buf_fd);
+
static int ion_sync_for_device(struct ion_client *client, int fd)
{
struct dma_buf *dmabuf;
@@ -1306,7 +1315,7 @@ static long ion_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
{
struct ion_handle *handle;
- handle = ion_import_dma_buf(client, data.fd.fd);
+ handle = ion_import_dma_buf_fd(client, data.fd.fd);
if (IS_ERR(handle))
ret = PTR_ERR(handle);
else
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index b860c5f..a1331fc 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -192,14 +192,26 @@ struct dma_buf *ion_share_dma_buf(struct ion_client
*client,
int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle);
/**
- * ion_import_dma_buf() - given an dma-buf fd from the ion exporter get handle
+ * ion_import_dma_buf() - get ion_handle from dma-buf
+ * @client:the client
+ * @dmabuf:the dma-buf
+ *
+ * Get the ion_buffer associated with the dma-buf and return the ion_handle.
+ * If no ion_handle exists for this buffer, return newly created ion_handle.
+ * If dma-buf from another exporter is passed, return ERR_PTR(-EINVAL)
+ */
+struct ion_handle *ion_import_dma_buf(struct ion_client *client,
+ struct dma_buf *dmabuf);
+
+/**
+ * ion_import_dma_buf_fd() - given a dma-buf fd from the ion exporter get
handle
* @client:the client
* @fd:the dma-buf fd
*
- * Given an dma-buf fd that was allocated through ion via ion_share_dma_buf,
- * import that fd and return a handle representing it. If a dma-buf from
+ * Given an dma-buf fd that was allocated through ion via ion_share_dma_buf_fd,
+ * import that fd and return a handle representing it. If a dma-buf from
* another exporter is passed in this function will return ERR_PTR(-EINVAL)
*/
-struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd);
+struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd);
#endif /* _LINUX_ION_H */
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv3 1/1] staging/ion: Add support to get ion handle from dma buf
Currently we can only import dma buf fd's to get ion_handle.
Adding support to import dma buf handles to support kernel
specific use cases.
An example use case is in linux platforms such as Tizen, in which
DRM-GEM is used for buffer management for graphics. It has gem_handle
corresponding to a buffer and uses gem_name for sharing the buffer
with other processes. However,it also uses dma_buf fd for 3d operations.
For wayland, there are multiple calls for gem_handle to dma_buf fd
conversion. So, we store dma_buf associated with buffer. But, there is
no api for getting ion_handle from dma_buf. This patch exposes api to
retrieve the ion handle from dma_buf for similar use cases. With this
patch, we can integrate ION within DRM-GEM for buffer management and
dma_buf sharing.
Signed-off-by: Rohit kumar
---
v2: Updated commit message with use case explanation, as suggested by
Laura Abbott
v3: Fixed dmabuf refcount issue in ion_import_dma_buf. dma_buf_put()
was being called without dma_buf_get(), so moving it to
ion_import_dma_buf_fd().
drivers/staging/android/ion/ion.c | 26 ++
drivers/staging/android/ion/ion.h | 20
2 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index e237e9f..7e86e18 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1151,22 +1151,18 @@ int ion_share_dma_buf_fd(struct ion_client *client,
struct ion_handle *handle)
}
EXPORT_SYMBOL(ion_share_dma_buf_fd);
-struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd)
+struct ion_handle *ion_import_dma_buf(struct ion_client *client,
+ struct dma_buf *dmabuf)
{
- struct dma_buf *dmabuf;
struct ion_buffer *buffer;
struct ion_handle *handle;
int ret;
- dmabuf = dma_buf_get(fd);
- if (IS_ERR(dmabuf))
- return ERR_CAST(dmabuf);
/* if this memory came from ion */
if (dmabuf->ops != &dma_buf_ops) {
pr_err("%s: can not import dmabuf from another exporter\n",
__func__);
- dma_buf_put(dmabuf);
return ERR_PTR(-EINVAL);
}
buffer = dmabuf->priv;
@@ -1194,11 +1190,25 @@ struct ion_handle *ion_import_dma_buf(struct ion_client
*client, int fd)
}
end:
- dma_buf_put(dmabuf);
return handle;
}
EXPORT_SYMBOL(ion_import_dma_buf);
+struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
+{
+ struct dma_buf *dmabuf;
+ struct ion_handle *handle;
+
+ dmabuf = dma_buf_get(fd);
+ if (IS_ERR(dmabuf))
+ return ERR_CAST(dmabuf);
+
+ handle = ion_import_dma_buf(client, dmabuf);
+ dma_buf_put(dmabuf);
+ return handle;
+}
+EXPORT_SYMBOL(ion_import_dma_buf_fd);
+
static int ion_sync_for_device(struct ion_client *client, int fd)
{
struct dma_buf *dmabuf;
@@ -1306,7 +1316,7 @@ static long ion_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
{
struct ion_handle *handle;
- handle = ion_import_dma_buf(client, data.fd.fd);
+ handle = ion_import_dma_buf_fd(client, data.fd.fd);
if (IS_ERR(handle))
ret = PTR_ERR(handle);
else
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index b860c5f..a1331fc 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -192,14 +192,26 @@ struct dma_buf *ion_share_dma_buf(struct ion_client
*client,
int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle);
/**
- * ion_import_dma_buf() - given an dma-buf fd from the ion exporter get handle
+ * ion_import_dma_buf() - get ion_handle from dma-buf
+ * @client:the client
+ * @dmabuf:the dma-buf
+ *
+ * Get the ion_buffer associated with the dma-buf and return the ion_handle.
+ * If no ion_handle exists for this buffer, return newly created ion_handle.
+ * If dma-buf from another exporter is passed, return ERR_PTR(-EINVAL)
+ */
+struct ion_handle *ion_import_dma_buf(struct ion_client *client,
+ struct dma_buf *dmabuf);
+
+/**
+ * ion_import_dma_buf_fd() - given a dma-buf fd from the ion exporter get
handle
* @client:the client
* @fd:the dma-buf fd
*
- * Given an dma-buf fd that was allocated through ion via ion_share_dma_buf,
- * import that fd and return a handle representing it. If a dma-buf from
+ * Given an dma-buf fd that was allocated through ion via ion_share_dma_buf_fd,
+ * import that fd and return a handle representing it. If a dma-buf from
* another exporter is passed in this function will return ERR_PTR(-EINVAL)
*/
-struct ion_handle *ion_import_dma_buf(struct ion_client
[PATCH 1/1] staging: ion: Fix error handling in ion_buffer_create
This patch fixes error handling case when buffer->pages allocation
fails. Also, it removes unreachable code of checking ret variable
although it is not updated.
Signed-off-by: Rohit kumar
---
drivers/staging/android/ion/ion.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 217aa53..af59e4a 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -213,10 +213,10 @@ static struct ion_buffer *ion_buffer_create(struct
ion_heap *heap,
"heap->ops->map_dma should return ERR_PTR on error"))
table = ERR_PTR(-EINVAL);
if (IS_ERR(table)) {
- heap->ops->free(buffer);
- kfree(buffer);
- return ERR_CAST(table);
+ ret = -EINVAL;
+ goto err1;
}
+
buffer->sg_table = table;
if (ion_buffer_fault_user_mappings(buffer)) {
int num_pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
@@ -226,7 +226,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap
*heap,
buffer->pages = vmalloc(sizeof(struct page *) * num_pages);
if (!buffer->pages) {
ret = -ENOMEM;
- goto err1;
+ goto err;
}
for_each_sg(table->sgl, sg, table->nents, i) {
@@ -235,9 +235,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap
*heap,
for (j = 0; j < sg->length / PAGE_SIZE; j++)
buffer->pages[k++] = page++;
}
-
- if (ret)
- goto err;
}
buffer->dev = dev;
@@ -261,9 +258,8 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap
*heap,
err:
heap->ops->unmap_dma(heap, buffer);
- heap->ops->free(buffer);
err1:
- vfree(buffer->pages);
+ heap->ops->free(buffer);
err2:
kfree(buffer);
return ERR_PTR(ret);
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] staging: xm2mvscale: Add TODO for the driver
This commit highlights the key functionalities that will be improved upon in a future patch set. Signed-off-by: Rohit Athavale --- drivers/staging/xm2mvscale/TODO | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 drivers/staging/xm2mvscale/TODO diff --git a/drivers/staging/xm2mvscale/TODO b/drivers/staging/xm2mvscale/TODO new file mode 100644 index 000..ba5fd23 --- /dev/null +++ b/drivers/staging/xm2mvscale/TODO @@ -0,0 +1,15 @@ +* Possible remaining coding style fix. +* Add support for DMABUF. +* This is an early prototype, hardware register map changes are expected. +* Update driver for 64-bit DMA address once the new Xilinx M2M Scaler IP + has support for 64-bit DMA Addresses. Current IP supports 32-bit DMA addresses. +* Remove deadcode. +* Add documents in Documentation beyond the DT binding doc. +* This needs a home in the proper drivers area (example : drivers/misc/), + once the quality of the driver is improved. Suggestions about where + it should be placed are welcome. +* The IOCTL header could be moved to an uapi/* area once this is out of staging. + +Please send any patches to: +Greg Kroah-Hartman and Rohit Athavale + -- 1.9.1 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] staging: xm2mvscale: Driver support for Xilinx M2M Video Scaler
This commit adds driver support for the pre-release Xilinx M2M Video
Scaler IP. There are three parts to this driver :
- The Hardware/IP layer that reads and writes register of the IP
contained in the scaler_hw_xm2m.c
- The set of ioctls that applications would need to know contained
in ioctl_xm2mvsc.h
- The char driver that consumes the IP layer in xm2m_vscale.c
Signed-off-by: Rohit Athavale
---
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 1 +
drivers/staging/xm2mvscale/Kconfig| 12 +
drivers/staging/xm2mvscale/Makefile | 3 +
drivers/staging/xm2mvscale/ioctl_xm2mvsc.h| 134
drivers/staging/xm2mvscale/scaler_hw_xm2m.c | 945 ++
drivers/staging/xm2mvscale/scaler_hw_xm2m.h | 152 +
drivers/staging/xm2mvscale/xm2m_vscale.c | 783 +
drivers/staging/xm2mvscale/xvm2mvsc_hw_regs.h | 204 ++
9 files changed, 2236 insertions(+)
create mode 100644 drivers/staging/xm2mvscale/Kconfig
create mode 100644 drivers/staging/xm2mvscale/Makefile
create mode 100644 drivers/staging/xm2mvscale/ioctl_xm2mvsc.h
create mode 100644 drivers/staging/xm2mvscale/scaler_hw_xm2m.c
create mode 100644 drivers/staging/xm2mvscale/scaler_hw_xm2m.h
create mode 100644 drivers/staging/xm2mvscale/xm2m_vscale.c
create mode 100644 drivers/staging/xm2mvscale/xvm2mvsc_hw_regs.h
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index e95ab68..3ee3a3e 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -122,4 +122,6 @@ source "drivers/staging/vboxvideo/Kconfig"
source "drivers/staging/pi433/Kconfig"
+source "drivers/staging/xm2mvscale/Kconfig"
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index af8cd6a..29ce417 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -52,3 +52,4 @@ obj-$(CONFIG_BCM2835_VCHIQ) += vc04_services/
obj-$(CONFIG_CRYPTO_DEV_CCREE) += ccree/
obj-$(CONFIG_DRM_VBOXVIDEO)+= vboxvideo/
obj-$(CONFIG_PI433)+= pi433/
+obj-$(CONFIG_XILINX_M2M_VSC) += xm2mvscale/
diff --git a/drivers/staging/xm2mvscale/Kconfig
b/drivers/staging/xm2mvscale/Kconfig
new file mode 100644
index 000..68ccbca
--- /dev/null
+++ b/drivers/staging/xm2mvscale/Kconfig
@@ -0,0 +1,12 @@
+config XILINX_M2M_VSC
+ tristate "Xilinx M2M Video Scaler"
+ depends on ARCH_ZYNQMP && OF
+ select DMA_SHARED_BUFFER
+ ---help---
+ This driver is developed for Xilinx M2M Video Scaler IP,
+ designed to allow passage of frame buffers from the source
+ kernel sub-system, apply video scaling and forward to the
+ sink kernel sub-system.
+
+ To compile this driver as a module, choose M here.
+ If unsure, choose N.
diff --git a/drivers/staging/xm2mvscale/Makefile
b/drivers/staging/xm2mvscale/Makefile
new file mode 100644
index 000..ec777e1
--- /dev/null
+++ b/drivers/staging/xm2mvscale/Makefile
@@ -0,0 +1,3 @@
+xm2m_vscale_drv-y := scaler_hw_xm2m.o
+xm2m_vscale_drv-y += xm2m_vscale.o
+obj-$(CONFIG_XILINX_M2M_VSC) += xm2m_vscale_drv.o
diff --git a/drivers/staging/xm2mvscale/ioctl_xm2mvsc.h
b/drivers/staging/xm2mvscale/ioctl_xm2mvsc.h
new file mode 100644
index 000..03bd7ab
--- /dev/null
+++ b/drivers/staging/xm2mvscale/ioctl_xm2mvsc.h
@@ -0,0 +1,134 @@
+/*
+ * Xilinx Memory-to-Memory Video Scaler IP
+ *
+ * Copyright (C) 2018 Xilinx, Inc. All rights reserved.
+ *
+ * SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+ */
+#ifndef __IOCTL_XM2MVSC_H__
+#define __IOCTL_XM2MVSC_H__
+
+/* Xilinx Video Specific Color/Pixel Formats */
+enum xm2mvsc_pix_fmt {
+ XILINX_FRMBUF_FMT_RGBX8 = 10,
+ XILINX_FRMBUF_FMT_YUVX8,
+ XILINX_FRMBUF_FMT_YUYV8,
+ XILINX_FRMBUF_FMT_RGBA8,
+ XILINX_FRMBUF_FMT_YUVA8,
+ XILINX_FRMBUF_FMT_RGBX10,
+ XILINX_FRMBUF_FMT_YUVX10,
+ /* RGB565 takes the value of 17 */
+ XILINX_FRMBUF_FMT_Y_UV8 = 18,
+ XILINX_FRMBUF_FMT_Y_UV8_420,
+ XILINX_FRMBUF_FMT_RGB8,
+ XILINX_FRMBUF_FMT_YUV8,
+ XILINX_FRMBUF_FMT_Y_UV10,
+ XILINX_FRMBUF_FMT_Y_UV10_420,
+ XILINX_FRMBUF_FMT_Y8,
+ XILINX_FRMBUF_FMT_Y10,
+ XILINX_FRMBUF_FMT_BGRA8,
+ XILINX_FRMBUF_FMT_BGRX8,
+ XILINX_FRMBUF_FMT_UYVY8,
+ XILINX_FRMBUF_FMT_BGR8,
+};
+
+/* struct xm2mvsc_qdata - Struct to enqueue a descriptor
+ * @srcbuf_ht: Height of source buffer
+ * @srcbuf_wt: Width of source buffer
+ * @srcbuf_bpp: Bytes per pixel of source buffer
+ * @srcbuf_cft: Color/Pixel format of source buffer
+ * @srcbuf_size: Size of the source buffer requested
+ * @srcbuf_mmap: Identify if srcbuf is mmap'ed
+ * @srcbuf_stride: Stride of the source buffer
+ * @dstbuf_ht: Height of destination buffer
+ * @dstbuf_wt: Width of destination buffer
+ * @dstbuf_bpp: Bytes per pixel of destination buffer
[PATCH 3/3] Documentation: devicetree: bindings: Add DT binding doc for xm2mvsc driver
This commit adds the binding doc for the DT that the driver expects.
Driver has been tested against Zynq US+ board.
Signed-off-by: Rohit Athavale
---
.../devicetree/bindings/xm2mvscaler.txt| 25 ++
1 file changed, 25 insertions(+)
create mode 100644
drivers/staging/xm2mvscale/Documentation/devicetree/bindings/xm2mvscaler.txt
diff --git
a/drivers/staging/xm2mvscale/Documentation/devicetree/bindings/xm2mvscaler.txt
b/drivers/staging/xm2mvscale/Documentation/devicetree/bindings/xm2mvscaler.txt
new file mode 100644
index 000..1f3d805
--- /dev/null
+++
b/drivers/staging/xm2mvscale/Documentation/devicetree/bindings/xm2mvscaler.txt
@@ -0,0 +1,25 @@
+Xilinx M2M Video Scaler
+---
+This document describes the DT bindings required by the
+Xilinx M2M Video Scaler driver.
+
+Required Properties:
+- compatible : Must be "xlnx,v-m2m-scaler"
+- reg : Memory map for module access
+- reset-gpios : Should contain GPIO reset phandle
+- interrupt-parent : Interrupt controller the interrupt is routed through
+- interrupts : Should contain DMA channel interrupt
+- xlnx,scaler-num-taps : The number of filter taps for scaling filter
+- xlnx,scaler-max-chan : The maximum number of supported scaling channels
+
+Examples
+-
+ v_multi_scaler: v_multi_scaler@a000 {
+ compatible = "xlnx,v-m2m-scaler";
+ reg = <0x0 0xa000 0x0 0x1>;
+ reset-gpios = <&gpio 78 1>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 89 4>;
+ xlnx,scaler-num-taps = <6>;
+ xlnx,scaler-max-chan = <4>;
+ };
--
1.9.1
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/3] Initial driver support for Xilinx M2M Video Scaler
This patch series has three commits : - Driver support for the Xilinx M2M Video Scaler IP - TODO document - DT binding doc Changes in HW register map is expected as the IP undergoes changes. This is a first attempt at the driver as an early prototype. This is a M2M Video Scaler IP that uses polyphases filters to perform video scaling. The driver will be used by an application like a gstreamer plugin. Rohit Athavale (3): staging: xm2mvscale: Driver support for Xilinx M2M Video Scaler staging: xm2mvscale: Add TODO for the driver Documentation: devicetree: bindings: Add DT binding doc for xm2mvsc driver drivers/staging/Kconfig| 2 + drivers/staging/Makefile | 1 + .../devicetree/bindings/xm2mvscaler.txt| 25 + drivers/staging/xm2mvscale/Kconfig | 12 + drivers/staging/xm2mvscale/Makefile| 3 + drivers/staging/xm2mvscale/TODO| 15 + drivers/staging/xm2mvscale/ioctl_xm2mvsc.h | 134 +++ drivers/staging/xm2mvscale/scaler_hw_xm2m.c| 945 + drivers/staging/xm2mvscale/scaler_hw_xm2m.h| 152 drivers/staging/xm2mvscale/xm2m_vscale.c | 783 + drivers/staging/xm2mvscale/xvm2mvsc_hw_regs.h | 204 + 11 files changed, 2276 insertions(+) create mode 100644 drivers/staging/xm2mvscale/Documentation/devicetree/bindings/xm2mvscaler.txt create mode 100644 drivers/staging/xm2mvscale/Kconfig create mode 100644 drivers/staging/xm2mvscale/Makefile create mode 100644 drivers/staging/xm2mvscale/TODO create mode 100644 drivers/staging/xm2mvscale/ioctl_xm2mvsc.h create mode 100644 drivers/staging/xm2mvscale/scaler_hw_xm2m.c create mode 100644 drivers/staging/xm2mvscale/scaler_hw_xm2m.h create mode 100644 drivers/staging/xm2mvscale/xm2m_vscale.c create mode 100644 drivers/staging/xm2mvscale/xvm2mvsc_hw_regs.h -- 1.9.1 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/3] staging: xm2mvscale: Driver support for Xilinx M2M Video Scaler
Hi Dan, Thanks for taking a look. I have added a tweak to add to the patch series. Will CC linux-media on the V2 and add a note about this in the cover letter. Best Regards, Rohit > -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Wednesday, February 21, 2018 12:27 AM > To: Rohit Athavale > Cc: de...@driverdev.osuosl.org; gre...@linuxfoundation.org > Subject: Re: [PATCH 1/3] staging: xm2mvscale: Driver support for Xilinx M2M > Video > Scaler > > This feels like a media driver. Can you CC linux-me...@vger.kernel.org? > Someone needs to review the interface to see if it makes sense. > > regard, > dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 3/3] Documentation: devicetree: bindings: Add DT binding doc for xm2mvsc driver
This commit adds the binding doc for the DT that the driver expects.
Driver has been tested against Zynq US+ board.
Signed-off-by: Rohit Athavale
---
.../devicetree/bindings/xm2mvscaler.txt| 25 ++
1 file changed, 25 insertions(+)
create mode 100644
drivers/staging/xm2mvscale/Documentation/devicetree/bindings/xm2mvscaler.txt
diff --git
a/drivers/staging/xm2mvscale/Documentation/devicetree/bindings/xm2mvscaler.txt
b/drivers/staging/xm2mvscale/Documentation/devicetree/bindings/xm2mvscaler.txt
new file mode 100644
index 000..1f3d805
--- /dev/null
+++
b/drivers/staging/xm2mvscale/Documentation/devicetree/bindings/xm2mvscaler.txt
@@ -0,0 +1,25 @@
+Xilinx M2M Video Scaler
+---
+This document describes the DT bindings required by the
+Xilinx M2M Video Scaler driver.
+
+Required Properties:
+- compatible : Must be "xlnx,v-m2m-scaler"
+- reg : Memory map for module access
+- reset-gpios : Should contain GPIO reset phandle
+- interrupt-parent : Interrupt controller the interrupt is routed through
+- interrupts : Should contain DMA channel interrupt
+- xlnx,scaler-num-taps : The number of filter taps for scaling filter
+- xlnx,scaler-max-chan : The maximum number of supported scaling channels
+
+Examples
+-
+ v_multi_scaler: v_multi_scaler@a000 {
+ compatible = "xlnx,v-m2m-scaler";
+ reg = <0x0 0xa000 0x0 0x1>;
+ reset-gpios = <&gpio 78 1>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 89 4>;
+ xlnx,scaler-num-taps = <6>;
+ xlnx,scaler-max-chan = <4>;
+ };
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/3] staging: xm2mvscale: Add TODO for the driver
This commit highlights the key functionalities that will be improved upon in a future patch set. Signed-off-by: Rohit Athavale --- drivers/staging/xm2mvscale/TODO | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 drivers/staging/xm2mvscale/TODO diff --git a/drivers/staging/xm2mvscale/TODO b/drivers/staging/xm2mvscale/TODO new file mode 100644 index 000..f0a0733 --- /dev/null +++ b/drivers/staging/xm2mvscale/TODO @@ -0,0 +1,18 @@ +* Fix checkpatch.pl complaints +* Investigate if V4L2/Media framework can be used on top of HW Layer instead + of exisiting char driver. +* Possible remaining coding style fix. +* Add support for DMABUF. +* This is an early prototype, hardware register map changes are expected. +* Update driver for 64-bit DMA address once the new Xilinx M2M Scaler IP + has support for 64-bit DMA Addresses. Current IP supports 32-bit DMA addresses. +* Remove deadcode. +* Add documents in Documentation beyond the DT binding doc. +* This needs a home in the proper drivers area (example : drivers/misc/), + once the quality of the driver is improved. Suggestions about where + it should be placed are welcome. +* The IOCTL header could be moved to an uapi/* area once this is out of staging. + +Please send any patches to: +Greg Kroah-Hartman and Rohit Athavale + -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/3] Initial driver support for Xilinx M2M Video Scaler
This patch series has three commits : - Driver support for the Xilinx M2M Video Scaler IP - TODO document - DT binding doc Changes in HW register map is expected as the IP undergoes changes. This is a first attempt at the driver as an early prototype. This is a M2M Video Scaler IP that uses polyphases filters to perform video scaling. The driver will be used by an application like a gstreamer plugin. Change Log: v2 - Cc'ing linux-media mailing list as suggested by Dan Carpenter. Dan wanted to see if someone from linux-media can review the driver interface in xm2m_vscale.c to see if it makes sense. - Another question would be the right place to keep the driver, in drivers/staging/media or drivers/staging/ - Dropped empty mmap_open, mmap_close ops. - Removed incorrect DMA_SHARED_BUFFER select from Kconfig v1 - Initial version Rohit Athavale (3): staging: xm2mvscale: Driver support for Xilinx M2M Video Scaler staging: xm2mvscale: Add TODO for the driver Documentation: devicetree: bindings: Add DT binding doc for xm2mvsc driver drivers/staging/Kconfig| 2 + drivers/staging/Makefile | 1 + .../devicetree/bindings/xm2mvscaler.txt| 25 + drivers/staging/xm2mvscale/Kconfig | 11 + drivers/staging/xm2mvscale/Makefile| 3 + drivers/staging/xm2mvscale/TODO| 18 + drivers/staging/xm2mvscale/ioctl_xm2mvsc.h | 134 +++ drivers/staging/xm2mvscale/scaler_hw_xm2m.c| 945 + drivers/staging/xm2mvscale/scaler_hw_xm2m.h| 152 drivers/staging/xm2mvscale/xm2m_vscale.c | 768 + drivers/staging/xm2mvscale/xvm2mvsc_hw_regs.h | 204 + 11 files changed, 2263 insertions(+) create mode 100644 drivers/staging/xm2mvscale/Documentation/devicetree/bindings/xm2mvscaler.txt create mode 100644 drivers/staging/xm2mvscale/Kconfig create mode 100644 drivers/staging/xm2mvscale/Makefile create mode 100644 drivers/staging/xm2mvscale/TODO create mode 100644 drivers/staging/xm2mvscale/ioctl_xm2mvsc.h create mode 100644 drivers/staging/xm2mvscale/scaler_hw_xm2m.c create mode 100644 drivers/staging/xm2mvscale/scaler_hw_xm2m.h create mode 100644 drivers/staging/xm2mvscale/xm2m_vscale.c create mode 100644 drivers/staging/xm2mvscale/xvm2mvsc_hw_regs.h -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/3] staging: xm2mvscale: Driver support for Xilinx M2M Video Scaler
This commit adds driver support for the pre-release Xilinx M2M Video
Scaler IP. There are three parts to this driver :
- The Hardware/IP layer that reads and writes register of the IP
contained in the scaler_hw_xm2m.c
- The set of ioctls that applications would need to know contained
in ioctl_xm2mvsc.h
- The char driver that consumes the IP layer in xm2m_vscale.c
Signed-off-by: Rohit Athavale
---
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 1 +
drivers/staging/xm2mvscale/Kconfig| 11 +
drivers/staging/xm2mvscale/Makefile | 3 +
drivers/staging/xm2mvscale/ioctl_xm2mvsc.h| 134
drivers/staging/xm2mvscale/scaler_hw_xm2m.c | 945 ++
drivers/staging/xm2mvscale/scaler_hw_xm2m.h | 152 +
drivers/staging/xm2mvscale/xm2m_vscale.c | 768 +
drivers/staging/xm2mvscale/xvm2mvsc_hw_regs.h | 204 ++
9 files changed, 2220 insertions(+)
create mode 100644 drivers/staging/xm2mvscale/Kconfig
create mode 100644 drivers/staging/xm2mvscale/Makefile
create mode 100644 drivers/staging/xm2mvscale/ioctl_xm2mvsc.h
create mode 100644 drivers/staging/xm2mvscale/scaler_hw_xm2m.c
create mode 100644 drivers/staging/xm2mvscale/scaler_hw_xm2m.h
create mode 100644 drivers/staging/xm2mvscale/xm2m_vscale.c
create mode 100644 drivers/staging/xm2mvscale/xvm2mvsc_hw_regs.h
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index e95ab68..3ee3a3e 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -122,4 +122,6 @@ source "drivers/staging/vboxvideo/Kconfig"
source "drivers/staging/pi433/Kconfig"
+source "drivers/staging/xm2mvscale/Kconfig"
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index af8cd6a..29ce417 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -52,3 +52,4 @@ obj-$(CONFIG_BCM2835_VCHIQ) += vc04_services/
obj-$(CONFIG_CRYPTO_DEV_CCREE) += ccree/
obj-$(CONFIG_DRM_VBOXVIDEO)+= vboxvideo/
obj-$(CONFIG_PI433)+= pi433/
+obj-$(CONFIG_XILINX_M2M_VSC) += xm2mvscale/
diff --git a/drivers/staging/xm2mvscale/Kconfig
b/drivers/staging/xm2mvscale/Kconfig
new file mode 100644
index 000..949a8e4
--- /dev/null
+++ b/drivers/staging/xm2mvscale/Kconfig
@@ -0,0 +1,11 @@
+config XILINX_M2M_VSC
+ tristate "Xilinx M2M Video Scaler"
+ depends on ARCH_ZYNQMP && OF
+ ---help---
+ This driver is developed for Xilinx M2M Video Scaler IP,
+ designed to allow passage of frame buffers from the source
+ kernel sub-system, apply video scaling and forward to the
+ sink kernel sub-system.
+
+ To compile this driver as a module, choose M here.
+ If unsure, choose N.
diff --git a/drivers/staging/xm2mvscale/Makefile
b/drivers/staging/xm2mvscale/Makefile
new file mode 100644
index 000..ec777e1
--- /dev/null
+++ b/drivers/staging/xm2mvscale/Makefile
@@ -0,0 +1,3 @@
+xm2m_vscale_drv-y := scaler_hw_xm2m.o
+xm2m_vscale_drv-y += xm2m_vscale.o
+obj-$(CONFIG_XILINX_M2M_VSC) += xm2m_vscale_drv.o
diff --git a/drivers/staging/xm2mvscale/ioctl_xm2mvsc.h
b/drivers/staging/xm2mvscale/ioctl_xm2mvsc.h
new file mode 100644
index 000..03bd7ab
--- /dev/null
+++ b/drivers/staging/xm2mvscale/ioctl_xm2mvsc.h
@@ -0,0 +1,134 @@
+/*
+ * Xilinx Memory-to-Memory Video Scaler IP
+ *
+ * Copyright (C) 2018 Xilinx, Inc. All rights reserved.
+ *
+ * SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+ */
+#ifndef __IOCTL_XM2MVSC_H__
+#define __IOCTL_XM2MVSC_H__
+
+/* Xilinx Video Specific Color/Pixel Formats */
+enum xm2mvsc_pix_fmt {
+ XILINX_FRMBUF_FMT_RGBX8 = 10,
+ XILINX_FRMBUF_FMT_YUVX8,
+ XILINX_FRMBUF_FMT_YUYV8,
+ XILINX_FRMBUF_FMT_RGBA8,
+ XILINX_FRMBUF_FMT_YUVA8,
+ XILINX_FRMBUF_FMT_RGBX10,
+ XILINX_FRMBUF_FMT_YUVX10,
+ /* RGB565 takes the value of 17 */
+ XILINX_FRMBUF_FMT_Y_UV8 = 18,
+ XILINX_FRMBUF_FMT_Y_UV8_420,
+ XILINX_FRMBUF_FMT_RGB8,
+ XILINX_FRMBUF_FMT_YUV8,
+ XILINX_FRMBUF_FMT_Y_UV10,
+ XILINX_FRMBUF_FMT_Y_UV10_420,
+ XILINX_FRMBUF_FMT_Y8,
+ XILINX_FRMBUF_FMT_Y10,
+ XILINX_FRMBUF_FMT_BGRA8,
+ XILINX_FRMBUF_FMT_BGRX8,
+ XILINX_FRMBUF_FMT_UYVY8,
+ XILINX_FRMBUF_FMT_BGR8,
+};
+
+/* struct xm2mvsc_qdata - Struct to enqueue a descriptor
+ * @srcbuf_ht: Height of source buffer
+ * @srcbuf_wt: Width of source buffer
+ * @srcbuf_bpp: Bytes per pixel of source buffer
+ * @srcbuf_cft: Color/Pixel format of source buffer
+ * @srcbuf_size: Size of the source buffer requested
+ * @srcbuf_mmap: Identify if srcbuf is mmap'ed
+ * @srcbuf_stride: Stride of the source buffer
+ * @dstbuf_ht: Height of destination buffer
+ * @dstbuf_wt: Width of destination buffer
+ * @dstbuf_bpp: Bytes per pixel of destination buffer
+ * @dstbuf_cft: Color/Pixel format
[no subject]
de...@driverdev.osuosl.org
Bcc:
Subject: [PATCH v2] drivers:staging:android:ashmem: Changing return type from
int to loff_t
Reply-To:
Changing return type from int to loff_t. Actual return type of the
function (vfs_llseek) is loff_t (long long). Here due to implicit
converion from long long to int, result will be implementation defined.
Signed-off-by: Rohit Kumar
---
drivers/staging/android/ashmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 86580b6..a1a0025 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -321,7 +321,7 @@ static ssize_t ashmem_read_iter(struct kiocb *iocb, struct
iov_iter *iter)
static loff_t ashmem_llseek(struct file *file, loff_t offset, int origin)
{
struct ashmem_area *asma = file->private_data;
- int ret;
+ loff_t ret;
mutex_lock(&ashmem_mutex);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] drivers:staging:android:ashmem: Changing return type from int to loff_t
Changing return type from int to loff_t. Actual return type of the
function (vfs_llseek) is loff_t (long long). Here due to implicit
converion from long long to int, result will be implementation defined.
Signed-off-by: Rohit Kumar
---
drivers/staging/android/ashmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 86580b6..a1a0025 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -321,7 +321,7 @@ static ssize_t ashmem_read_iter(struct kiocb *iocb, struct
iov_iter *iter)
static loff_t ashmem_llseek(struct file *file, loff_t offset, int origin)
{
struct ashmem_area *asma = file->private_data;
- int ret;
+ loff_t ret;
mutex_lock(&ashmem_mutex);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v2 1/3] staging: xm2mvscale: Driver support for Xilinx M2M Video Scaler
Hi Hans, Thanks for taking the time to take a look at this. > This should definitely use the V4L2 API. I guess it could be added > to staging/media with a big fat TODO that this should be converted to > the V4L2 mem2mem framework. > > But it makes no sense to re-invent the V4L2 streaming API :-) > > drivers/media/platform/mx2_emmaprp.c does something similar to this. > It's a little bit outdated (not using the latest m2m helper functions) > but it is a good starting point. I looked at the mx2_emmaprp.c and the Samsung G-Scaler M2M driver. IMHO, the main difference between the Hardware registers/capabilities is that mx2_emmaprp driver or the gsc driver, have one scaling "channel" if we might call it. Whereas the HW/IP I have in mind has 4-8 scaling channels. By a scaling channel, I mean an entity of the HW or IP, that can take the following parameters : - Input height, stride , width, color format, input Y and Cb/Cr physically contiguous memory pointers - Output height, stride, width, color format, output Y and Cb/Cr physically contiguous memory pointers Based on the above parameters, when the above are provided and the IP is started, we get an interrupt on completion. I'm sure you are familiar with this model. However, in the case of this IP, there could be 4-8 such channels and a single interrupt on the completion of the all 4-8 scaling operations. In this IP, we are trying to have 4-8 input sources being scaled by this single piece of hardware, by time multiplexing. An example use case is : Four applications (sources) will feed (enqueue) 4 input buffers to the scaler, the scaler driver will synchronize the programming of these buffers, when the number of buffers received by the driver meets our batch size (say a batch size of 4), it will kick start the IP. The four applications will poll on the fd, upon receiving an interrupt from the hardware the poll will unblock. And all four applications can dequeue their respective buffers and display them on a sink. But each "channel" can be set to do accept its own individual input and output formats. When I went through : https://www.kernel.org/doc/html/v4.14/media/uapi/v4l/open.html#multiple-opens It appears, once an application has invoked VIDIOC_REQBUFS or VIDIOC_CREATE_BUFS, other applications cannot VIDIOC_S_FMT on them. However to maximize the available number of channels, it would be necessary to allow several applications to be able to perform VIDIOC_S_FMT on the device node in the case of this hardware as different channels can be expected to deal with different scaling operations. One option is to create a logical /dev/videoX node for each such channel, and have a parent driver perform the interrupt handling, batch size setting and other such common functionalities. Is there a way to allow multiple applications talk to the same video device node/file handle without creating logical video nodes for each channel ? Please let me know if the description of HW is not clear. I will look forward to hear comments from you. > > So for this series: > > Nacked-by: Hans Verkuil > > If this was added to drivers/staging/media instead and with an updated > TODO, then we can accept it, but we need to see some real effort afterwards > to switch this to the right API. Otherwise it will be removed again > after a few kernel cycles. > Many thanks for providing a pathway to get this into drivers/staging/media I will drop this series, and re-send with the driver being placed in drivers/staging/media. I'll add some references to this conversation, so a new reviewer gets some context of what was discussed. In the meanwhile I will look into re-writing this to utilize the M2M V4L2 API. > Regards, > > Hans Best Regards, Rohit > -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Friday, March 09, 2018 3:58 AM > To: Greg KH ; Rohit Athavale > > Cc: de...@driverdev.osuosl.org; linux-me...@vger.kernel.org > Subject: Re: [PATCH v2 1/3] staging: xm2mvscale: Driver support for Xilinx M2M > Video Scaler > > On 22/02/18 14:46, Greg KH wrote: > > On Wed, Feb 21, 2018 at 02:43:14PM -0800, Rohit Athavale wrote: > >> This commit adds driver support for the pre-release Xilinx M2M Video > >> Scaler IP. There are three parts to this driver : > >> > >> - The Hardware/IP layer that reads and writes register of the IP > >>contained in the scaler_hw_xm2m.c > >> - The set of ioctls that applications would need to know contained > >>in ioctl_xm2mvsc.h > >> - The char driver that consumes the IP layer in xm2m_vscale.c > >> > >> Signed-off-by: Rohit Athavale > >> --- > > > > I need an ack from the linux-media maintainers before I can consid
Re: [PATCH] change slave occurence to secondary everywhere
On 23/07/20 10:36 pm, Greg KH wrote: > On Thu, Jul 23, 2020 at 08:45:13PM +0530, Rohit K Bharadwaj wrote: >> changed usage of slave (deprecated) to secondary >> >> Signed-off-by: Rohit K Bharadwaj >> --- >> drivers/staging/nvec/nvec.c | 12 ++-- >> 1 file changed, 6 insertions(+), 6 deletions(-) > > Odd subject line, you should follow the other patches for this driver: > staging: nvec: one_line_description_here > > Also, you need to version your patches, this was v2, right? Put below > the --- line what you changed for each version. > > v3? > > thanks, > > greg k-h > Thank you so much for the suggestions sir, I have made all the necessary changes and have submitted the patch again, I apologize for any inconvenience caused from my side. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: nvec: change usage of slave to secondary
On 24/07/20 10:06 am, Rohit K Bharadwaj wrote:
> changed usage of slave (deprecated) to secondary
>
> Signed-off-by: Rohit K Bharadwaj
> ---
> v3: change patch subject, add version history
> v2: add changelog text in body of mail
> v1: fix style issues by changing usage of slave to secondary
>
> drivers/staging/nvec/nvec.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
> index 360ec0407740..5d7b66719a39 100644
> --- a/drivers/staging/nvec/nvec.c
> +++ b/drivers/staging/nvec/nvec.c
> @@ -718,7 +718,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
> return IRQ_HANDLED;
> }
>
> -static void tegra_init_i2c_slave(struct nvec_chip *nvec)
> +static void tegra_init_i2c_secondary(struct nvec_chip *nvec)
> {
> u32 val;
>
> @@ -744,7 +744,7 @@ static void tegra_init_i2c_slave(struct nvec_chip *nvec)
> }
>
> #ifdef CONFIG_PM_SLEEP
> -static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
> +static void nvec_disable_i2c_secondary(struct nvec_chip *nvec)
> {
> disable_irq(nvec->irq);
> writel(I2C_SL_NEWSL | I2C_SL_NACK, nvec->base + I2C_SL_CNFG);
> @@ -784,7 +784,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, nvec);
> nvec->dev = dev;
>
> - if (of_property_read_u32(dev->of_node, "slave-addr", &nvec->i2c_addr)) {
> + if (of_property_read_u32(dev->of_node, "secondary-addr",
> &nvec->i2c_addr)) {
> dev_err(dev, "no i2c address specified");
> return -ENODEV;
> }
> @@ -839,7 +839,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
> }
> disable_irq(nvec->irq);
>
> - tegra_init_i2c_slave(nvec);
> + tegra_init_i2c_secondary(nvec);
>
> /* enable event reporting */
> nvec_toggle_global_events(nvec, true);
> @@ -913,7 +913,7 @@ static int nvec_suspend(struct device *dev)
> if (!err)
> nvec_msg_free(nvec, msg);
>
> - nvec_disable_i2c_slave(nvec);
> + nvec_disable_i2c_secondary(nvec);
>
> return 0;
> }
> @@ -923,7 +923,7 @@ static int nvec_resume(struct device *dev)
> struct nvec_chip *nvec = dev_get_drvdata(dev);
>
> dev_dbg(nvec->dev, "resuming\n");
> - tegra_init_i2c_slave(nvec);
> + tegra_init_i2c_secondary(nvec);
> nvec_toggle_global_events(nvec, true);
>
> return 0;
>
Dear All, this message was not delivered to marvi...@gmx.de, I'm getting that
The response from the remote server was:
554 gmx.net (mxgmx016) Nemesis ESMTP Service not available No SMTP service
Reject due to policy restrictions,
I'm really sorry if I'm wasting your time by these trivial problems, thanks a
lot for your time, could you please let me know whether I have to resend the
patch again or is the patch fine currently and can be accepted into the linux
kernel tree?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: nvec: change usage of slave to secondary
On 24/07/20 1:58 pm, Greg KH wrote:
> On Fri, Jul 24, 2020 at 01:44:27PM +0530, Rohit Bharadwaj wrote:
>> On 24/07/20 10:06 am, Rohit K Bharadwaj wrote:
>>> changed usage of slave (deprecated) to secondary
>>>
>>> Signed-off-by: Rohit K Bharadwaj
>>> ---
>>> v3: change patch subject, add version history
>>> v2: add changelog text in body of mail
>>> v1: fix style issues by changing usage of slave to secondary
>>>
>>> drivers/staging/nvec/nvec.c | 12 ++--
>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
>>> index 360ec0407740..5d7b66719a39 100644
>>> --- a/drivers/staging/nvec/nvec.c
>>> +++ b/drivers/staging/nvec/nvec.c
>>> @@ -718,7 +718,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>>> return IRQ_HANDLED;
>>> }
>>>
>>> -static void tegra_init_i2c_slave(struct nvec_chip *nvec)
>>> +static void tegra_init_i2c_secondary(struct nvec_chip *nvec)
>>> {
>>> u32 val;
>>>
>>> @@ -744,7 +744,7 @@ static void tegra_init_i2c_slave(struct nvec_chip *nvec)
>>> }
>>>
>>> #ifdef CONFIG_PM_SLEEP
>>> -static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
>>> +static void nvec_disable_i2c_secondary(struct nvec_chip *nvec)
>>> {
>>> disable_irq(nvec->irq);
>>> writel(I2C_SL_NEWSL | I2C_SL_NACK, nvec->base + I2C_SL_CNFG);
>>> @@ -784,7 +784,7 @@ static int tegra_nvec_probe(struct platform_device
>>> *pdev)
>>> platform_set_drvdata(pdev, nvec);
>>> nvec->dev = dev;
>>>
>>> - if (of_property_read_u32(dev->of_node, "slave-addr", &nvec->i2c_addr)) {
>>> + if (of_property_read_u32(dev->of_node, "secondary-addr",
>>> &nvec->i2c_addr)) {
>>> dev_err(dev, "no i2c address specified");
>>> return -ENODEV;
>>> }
>>> @@ -839,7 +839,7 @@ static int tegra_nvec_probe(struct platform_device
>>> *pdev)
>>> }
>>> disable_irq(nvec->irq);
>>>
>>> - tegra_init_i2c_slave(nvec);
>>> + tegra_init_i2c_secondary(nvec);
>>>
>>> /* enable event reporting */
>>> nvec_toggle_global_events(nvec, true);
>>> @@ -913,7 +913,7 @@ static int nvec_suspend(struct device *dev)
>>> if (!err)
>>> nvec_msg_free(nvec, msg);
>>>
>>> - nvec_disable_i2c_slave(nvec);
>>> + nvec_disable_i2c_secondary(nvec);
>>>
>>> return 0;
>>> }
>>> @@ -923,7 +923,7 @@ static int nvec_resume(struct device *dev)
>>> struct nvec_chip *nvec = dev_get_drvdata(dev);
>>>
>>> dev_dbg(nvec->dev, "resuming\n");
>>> - tegra_init_i2c_slave(nvec);
>>> + tegra_init_i2c_secondary(nvec);
>>> nvec_toggle_global_events(nvec, true);
>>>
>>> return 0;
>>>
>> Dear All, this message was not delivered to marvi...@gmx.de, I'm getting
>> that The response from the remote server was:
>> 554 gmx.net (mxgmx016) Nemesis ESMTP Service not available No SMTP service
>> Reject due to policy restrictions,
>
> Not a big deal, email address atrophy over time. That's why you always
> cc: a public mailing list for patches.
>
> thanks,
>
> greg k-h
>
Thank you so much for the reply sir, I hope this patch gets accepted.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] change slave occurence to secondary everywhere
Signed-off-by: Rohit K Bharadwaj
---
drivers/staging/nvec/nvec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 360ec0407740..5d7b66719a39 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -718,7 +718,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
return IRQ_HANDLED;
}
-static void tegra_init_i2c_slave(struct nvec_chip *nvec)
+static void tegra_init_i2c_secondary(struct nvec_chip *nvec)
{
u32 val;
@@ -744,7 +744,7 @@ static void tegra_init_i2c_slave(struct nvec_chip *nvec)
}
#ifdef CONFIG_PM_SLEEP
-static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
+static void nvec_disable_i2c_secondary(struct nvec_chip *nvec)
{
disable_irq(nvec->irq);
writel(I2C_SL_NEWSL | I2C_SL_NACK, nvec->base + I2C_SL_CNFG);
@@ -784,7 +784,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, nvec);
nvec->dev = dev;
- if (of_property_read_u32(dev->of_node, "slave-addr", &nvec->i2c_addr)) {
+ if (of_property_read_u32(dev->of_node, "secondary-addr",
&nvec->i2c_addr)) {
dev_err(dev, "no i2c address specified");
return -ENODEV;
}
@@ -839,7 +839,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
}
disable_irq(nvec->irq);
- tegra_init_i2c_slave(nvec);
+ tegra_init_i2c_secondary(nvec);
/* enable event reporting */
nvec_toggle_global_events(nvec, true);
@@ -913,7 +913,7 @@ static int nvec_suspend(struct device *dev)
if (!err)
nvec_msg_free(nvec, msg);
- nvec_disable_i2c_slave(nvec);
+ nvec_disable_i2c_secondary(nvec);
return 0;
}
@@ -923,7 +923,7 @@ static int nvec_resume(struct device *dev)
struct nvec_chip *nvec = dev_get_drvdata(dev);
dev_dbg(nvec->dev, "resuming\n");
- tegra_init_i2c_slave(nvec);
+ tegra_init_i2c_secondary(nvec);
nvec_toggle_global_events(nvec, true);
return 0;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] change slave occurence to secondary everywhere
changed usage of slave (deprecated) to secondary
Signed-off-by: Rohit K Bharadwaj
---
drivers/staging/nvec/nvec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 360ec0407740..5d7b66719a39 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -718,7 +718,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
return IRQ_HANDLED;
}
-static void tegra_init_i2c_slave(struct nvec_chip *nvec)
+static void tegra_init_i2c_secondary(struct nvec_chip *nvec)
{
u32 val;
@@ -744,7 +744,7 @@ static void tegra_init_i2c_slave(struct nvec_chip *nvec)
}
#ifdef CONFIG_PM_SLEEP
-static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
+static void nvec_disable_i2c_secondary(struct nvec_chip *nvec)
{
disable_irq(nvec->irq);
writel(I2C_SL_NEWSL | I2C_SL_NACK, nvec->base + I2C_SL_CNFG);
@@ -784,7 +784,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, nvec);
nvec->dev = dev;
- if (of_property_read_u32(dev->of_node, "slave-addr", &nvec->i2c_addr)) {
+ if (of_property_read_u32(dev->of_node, "secondary-addr",
&nvec->i2c_addr)) {
dev_err(dev, "no i2c address specified");
return -ENODEV;
}
@@ -839,7 +839,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
}
disable_irq(nvec->irq);
- tegra_init_i2c_slave(nvec);
+ tegra_init_i2c_secondary(nvec);
/* enable event reporting */
nvec_toggle_global_events(nvec, true);
@@ -913,7 +913,7 @@ static int nvec_suspend(struct device *dev)
if (!err)
nvec_msg_free(nvec, msg);
- nvec_disable_i2c_slave(nvec);
+ nvec_disable_i2c_secondary(nvec);
return 0;
}
@@ -923,7 +923,7 @@ static int nvec_resume(struct device *dev)
struct nvec_chip *nvec = dev_get_drvdata(dev);
dev_dbg(nvec->dev, "resuming\n");
- tegra_init_i2c_slave(nvec);
+ tegra_init_i2c_secondary(nvec);
nvec_toggle_global_events(nvec, true);
return 0;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: nvec: change usage of slave to secondary
changed usage of slave (deprecated) to secondary
Signed-off-by: Rohit K Bharadwaj
---
v3: change patch subject, add version history
v2: add changelog text in body of mail
v1: fix style issues by changing usage of slave to secondary
drivers/staging/nvec/nvec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 360ec0407740..5d7b66719a39 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -718,7 +718,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
return IRQ_HANDLED;
}
-static void tegra_init_i2c_slave(struct nvec_chip *nvec)
+static void tegra_init_i2c_secondary(struct nvec_chip *nvec)
{
u32 val;
@@ -744,7 +744,7 @@ static void tegra_init_i2c_slave(struct nvec_chip *nvec)
}
#ifdef CONFIG_PM_SLEEP
-static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
+static void nvec_disable_i2c_secondary(struct nvec_chip *nvec)
{
disable_irq(nvec->irq);
writel(I2C_SL_NEWSL | I2C_SL_NACK, nvec->base + I2C_SL_CNFG);
@@ -784,7 +784,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, nvec);
nvec->dev = dev;
- if (of_property_read_u32(dev->of_node, "slave-addr", &nvec->i2c_addr)) {
+ if (of_property_read_u32(dev->of_node, "secondary-addr",
&nvec->i2c_addr)) {
dev_err(dev, "no i2c address specified");
return -ENODEV;
}
@@ -839,7 +839,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
}
disable_irq(nvec->irq);
- tegra_init_i2c_slave(nvec);
+ tegra_init_i2c_secondary(nvec);
/* enable event reporting */
nvec_toggle_global_events(nvec, true);
@@ -913,7 +913,7 @@ static int nvec_suspend(struct device *dev)
if (!err)
nvec_msg_free(nvec, msg);
- nvec_disable_i2c_slave(nvec);
+ nvec_disable_i2c_secondary(nvec);
return 0;
}
@@ -923,7 +923,7 @@ static int nvec_resume(struct device *dev)
struct nvec_chip *nvec = dev_get_drvdata(dev);
dev_dbg(nvec->dev, "resuming\n");
- tegra_init_i2c_slave(nvec);
+ tegra_init_i2c_secondary(nvec);
nvec_toggle_global_events(nvec, true);
return 0;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: nvec: change usage of slave to secondary
On 24/07/20 7:39 pm, Dan Carpenter wrote:
> On Fri, Jul 24, 2020 at 10:06:34AM +0530, Rohit K Bharadwaj wrote:
>> @@ -784,7 +784,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
>> platform_set_drvdata(pdev, nvec);
>> nvec->dev = dev;
>>
>> -if (of_property_read_u32(dev->of_node, "slave-addr", &nvec->i2c_addr)) {
>> +if (of_property_read_u32(dev->of_node, "secondary-addr",
>> &nvec->i2c_addr)) {
>
> Sorry, I should have looked for v3 at the start to reply to it. This
> line will break the driver.
>
> regards,
> dan carpenter
>
Thank you for your review sir, my intention was to fix kernel coding style
issues and hence had picked this one.
Could you please let me know whether I should undo that particular line and
submit the patch again so as not to break the driver?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: nvec: change usage of slave to secondary
On 24/07/20 10:06 pm, Marc Dietrich wrote:
>
>
> On Fri, 24 Jul 2020, Marc Dietrich wrote:
>
>> Hi Rohit,
>>
>> On Fri, 24 Jul 2020, Rohit Bharadwaj wrote:
>>
>>> On 24/07/20 1:58 pm, Greg KH wrote:
>>>> On Fri, Jul 24, 2020 at 01:44:27PM +0530, Rohit Bharadwaj wrote:
>>>>> On 24/07/20 10:06 am, Rohit K Bharadwaj wrote:
>>>>>> changed usage of slave (deprecated) to secondary
>>>>>>
>>>>>> Signed-off-by: Rohit K Bharadwaj
>>>>>> ---
>>>>>> v3: change patch subject, add version history
>>>>>> v2: add changelog text in body of mail
>>>>>> v1: fix style issues by changing usage of slave to secondary
>>>>>>
>>>>>> drivers/staging/nvec/nvec.c | 12 ++--
>>>>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
>>>>>> index 360ec0407740..5d7b66719a39 100644
>>>>>> --- a/drivers/staging/nvec/nvec.c
>>>>>> +++ b/drivers/staging/nvec/nvec.c
>>>>>> @@ -718,7 +718,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>>>>>> return IRQ_HANDLED;
>>>>>> }
>>>>>>
>>>>>> -static void tegra_init_i2c_slave(struct nvec_chip *nvec)
>>>>>> +static void tegra_init_i2c_secondary(struct nvec_chip *nvec)
>>>>>> {
>>>>>> u32 val;
>>>>>>
>>>>>> @@ -744,7 +744,7 @@ static void tegra_init_i2c_slave(struct nvec_chip
>>>>>> *nvec)
>>>>>> }
>>>>>>
>>>>>> #ifdef CONFIG_PM_SLEEP
>>>>>> -static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
>>>>>> +static void nvec_disable_i2c_secondary(struct nvec_chip *nvec)
>>>>>> {
>>>>>> disable_irq(nvec->irq);
>>>>>> writel(I2C_SL_NEWSL | I2C_SL_NACK, nvec->base + I2C_SL_CNFG);
>>>>>> @@ -784,7 +784,7 @@ static int tegra_nvec_probe(struct platform_device
>>>>>> *pdev)
>>>>>> platform_set_drvdata(pdev, nvec);
>>>>>> nvec->dev = dev;
>>>>>>
>>>>>> - if (of_property_read_u32(dev->of_node, "slave-addr",
>>>>>> &nvec->i2c_addr)) {
>>>>>> + if (of_property_read_u32(dev->of_node, "secondary-addr",
>>>>>> &nvec->i2c_addr)) {
>>>>>> dev_err(dev, "no i2c address specified");
>>>>>> return -ENODEV;
>>>>>> }
>>
>> as Christoph said, please don't change this line.
>
> arr, I meant Dan of course ;-)
Dear all, thank you so much for your inputs, I will try to make some other
patch which will not break the driver (hopefully :p), or if you give me
permission to submit this patch itself by just keeping this one line
> if (of_property_read_u32(dev->of_node, "slave-addr", &nvec->i2c_addr))
unchanged, and provided it does not break the driver by doing so, I would
gladly make the changes and submit v4 of the patch.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4] staging: nvec: change usage of slave to secondary
changed usage of slave (which is deprecated) to secondary without breaking the
driver
Tested-by: Dan Carpenter
Acked-by: Marc Dietrich
Signed-off-by: Rohit K Bharadwaj
---
v4: undo the changes (which broke the driver) to this line: if
(of_property_read_u32(dev->of_node, "slave-addr", &nvec->i2c_addr))
v3: change patch subject, add version history
v2: add changelog text in body of mail
v1: fix style issues by changing usage of slave to secondary
drivers/staging/nvec/nvec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 360ec0407740..a7e995bfe989 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -718,7 +718,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
return IRQ_HANDLED;
}
-static void tegra_init_i2c_slave(struct nvec_chip *nvec)
+static void tegra_init_i2c_secondary(struct nvec_chip *nvec)
{
u32 val;
@@ -744,7 +744,7 @@ static void tegra_init_i2c_slave(struct nvec_chip *nvec)
}
#ifdef CONFIG_PM_SLEEP
-static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
+static void nvec_disable_i2c_secondary(struct nvec_chip *nvec)
{
disable_irq(nvec->irq);
writel(I2C_SL_NEWSL | I2C_SL_NACK, nvec->base + I2C_SL_CNFG);
@@ -839,7 +839,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
}
disable_irq(nvec->irq);
- tegra_init_i2c_slave(nvec);
+ tegra_init_i2c_secondary(nvec);
/* enable event reporting */
nvec_toggle_global_events(nvec, true);
@@ -913,7 +913,7 @@ static int nvec_suspend(struct device *dev)
if (!err)
nvec_msg_free(nvec, msg);
- nvec_disable_i2c_slave(nvec);
+ nvec_disable_i2c_secondary(nvec);
return 0;
}
@@ -923,7 +923,7 @@ static int nvec_resume(struct device *dev)
struct nvec_chip *nvec = dev_get_drvdata(dev);
dev_dbg(nvec->dev, "resuming\n");
- tegra_init_i2c_slave(nvec);
+ tegra_init_i2c_secondary(nvec);
nvec_toggle_global_events(nvec, true);
return 0;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: nvec: change usage of slave to secondary
On 25/07/20 2:12 am, Marc Dietrich wrote:
>
> Hi Rohit,
>
> On Fri, 24 Jul 2020, Rohit K Bharadwaj wrote:
>
>> On 24/07/20 10:06 pm, Marc Dietrich wrote:
>>>
>>>
>>> On Fri, 24 Jul 2020, Marc Dietrich wrote:
>>>
>>>> Hi Rohit,
>>>>
>>>> On Fri, 24 Jul 2020, Rohit Bharadwaj wrote:
>>>>
>>>>> On 24/07/20 1:58 pm, Greg KH wrote:
>>>>>> On Fri, Jul 24, 2020 at 01:44:27PM +0530, Rohit Bharadwaj wrote:
>>>>>>> On 24/07/20 10:06 am, Rohit K Bharadwaj wrote:
>>>>>>>> changed usage of slave (deprecated) to secondary
>>>>>>>>
>>>>>>>> Signed-off-by: Rohit K Bharadwaj
>>>>>>>> ---
>>>>>>>> v3: change patch subject, add version history
>>>>>>>> v2: add changelog text in body of mail
>>>>>>>> v1: fix style issues by changing usage of slave to secondary
>>>>>>>>
>>>>>>>> drivers/staging/nvec/nvec.c | 12 ++--
>>>>>>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
>>>>>>>> index 360ec0407740..5d7b66719a39 100644
>>>>>>>> --- a/drivers/staging/nvec/nvec.c
>>>>>>>> +++ b/drivers/staging/nvec/nvec.c
>>>>>>>> @@ -718,7 +718,7 @@ static irqreturn_t nvec_interrupt(int irq, void
>>>>>>>> *dev)
>>>>>>>> return IRQ_HANDLED;
>>>>>>>> }
>>>>>>>>
>>>>>>>> -static void tegra_init_i2c_slave(struct nvec_chip *nvec)
>>>>>>>> +static void tegra_init_i2c_secondary(struct nvec_chip *nvec)
>>>>>>>> {
>>>>>>>> u32 val;
>>>>>>>>
>>>>>>>> @@ -744,7 +744,7 @@ static void tegra_init_i2c_slave(struct nvec_chip
>>>>>>>> *nvec)
>>>>>>>> }
>>>>>>>>
>>>>>>>> #ifdef CONFIG_PM_SLEEP
>>>>>>>> -static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
>>>>>>>> +static void nvec_disable_i2c_secondary(struct nvec_chip *nvec)
>>>>>>>> {
>>>>>>>> disable_irq(nvec->irq);
>>>>>>>> writel(I2C_SL_NEWSL | I2C_SL_NACK, nvec->base + I2C_SL_CNFG);
>>>>>>>> @@ -784,7 +784,7 @@ static int tegra_nvec_probe(struct platform_device
>>>>>>>> *pdev)
>>>>>>>> platform_set_drvdata(pdev, nvec);
>>>>>>>> nvec->dev = dev;
>>>>>>>>
>>>>>>>> - if (of_property_read_u32(dev->of_node, "slave-addr",
>>>>>>>> &nvec->i2c_addr)) {
>>>>>>>> + if (of_property_read_u32(dev->of_node, "secondary-addr",
>>>>>>>> &nvec->i2c_addr)) {
>>>>>>>> dev_err(dev, "no i2c address specified");
>>>>>>>> return -ENODEV;
>>>>>>>> }
>>>>
>>>> as Christoph said, please don't change this line.
>>>
>>> arr, I meant Dan of course ;-)
>> Dear all, thank you so much for your inputs, I will try to make some other
>> patch which will not break the driver (hopefully :p), or if you give me
>> permission to submit this patch itself by just keeping this one line
>>
>>> if (of_property_read_u32(dev->of_node, "slave-addr", &nvec->i2c_addr))
>>
>> unchanged, and provided it does not break the driver by doing so, I would
>> gladly make the changes and submit v4 of the patch.
>
> please resend the patch with the line above unchanged as v4. Don't forget to
> to update the changelog to the commit message. I tested your patch (without
> the dt property change) and it does not change behavoir - as expected,
> so you will recevice my Ack.
>
> Marc
Thank you so much for the suggestions and the Ack sir, I have made the
necessary changes and I have sent the v4 of the patch.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: nvec: change usage of slave to secondary
On 25/07/20 5:31 pm, Michał Mirosław wrote: > On Sat, Jul 25, 2020 at 11:59:39AM +0530, Rohit K Bharadwaj wrote: >> changed usage of slave (which is deprecated) to secondary without breaking >> the driver > > The relevant I2C and SMBus standards use master/slave terminology. Why are > you changing the names to something unfamiliar? > > If the reason are the recent coding-style changes, then please note they > are about avoiding introducing *NEW* uses of the specific words and not > about blindly replacing existing occurrences. > > Best Regards > Michał Mirosław > I'm really sorry sir, I didn't knew about this, yes the reason for my change is according to the script checkpatch.pl to suit the coding style, I would try to fix some other coding style related issues if this patch seems to be a bad idea. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: nvec: change usage of slave to secondary
On 25/07/20 6:20 pm, Michał Mirosław wrote: > On Sat, Jul 25, 2020 at 06:01:19PM +0530, Rohit K Bharadwaj wrote: >> On 25/07/20 5:31 pm, Michał Mirosław wrote: >>> On Sat, Jul 25, 2020 at 11:59:39AM +0530, Rohit K Bharadwaj wrote: >>>> changed usage of slave (which is deprecated) to secondary without breaking >>>> the driver >>> >>> The relevant I2C and SMBus standards use master/slave terminology. Why are >>> you changing the names to something unfamiliar? >>> >>> If the reason are the recent coding-style changes, then please note they >>> are about avoiding introducing *NEW* uses of the specific words and not >>> about blindly replacing existing occurrences. >> >> I'm really sorry sir, I didn't knew about this, yes the reason for my change >> is according to the script checkpatch.pl to suit the coding style, I would >> try to fix some other coding style related issues if this patch seems to be >> a bad idea. > > I didn't know checkpatch does this (it doesn't in current Linus' master > tree). I can see there is a commit in next adding this, but seems that > it uses a test far from the original coding-style wording... > > Best Regards > Michał Mirosław > yes sir, in the linux-next tree, when I ran the script on this file it showed me it had style issues and the usage of slave is deprecated and it suggested me to replace it with secondary or target. and hence I made this patch, please do let me know if this patch can be acceptable or not. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: media: atomisp: fix code style issues
this patch fixes the warnings and errors generated after running checkpatch.pl
on pci/sh_css_firmware.c
Signed-off-by: Rohit K Bharadwaj
---
.../media/atomisp/pci/sh_css_firmware.c | 62 +++
1 file changed, 36 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
index d4ab15b6d1ac..244c7c7780a3 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
@@ -51,9 +51,11 @@ struct fw_param {
static struct firmware_header *firmware_header;
-/* The string STR is a place holder
+/*
+ * The string STR is a place holder
* which will be replaced with the actual RELEASE_VERSION
- * during package generation. Please do not modify */
+ * during package generation. Please do not modify
+ */
static const char *isp2400_release_version =
STR(irci_stable_candrpv_0415_20150521_0458);
static const char *isp2401_release_version = STR(irci_ecr -
master_20150911_0724);
@@ -78,7 +80,8 @@ char *sh_css_get_fw_version(void)
/* Setup sp/sp1 binary */
static int
setup_binary(struct ia_css_fw_info *fw, const char *fw_data,
-struct ia_css_fw_info *sh_css_fw, unsigned int binary_id) {
+struct ia_css_fw_info *sh_css_fw, unsigned int binary_id)
+{
const char *blob_data;
if ((!fw) || (!fw_data))
@@ -102,7 +105,8 @@ setup_binary(struct ia_css_fw_info *fw, const char *fw_data,
int
sh_css_load_blob_info(const char *fw, const struct ia_css_fw_info *bi,
struct ia_css_blob_descr *bd,
- unsigned int index) {
+ unsigned int index)
+{
const char *name;
const unsigned char *blob;
@@ -110,14 +114,16 @@ sh_css_load_blob_info(const char *fw, const struct
ia_css_fw_info *bi,
return -EINVAL;
/* Special case: only one binary in fw */
- if (!bi) bi = (const struct ia_css_fw_info *)fw;
+ if (!bi)
+ bi = (const struct ia_css_fw_info *)fw;
name = fw + bi->blob.prog_name_offset;
blob = (const unsigned char *)fw + bi->blob.offset;
/* sanity check */
- if (bi->blob.size != bi->blob.text_size + bi->blob.icache_size +
bi->blob.data_size + bi->blob.padding_size)
- {
+ if (bi->blob.size !=
+ bi->blob.text_size + bi->blob.icache_size +
+ bi->blob.data_size + bi->blob.padding_size) {
/* sanity check, note the padding bytes added for section to
DDR alignment */
return -EINVAL;
}
@@ -128,21 +134,18 @@ sh_css_load_blob_info(const char *fw, const struct
ia_css_fw_info *bi,
bd->blob = blob;
bd->header = *bi;
- if (bi->type == ia_css_isp_firmware || bi->type == ia_css_sp_firmware)
- {
+ if (bi->type == ia_css_isp_firmware || bi->type == ia_css_sp_firmware) {
char *namebuffer;
namebuffer = kstrdup(name, GFP_KERNEL);
if (!namebuffer)
return -ENOMEM;
bd->name = fw_minibuffer[index].name = namebuffer;
- } else
- {
+ } else {
bd->name = name;
}
- if (bi->type == ia_css_isp_firmware)
- {
+ if (bi->type == ia_css_isp_firmware) {
size_t paramstruct_size = sizeof(struct ia_css_memory_offsets);
size_t configstruct_size = sizeof(struct
ia_css_config_memory_offsets);
size_t statestruct_size = sizeof(struct
ia_css_state_memory_offsets);
@@ -223,7 +226,8 @@ static const char * const fw_acc_type_name[] = {
int
sh_css_load_firmware(struct device *dev, const char *fw_data,
-unsigned int fw_size) {
+unsigned int fw_size)
+{
unsigned int i;
struct ia_css_fw_info *binaries;
struct sh_css_fw_bi_file_h *file_header;
@@ -238,7 +242,8 @@ sh_css_load_firmware(struct device *dev, const char
*fw_data,
firmware_header = (struct firmware_header *)fw_data;
file_header = &firmware_header->file_header;
binaries = &firmware_header->binary_header;
- strscpy(FW_rel_ver_name, file_header->version,
min(sizeof(FW_rel_ver_name), sizeof(file_header->version)));
+ strscpy(FW_rel_ver_name, file_header->version,
+ min(sizeof(FW_rel_ver_name), sizeof(file_header->version)));
ret = sh_css_check_firmware_version(dev, fw_data);
if (ret) {
IA_CSS_ERROR("CSS code version (%s) and firmware version (%s)
mismatch!",
@@ -257,8 +262,7 @@ sh_css_load_firmware(struct device *dev, const char
*fw_data,
sh_css_num_binaries = file_header->binary_nr;
/* Only allocate memory for ISP blob info */
- if (sh_css_num_binaries
[PATCH v2 1/4] fix style of block comments
this patch fixes the coding style of block comments.
Signed-off-by: Rohit K Bharadwaj
---
v2: split patch into sequence of patches
v1: fix all coding style issues in single patch
.../media/atomisp/pci/sh_css_firmware.c | 28 +--
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
index d4ab15b6d1ac..2907aead98b7 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
@@ -51,9 +51,12 @@ struct fw_param {
static struct firmware_header *firmware_header;
-/* The string STR is a place holder
+/*
+ * The string STR is a place holder
* which will be replaced with the actual RELEASE_VERSION
- * during package generation. Please do not modify */
+ * during package generation. Please do not modify
+ */
+
static const char *isp2400_release_version =
STR(irci_stable_candrpv_0415_20150521_0458);
static const char *isp2401_release_version = STR(irci_ecr -
master_20150911_0724);
@@ -276,10 +279,11 @@ sh_css_load_firmware(struct device *dev, const char
*fw_data,
for (i = 0; i < sh_css_num_binaries; i++)
{
struct ia_css_fw_info *bi = &binaries[i];
- /* note: the var below is made static as it is quite large;
- if it is not static it ends up on the stack which could
- cause issues for drivers
- */
+ /*
+* note: the var below is made static as it is quite large;
+* if it is not static it ends up on the stack which could
+* cause issues for drivers
+*/
static struct ia_css_blob_descr bd;
int err;
@@ -333,7 +337,11 @@ sh_css_load_firmware(struct device *dev, const char
*fw_data,
return err;
} else {
- /* All subsequent binaries (including bootloaders)
(i>NUM_OF_SPS) are ISP firmware */
+ /*
+* All subsequent binaries
+* (including bootloaders) (i>NUM_OF_SPS)
+* are ISP firmware
+*/
if (i < NUM_OF_SPS)
return -EINVAL;
@@ -374,8 +382,10 @@ ia_css_ptr
sh_css_load_blob(const unsigned char *blob, unsigned int size)
{
ia_css_ptr target_addr = hmm_alloc(size, HMM_BO_PRIVATE, 0, NULL, 0);
- /* this will allocate memory aligned to a DDR word boundary which
- is required for the CSS DMA to read the instructions. */
+ /*
+* this will allocate memory aligned to a DDR word boundary which
+* is required for the CSS DMA to read the instructions.
+*/
assert(blob);
if (target_addr)
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/4] fix style of block comments
On 26/07/20 2:18 pm, Rohit K Bharadwaj wrote:
> this patch fixes the coding style of block comments.
>
> Signed-off-by: Rohit K Bharadwaj
> ---
> v2: split patch into sequence of patches
> v1: fix all coding style issues in single patch
>
> .../media/atomisp/pci/sh_css_firmware.c | 28 +--
> 1 file changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
> b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
> index d4ab15b6d1ac..2907aead98b7 100644
> --- a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
> +++ b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
> @@ -51,9 +51,12 @@ struct fw_param {
>
> static struct firmware_header *firmware_header;
>
> -/* The string STR is a place holder
> +/*
> + * The string STR is a place holder
> * which will be replaced with the actual RELEASE_VERSION
> - * during package generation. Please do not modify */
> + * during package generation. Please do not modify
> + */
> +
> static const char *isp2400_release_version =
> STR(irci_stable_candrpv_0415_20150521_0458);
> static const char *isp2401_release_version = STR(irci_ecr -
> master_20150911_0724);
>
> @@ -276,10 +279,11 @@ sh_css_load_firmware(struct device *dev, const char
> *fw_data,
> for (i = 0; i < sh_css_num_binaries; i++)
> {
> struct ia_css_fw_info *bi = &binaries[i];
> - /* note: the var below is made static as it is quite large;
> -if it is not static it ends up on the stack which could
> -cause issues for drivers
> - */
> + /*
> + * note: the var below is made static as it is quite large;
> + * if it is not static it ends up on the stack which could
> + * cause issues for drivers
> + */
> static struct ia_css_blob_descr bd;
> int err;
>
> @@ -333,7 +337,11 @@ sh_css_load_firmware(struct device *dev, const char
> *fw_data,
> return err;
>
> } else {
> - /* All subsequent binaries (including bootloaders)
> (i>NUM_OF_SPS) are ISP firmware */
> + /*
> + * All subsequent binaries
> + * (including bootloaders) (i>NUM_OF_SPS)
> + * are ISP firmware
> + */
> if (i < NUM_OF_SPS)
> return -EINVAL;
>
> @@ -374,8 +382,10 @@ ia_css_ptr
> sh_css_load_blob(const unsigned char *blob, unsigned int size)
> {
> ia_css_ptr target_addr = hmm_alloc(size, HMM_BO_PRIVATE, 0, NULL, 0);
> - /* this will allocate memory aligned to a DDR word boundary which
> -is required for the CSS DMA to read the instructions. */
> + /*
> + * this will allocate memory aligned to a DDR word boundary which
> + * is required for the CSS DMA to read the instructions.
> + */
>
> assert(blob);
> if (target_addr)
>
I'm really sorry for the spam, please excuse me, I realized that I didn't
change the subject prefix so will send another version, apologies for any
inconvenience caused.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/4] staging: media: atomisp: fix style of block comments
this patch fixes the coding style of block comments.
Signed-off-by: Rohit K Bharadwaj
---
v3: change patch subject prefix
v2: split patch into sequence of patches
v1: fix all coding style issues in single patch
.../media/atomisp/pci/sh_css_firmware.c | 28 +--
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
index d4ab15b6d1ac..2907aead98b7 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
@@ -51,9 +51,12 @@ struct fw_param {
static struct firmware_header *firmware_header;
-/* The string STR is a place holder
+/*
+ * The string STR is a place holder
* which will be replaced with the actual RELEASE_VERSION
- * during package generation. Please do not modify */
+ * during package generation. Please do not modify
+ */
+
static const char *isp2400_release_version =
STR(irci_stable_candrpv_0415_20150521_0458);
static const char *isp2401_release_version = STR(irci_ecr -
master_20150911_0724);
@@ -276,10 +279,11 @@ sh_css_load_firmware(struct device *dev, const char
*fw_data,
for (i = 0; i < sh_css_num_binaries; i++)
{
struct ia_css_fw_info *bi = &binaries[i];
- /* note: the var below is made static as it is quite large;
- if it is not static it ends up on the stack which could
- cause issues for drivers
- */
+ /*
+* note: the var below is made static as it is quite large;
+* if it is not static it ends up on the stack which could
+* cause issues for drivers
+*/
static struct ia_css_blob_descr bd;
int err;
@@ -333,7 +337,11 @@ sh_css_load_firmware(struct device *dev, const char
*fw_data,
return err;
} else {
- /* All subsequent binaries (including bootloaders)
(i>NUM_OF_SPS) are ISP firmware */
+ /*
+* All subsequent binaries
+* (including bootloaders) (i>NUM_OF_SPS)
+* are ISP firmware
+*/
if (i < NUM_OF_SPS)
return -EINVAL;
@@ -374,8 +382,10 @@ ia_css_ptr
sh_css_load_blob(const unsigned char *blob, unsigned int size)
{
ia_css_ptr target_addr = hmm_alloc(size, HMM_BO_PRIVATE, 0, NULL, 0);
- /* this will allocate memory aligned to a DDR word boundary which
- is required for the CSS DMA to read the instructions. */
+ /*
+* this will allocate memory aligned to a DDR word boundary which
+* is required for the CSS DMA to read the instructions.
+*/
assert(blob);
if (target_addr)
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 2/4] staging: media: atomisp: fix style of open brace
this patch fixes style of open brace after functions and if statements
Signed-off-by: Rohit K Bharadwaj
---
v3: change patch subject prefix
v2: split patch into sequence of patches
v1: fix all coding style issues in single patch
.../media/atomisp/pci/sh_css_firmware.c | 29 +--
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
index 2907aead98b7..988785ab6c95 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
@@ -81,7 +81,8 @@ char *sh_css_get_fw_version(void)
/* Setup sp/sp1 binary */
static int
setup_binary(struct ia_css_fw_info *fw, const char *fw_data,
-struct ia_css_fw_info *sh_css_fw, unsigned int binary_id) {
+struct ia_css_fw_info *sh_css_fw, unsigned int binary_id)
+{
const char *blob_data;
if ((!fw) || (!fw_data))
@@ -105,7 +106,8 @@ setup_binary(struct ia_css_fw_info *fw, const char *fw_data,
int
sh_css_load_blob_info(const char *fw, const struct ia_css_fw_info *bi,
struct ia_css_blob_descr *bd,
- unsigned int index) {
+ unsigned int index)
+{
const char *name;
const unsigned char *blob;
@@ -119,8 +121,9 @@ sh_css_load_blob_info(const char *fw, const struct
ia_css_fw_info *bi,
blob = (const unsigned char *)fw + bi->blob.offset;
/* sanity check */
- if (bi->blob.size != bi->blob.text_size + bi->blob.icache_size +
bi->blob.data_size + bi->blob.padding_size)
- {
+ if (bi->blob.size !=
+ bi->blob.text_size + bi->blob.icache_size +
+ bi->blob.data_size + bi->blob.padding_size) {
/* sanity check, note the padding bytes added for section to
DDR alignment */
return -EINVAL;
}
@@ -131,21 +134,18 @@ sh_css_load_blob_info(const char *fw, const struct
ia_css_fw_info *bi,
bd->blob = blob;
bd->header = *bi;
- if (bi->type == ia_css_isp_firmware || bi->type == ia_css_sp_firmware)
- {
+ if (bi->type == ia_css_isp_firmware || bi->type == ia_css_sp_firmware) {
char *namebuffer;
namebuffer = kstrdup(name, GFP_KERNEL);
if (!namebuffer)
return -ENOMEM;
bd->name = fw_minibuffer[index].name = namebuffer;
- } else
- {
+ } else {
bd->name = name;
}
- if (bi->type == ia_css_isp_firmware)
- {
+ if (bi->type == ia_css_isp_firmware) {
size_t paramstruct_size = sizeof(struct ia_css_memory_offsets);
size_t configstruct_size = sizeof(struct
ia_css_config_memory_offsets);
size_t statestruct_size = sizeof(struct
ia_css_state_memory_offsets);
@@ -226,7 +226,8 @@ static const char * const fw_acc_type_name[] = {
int
sh_css_load_firmware(struct device *dev, const char *fw_data,
-unsigned int fw_size) {
+unsigned int fw_size)
+{
unsigned int i;
struct ia_css_fw_info *binaries;
struct sh_css_fw_bi_file_h *file_header;
@@ -260,8 +261,7 @@ sh_css_load_firmware(struct device *dev, const char
*fw_data,
sh_css_num_binaries = file_header->binary_nr;
/* Only allocate memory for ISP blob info */
- if (sh_css_num_binaries > NUM_OF_SPS)
- {
+ if (sh_css_num_binaries > NUM_OF_SPS) {
sh_css_blob_info = kmalloc(
(sh_css_num_binaries - NUM_OF_SPS) *
sizeof(*sh_css_blob_info), GFP_KERNEL);
@@ -276,8 +276,7 @@ sh_css_load_firmware(struct device *dev, const char
*fw_data,
if (!fw_minibuffer)
return -ENOMEM;
- for (i = 0; i < sh_css_num_binaries; i++)
- {
+ for (i = 0; i < sh_css_num_binaries; i++) {
struct ia_css_fw_info *bi = &binaries[i];
/*
* note: the var below is made static as it is quite large;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 3/4] staging: media: atomisp: fix trailing statement of if
this patch fixes the error from checkpatch.pl which says that trailing statements after if keyword to be on next line Signed-off-by: Rohit K Bharadwaj --- v3: change patch subject prefix v2: split patch into sequence of patches v1: fix all coding style issues in single patch drivers/staging/media/atomisp/pci/sh_css_firmware.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/media/atomisp/pci/sh_css_firmware.c b/drivers/staging/media/atomisp/pci/sh_css_firmware.c index 988785ab6c95..2208453cbef0 100644 --- a/drivers/staging/media/atomisp/pci/sh_css_firmware.c +++ b/drivers/staging/media/atomisp/pci/sh_css_firmware.c @@ -115,7 +115,8 @@ sh_css_load_blob_info(const char *fw, const struct ia_css_fw_info *bi, return -EINVAL; /* Special case: only one binary in fw */ - if (!bi) bi = (const struct ia_css_fw_info *)fw; + if (!bi) + bi = (const struct ia_css_fw_info *)fw; name = fw + bi->blob.prog_name_offset; blob = (const unsigned char *)fw + bi->blob.offset; -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 4/4] staging: media: atomisp: fix line length exceeds
this patch fixes the line length exceeded error from checkpatch.pl
Signed-off-by: Rohit K Bharadwaj
---
v3: change patch subject prefix
v2: split patch into sequence of patches
v1: fix all coding style issues in single patch
drivers/staging/media/atomisp/pci/sh_css_firmware.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
index 2208453cbef0..6e8f45e38804 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
@@ -243,7 +243,8 @@ sh_css_load_firmware(struct device *dev, const char
*fw_data,
firmware_header = (struct firmware_header *)fw_data;
file_header = &firmware_header->file_header;
binaries = &firmware_header->binary_header;
- strscpy(FW_rel_ver_name, file_header->version,
min(sizeof(FW_rel_ver_name), sizeof(file_header->version)));
+ strscpy(FW_rel_ver_name, file_header->version,
+ min(sizeof(FW_rel_ver_name), sizeof(file_header->version)));
ret = sh_css_check_firmware_version(dev, fw_data);
if (ret) {
IA_CSS_ERROR("CSS code version (%s) and firmware version (%s)
mismatch!",
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/4] staging: media: atomisp: fix style of block comments
On 26/07/20 2:42 pm, Greg KH wrote:
> On Sun, Jul 26, 2020 at 02:35:10PM +0530, Rohit K Bharadwaj wrote:
>> this patch fixes the coding style of block comments.
>>
>> Signed-off-by: Rohit K Bharadwaj
>> ---
>> v3: change patch subject prefix
>> v2: split patch into sequence of patches
>> v1: fix all coding style issues in single patch
>>
>> .../media/atomisp/pci/sh_css_firmware.c | 28 +--
>> 1 file changed, 19 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
>> b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
>> index d4ab15b6d1ac..2907aead98b7 100644
>> --- a/drivers/staging/media/atomisp/pci/sh_css_firmware.c
>> +++ b/drivers/staging/media/atomisp/pci/sh_css_firmware.c
>> @@ -51,9 +51,12 @@ struct fw_param {
>>
>> static struct firmware_header *firmware_header;
>>
>> -/* The string STR is a place holder
>> +/*
>> + * The string STR is a place holder
>> * which will be replaced with the actual RELEASE_VERSION
>> - * during package generation. Please do not modify */
>> + * during package generation. Please do not modify
>> + */
>> +
>
> Why the blank line?
>
Sir, I thought that it would improve the readability of the code and would help
easily distinguish comments from the variable declaration part, and also since
there was a blank line between the start of comment and the static struct
firmware_header variable, I thought of putting a blank line after the comment
end as well to maintain symmetry.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 2/4] staging: media: atomisp: fix style of open brace
On 26/07/20 3:12 pm, Mauro Carvalho Chehab wrote:
> Em Sun, 26 Jul 2020 14:35:12 +0530
> Rohit K Bharadwaj escreveu:
>
>> this patch fixes style of open brace after functions and if statements
>>
>> Signed-off-by: Rohit K Bharadwaj
>
>> @@ -119,8 +121,9 @@ sh_css_load_blob_info(const char *fw, const struct
>> ia_css_fw_info *bi,
>> blob = (const unsigned char *)fw + bi->blob.offset;
>>
>> /* sanity check */
>> -if (bi->blob.size != bi->blob.text_size + bi->blob.icache_size +
>> bi->blob.data_size + bi->blob.padding_size)
>> -{
>> +if (bi->blob.size !=
>> +bi->blob.text_size + bi->blob.icache_size +
>> +bi->blob.data_size + bi->blob.padding_size) {
>
>
> Please adjust the alignments here. I'm pretty sure checkpatch --strict
> will end complaining with the above, as the first line ends with "=".
>
> I would, instead, code it as:
>
> if (bi->blob.size != bi->blob.text_size + bi->blob.icache_size +
>bi->blob.data_size + bi->blob.padding_size) {
>
>
> Thanks,
> Mauro
>
sure sir, do I have to make a v4 of the patch and send all the patches in this
series again or should I just send this one particular patch again?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: nvec: change usage of slave to secondary
On 02/08/20 1:43 pm, Marc Dietrich wrote:
> Hello Rohit,
>
> On Sat, 25 Jul 2020, Rohit K Bharadwaj wrote:
>
>> changed usage of slave (which is deprecated) to secondary without breaking
>> the driver
>>
>> Tested-by: Dan Carpenter
>> Acked-by: Marc Dietrich
>> Signed-off-by: Rohit K Bharadwaj
>
> please don't add "*-by"'s by yourself when you send a new patch version.
> These will be added "automatically" during the patch handling. I just said, I
> *will* ack your patch, when you resent it, not that I did it already.
>
> Thanks!
>
> Marc
>
>> ---
>> v4: undo the changes (which broke the driver) to this line: if
>> (of_property_read_u32(dev->of_node, "slave-addr", &nvec->i2c_addr))
>> v3: change patch subject, add version history
>> v2: add changelog text in body of mail
>> v1: fix style issues by changing usage of slave to secondary
>>
>> drivers/staging/nvec/nvec.c | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
>> index 360ec0407740..a7e995bfe989 100644
>> --- a/drivers/staging/nvec/nvec.c
>> +++ b/drivers/staging/nvec/nvec.c
>> @@ -718,7 +718,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>> return IRQ_HANDLED;
>> }
>>
>> -static void tegra_init_i2c_slave(struct nvec_chip *nvec)
>> +static void tegra_init_i2c_secondary(struct nvec_chip *nvec)
>> {
>> u32 val;
>>
>> @@ -744,7 +744,7 @@ static void tegra_init_i2c_slave(struct nvec_chip *nvec)
>> }
>>
>> #ifdef CONFIG_PM_SLEEP
>> -static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
>> +static void nvec_disable_i2c_secondary(struct nvec_chip *nvec)
>> {
>> disable_irq(nvec->irq);
>> writel(I2C_SL_NEWSL | I2C_SL_NACK, nvec->base + I2C_SL_CNFG);
>> @@ -839,7 +839,7 @@ static int tegra_nvec_probe(struct platform_device *pdev)
>> }
>> disable_irq(nvec->irq);
>>
>> - tegra_init_i2c_slave(nvec);
>> + tegra_init_i2c_secondary(nvec);
>>
>> /* enable event reporting */
>> nvec_toggle_global_events(nvec, true);
>> @@ -913,7 +913,7 @@ static int nvec_suspend(struct device *dev)
>> if (!err)
>> nvec_msg_free(nvec, msg);
>>
>> - nvec_disable_i2c_slave(nvec);
>> + nvec_disable_i2c_secondary(nvec);
>>
>> return 0;
>> }
>> @@ -923,7 +923,7 @@ static int nvec_resume(struct device *dev)
>> struct nvec_chip *nvec = dev_get_drvdata(dev);
>>
>> dev_dbg(nvec->dev, "resuming\n");
>> - tegra_init_i2c_slave(nvec);
>> + tegra_init_i2c_secondary(nvec);
>> nvec_toggle_global_events(nvec, true);
>>
>> return 0;
>> --
>> 2.25.1
>>
>>
I'm sorry for the tags sir, I would make sure not to make the mistakes in
future, Thanks for taking your time, I hope I can contribute on other aspects
of Linux kernel.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
