Re: [PATCH v4] staging: comedi: comedi_fops.c: added casts to get rid of sparse warnings
On 16/07/2020 16:25, B K Karthik wrote: fixed sparse warnings by adding a cast in assignment from void [noderef] __user * to unsigned int __force * and a reverse cast in argument from unsigned int * to unsigned int __user * . v1 -> v2: - Add a reverse cast in argument v2 -> v3: - Change commit description as suggested by Ian Abott v3 -> v4: - Add versioning information in commit description For future reference, the patch change history should go below the "---" divider line below where git will ignore it so that it does not appear in the final commit description. Otherwise, the committer would need to edit it out manually. Signed-off-by: B K Karthik --- drivers/staging/comedi/comedi_fops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c index 3f70e5dfac39..9cdc1e8a022d 100644 --- a/drivers/staging/comedi/comedi_fops.c +++ b/drivers/staging/comedi/comedi_fops.c @@ -2956,7 +2956,7 @@ static int get_compat_cmd(struct comedi_cmd *cmd, cmd->scan_end_arg = v32.scan_end_arg; cmd->stop_src = v32.stop_src; cmd->stop_arg = v32.stop_arg; - cmd->chanlist = compat_ptr(v32.chanlist); + cmd->chanlist = (unsigned int __force *)compat_ptr(v32.chanlist); cmd->chanlist_len = v32.chanlist_len; cmd->data = compat_ptr(v32.data); cmd->data_len = v32.data_len; @@ -2983,7 +2983,7 @@ static int put_compat_cmd(struct comedi32_cmd_struct __user *cmd32, v32.stop_src = cmd->stop_src; v32.stop_arg = cmd->stop_arg; /* Assume chanlist pointer is unchanged. */ - v32.chanlist = ptr_to_compat(cmd->chanlist); + v32.chanlist = ptr_to_compat((unsigned int __user *)cmd->chanlist); v32.chanlist_len = cmd->chanlist_len; v32.data = ptr_to_compat(cmd->data); v32.data_len = cmd->data_len; Still looks good. Reviewed-by: Ian Abbott -- -=( Ian Abbott || Web: www.mev.co.uk )=- -=( MEV Ltd. is a company registered in England & Wales. )=- -=( Registered number: 02862268. Registered address:)=- -=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: comedi: comedi_fops.c: added casts to get rid of sparse warnings
On Thu, Jul 16, 2020 at 11:25:48AM -0400, B K Karthik wrote: > fixed sparse warnings by adding a cast in assignment from > void [noderef] __user * to unsigned int __force * > and a reverse cast in argument from > unsigned int * to unsigned int __user * . > > v1 -> v2: > - Add a reverse cast in argument > v2 -> v3: > - Change commit description as suggested by Ian Abott > v3 -> v4: > - Add versioning information in commit description As Ian said, all of that goes below the --- line so it will not show up in the changelog text. As I don't want to hand-edit changelog text, as it does not scale, can you please fix this up and resend as a v5? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v5] staging: comedi: comedi_fops.c: added casts to get rid of sparse warnings
fixed sparse warnings by adding a cast in assignment from void [noderef] __user * to unsigned int __force * and a reverse cast in argument from unsigned int * to unsigned int __user * . Signed-off-by: B K Karthik Reviewed-by: Ian Abbott --- v1 -> v2: - Added a reverse cast in argument v2 -> v3: - Changed commit description v3 -> v4: - Added versioning info in commit description v4 -> v5: - Move versioning info below the divider line drivers/staging/comedi/comedi_fops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c index 3f70e5dfac39..9cdc1e8a022d 100644 --- a/drivers/staging/comedi/comedi_fops.c +++ b/drivers/staging/comedi/comedi_fops.c @@ -2956,7 +2956,7 @@ static int get_compat_cmd(struct comedi_cmd *cmd, cmd->scan_end_arg = v32.scan_end_arg; cmd->stop_src = v32.stop_src; cmd->stop_arg = v32.stop_arg; - cmd->chanlist = compat_ptr(v32.chanlist); + cmd->chanlist = (unsigned int __force *)compat_ptr(v32.chanlist); cmd->chanlist_len = v32.chanlist_len; cmd->data = compat_ptr(v32.data); cmd->data_len = v32.data_len; @@ -2983,7 +2983,7 @@ static int put_compat_cmd(struct comedi32_cmd_struct __user *cmd32, v32.stop_src = cmd->stop_src; v32.stop_arg = cmd->stop_arg; /* Assume chanlist pointer is unchanged. */ - v32.chanlist = ptr_to_compat(cmd->chanlist); + v32.chanlist = ptr_to_compat((unsigned int __user *)cmd->chanlist); v32.chanlist_len = cmd->chanlist_len; v32.data = ptr_to_compat(cmd->data); v32.data_len = cmd->data_len; -- 2.20.1 signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Greetings
Hello, Acknowledge please if you still use this e-mail. There is a heritage that has your surname. get in touch at:zhuq...@gmail.com Thanks, Qi ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: linux/drivers/staging/pi433/
On Fri, Jul 17, 2020 at 12:11:50PM +0100, christopher tyerman wrote: > hello > > Im looking for information on the pi433 driver. Who is currently > maintaining the driver? as the original author appears not to have made > any alterations since the original commit, and links are no longer valid. Any reason you didn't cc: that developer here? > Im looking to determine what would be necessary to confirm/implement > functionality using the RFM69HCW and, initially, more specifically the > SparkFun RFM69 Breakout( https://www.sparkfun.com/products/12823). No idea, try it and see! > As a side question can you tell what or where i can find information on > driver naming conventions? as the pi433 driver to me looks like it > should really be named after the RFM69 series of chips/modules rather > than a specific PCB for that module which appears to not be available > and multiple alternatives exist for. If you think it should be renamed, and want to do the work here to fix it up and get it out of staging, great, please do! thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: linux/drivers/staging/pi433/
On Fri, Jul 17, 2020 at 12:11:50PM +0100, christopher tyerman wrote: > hello > > Im looking for information on the pi433 driver. Who is currently > maintaining the driver? as the original author appears not to have made > any alterations since the original commit, and links are no longer valid. Looks like no one is. > > Im looking to determine what would be necessary to confirm/implement > functionality using the RFM69HCW and, initially, more specifically the > SparkFun RFM69 Breakout( https://www.sparkfun.com/products/12823). > > As a side question can you tell what or where i can find information on > driver naming conventions? as the pi433 driver to me looks like it > should really be named after the RFM69 series of chips/modules rather > than a specific PCB for that module which appears to not be available > and multiple alternatives exist for. That sounds reasonable. We can't Ack patches we haven't seen but probably you can rename anything that you want to. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] staging: comedi: INSN_CONFIG_DIGITAL_TRIG fixes
These patches correct problems with INSN_CONFIG_DIGITAL_TRIG comedi
configuration instructions in various comedi drivers, in particular the
use of unconstrained bit shift amounts from userspace leading to
undefined behaviour (although hopefully not the kernel crashy sort).
The patches have been marked for inclusion in the stable tree. Note
that patch 4 changes a similar area of code to Dan Carpenter's commit
ef75e14a6c93 ("staging: comedi: verify array index is correct before
using it"), so I have indicated it as a prerequisite.
*Note to Greg KH*: I have based these patches on your "staging-linus"
branch due to the prerequisite ef75e14a6c93 mentioned above being
present in neither "staging-next" nor "staging-testing" at the time of
posting.
1) staging: comedi: ni_6527: fix INSN_CONFIG_DIGITAL_TRIG support
2) staging: comedi: addi_apci_1032: check INSN_CONFIG_DIGITAL_TRIG shift
3) staging: comedi: addi_apci_1564: check INSN_CONFIG_DIGITAL_TRIG shift
4) staging: comedi: addi_apci_1500: check INSN_CONFIG_DIGITAL_TRIG shift
drivers/staging/comedi/drivers/addi_apci_1032.c | 20 ++--
drivers/staging/comedi/drivers/addi_apci_1500.c | 24 +++-
drivers/staging/comedi/drivers/addi_apci_1564.c | 20 ++--
drivers/staging/comedi/drivers/ni_6527.c| 2 +-
4 files changed, 48 insertions(+), 18 deletions(-)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] staging: comedi: addi_apci_1032: check INSN_CONFIG_DIGITAL_TRIG shift
The `INSN_CONFIG` comedi instruction with sub-instruction code
`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
used as a right shift amount for other bitmask values without being
checked. Shift amounts greater than or equal to 32 will result in
undefined behavior. Add code to deal with this.
Fixes: 33cdce6293dcc ("staging: comedi: addi_apci_1032: conform to new
INSN_CONFIG_DIGITAL_TRIG"
Cc: #3.8+
Signed-off-by: Ian Abbott
---
.../staging/comedi/drivers/addi_apci_1032.c | 20 +--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi_apci_1032.c
b/drivers/staging/comedi/drivers/addi_apci_1032.c
index 560649be9d13..e035c9f757a1 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1032.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1032.c
@@ -106,14 +106,22 @@ static int apci1032_cos_insn_config(struct comedi_device
*dev,
unsigned int *data)
{
struct apci1032_private *devpriv = dev->private;
- unsigned int shift, oldmask;
+ unsigned int shift, oldmask, himask, lomask;
switch (data[0]) {
case INSN_CONFIG_DIGITAL_TRIG:
if (data[1] != 0)
return -EINVAL;
shift = data[3];
- oldmask = (1U << shift) - 1;
+ if (shift < 32) {
+ oldmask = (1U << shift) - 1;
+ himask = data[4] << shift;
+ lomask = data[5] << shift;
+ } else {
+ oldmask = 0xu;
+ himask = 0;
+ lomask = 0;
+ }
switch (data[2]) {
case COMEDI_DIGITAL_TRIG_DISABLE:
devpriv->ctrl = 0;
@@ -136,8 +144,8 @@ static int apci1032_cos_insn_config(struct comedi_device
*dev,
devpriv->mode2 &= oldmask;
}
/* configure specified channels */
- devpriv->mode1 |= data[4] << shift;
- devpriv->mode2 |= data[5] << shift;
+ devpriv->mode1 |= himask;
+ devpriv->mode2 |= lomask;
break;
case COMEDI_DIGITAL_TRIG_ENABLE_LEVELS:
if (devpriv->ctrl != (APCI1032_CTRL_INT_ENA |
@@ -154,8 +162,8 @@ static int apci1032_cos_insn_config(struct comedi_device
*dev,
devpriv->mode2 &= oldmask;
}
/* configure specified channels */
- devpriv->mode1 |= data[4] << shift;
- devpriv->mode2 |= data[5] << shift;
+ devpriv->mode1 |= himask;
+ devpriv->mode2 |= lomask;
break;
default:
return -EINVAL;
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] staging: comedi: addi_apci_1500: check INSN_CONFIG_DIGITAL_TRIG shift
The `INSN_CONFIG` comedi instruction with sub-instruction code
`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
used as a right shift amount for other bitmask values without being
checked. Shift amounts greater than or equal to 32 will result in
undefined behavior. Add code to deal with this, adjusting the checks
for invalid channels so that enabled channel bits that would have been
lost by shifting are also checked for validity. Only channels 0 to 15
are valid.
Fixes: a8c66b684efaf ("staging: comedi: addi_apci_1500: rewrite the subdevice
support functions")
Cc: #4.0+: ef75e14a6c93: staging: comedi: verify array
index is correct before using it
Cc: #4.0+
Signed-off-by: Ian Abbott
---
.../staging/comedi/drivers/addi_apci_1500.c | 24 +++
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi_apci_1500.c
b/drivers/staging/comedi/drivers/addi_apci_1500.c
index 689acd69a1b9..816dd25b9d0e 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1500.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1500.c
@@ -452,13 +452,14 @@ static int apci1500_di_cfg_trig(struct comedi_device *dev,
struct apci1500_private *devpriv = dev->private;
unsigned int trig = data[1];
unsigned int shift = data[3];
- unsigned int hi_mask = data[4] << shift;
- unsigned int lo_mask = data[5] << shift;
- unsigned int chan_mask = hi_mask | lo_mask;
- unsigned int old_mask = (1 << shift) - 1;
+ unsigned int hi_mask;
+ unsigned int lo_mask;
+ unsigned int chan_mask;
+ unsigned int old_mask;
unsigned int pm;
unsigned int pt;
unsigned int pp;
+ unsigned int invalid_chan;
if (trig > 1) {
dev_dbg(dev->class_dev,
@@ -466,7 +467,20 @@ static int apci1500_di_cfg_trig(struct comedi_device *dev,
return -EINVAL;
}
- if (chan_mask > 0x) {
+ if (shift <= 16) {
+ hi_mask = data[4] << shift;
+ lo_mask = data[5] << shift;
+ old_mask = (1U << shift) - 1;
+ invalid_chan = (data[4] | data[5]) >> (16 - shift);
+ } else {
+ hi_mask = 0;
+ lo_mask = 0;
+ old_mask = 0x;
+ invalid_chan = data[4] | data[5];
+ }
+ chan_mask = hi_mask | lo_mask;
+
+ if (invalid_chan) {
dev_dbg(dev->class_dev, "invalid digital trigger channel\n");
return -EINVAL;
}
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging: comedi: addi_apci_1564: check INSN_CONFIG_DIGITAL_TRIG shift
The `INSN_CONFIG` comedi instruction with sub-instruction code
`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
used as a right shift amount for other bitmask values without being
checked. Shift amounts greater than or equal to 32 will result in
undefined behavior. Add code to deal with this.
Fixes: 1e15687ea472 ("staging: comedi: addi_apci_1564: add Change-of-State
interrupt subdevice and required functions"
Cc: #3.17+
Signed-off-by: Ian Abbott
---
.../staging/comedi/drivers/addi_apci_1564.c | 20 +--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index 10501fe6bb25..1268ba34be5f 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -331,14 +331,22 @@ static int apci1564_cos_insn_config(struct comedi_device
*dev,
unsigned int *data)
{
struct apci1564_private *devpriv = dev->private;
- unsigned int shift, oldmask;
+ unsigned int shift, oldmask, himask, lomask;
switch (data[0]) {
case INSN_CONFIG_DIGITAL_TRIG:
if (data[1] != 0)
return -EINVAL;
shift = data[3];
- oldmask = (1U << shift) - 1;
+ if (shift < 32) {
+ oldmask = (1U << shift) - 1;
+ himask = data[4] << shift;
+ lomask = data[5] << shift;
+ } else {
+ oldmask = 0xu;
+ himask = 0;
+ lomask = 0;
+ }
switch (data[2]) {
case COMEDI_DIGITAL_TRIG_DISABLE:
devpriv->ctrl = 0;
@@ -362,8 +370,8 @@ static int apci1564_cos_insn_config(struct comedi_device
*dev,
devpriv->mode2 &= oldmask;
}
/* configure specified channels */
- devpriv->mode1 |= data[4] << shift;
- devpriv->mode2 |= data[5] << shift;
+ devpriv->mode1 |= himask;
+ devpriv->mode2 |= lomask;
break;
case COMEDI_DIGITAL_TRIG_ENABLE_LEVELS:
if (devpriv->ctrl != (APCI1564_DI_IRQ_ENA |
@@ -380,8 +388,8 @@ static int apci1564_cos_insn_config(struct comedi_device
*dev,
devpriv->mode2 &= oldmask;
}
/* configure specified channels */
- devpriv->mode1 |= data[4] << shift;
- devpriv->mode2 |= data[5] << shift;
+ devpriv->mode1 |= himask;
+ devpriv->mode2 |= lomask;
break;
default:
return -EINVAL;
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging: comedi: ni_6527: fix INSN_CONFIG_DIGITAL_TRIG support
`ni6527_intr_insn_config()` processes `INSN_CONFIG` comedi instructions
for the "interrupt" subdevice. When `data[0]` is
`INSN_CONFIG_DIGITAL_TRIG` it is configuring the digital trigger. When
`data[2]` is `COMEDI_DIGITAL_TRIG_ENABLE_EDGES` it is configuring rising
and falling edge detection for the digital trigger, using a base channel
number (or shift amount) in `data[3]`, a rising edge bitmask in
`data[4]` and falling edge bitmask in `data[5]`.
If the base channel number (shift amount) is greater than or equal to
the number of channels (24) of the digital input subdevice, there are no
changes to the rising and falling edges, so the mask of channels to be
changed can be set to 0, otherwise the mask of channels to be changed,
and the rising and falling edge bitmasks are shifted by the base channel
number before calling `ni6527_set_edge_detection()` to change the
appropriate registers. Unfortunately, the code is comparing the base
channel (shift amount) to the interrupt subdevice's number of channels
(1) instead of the digital input subdevice's number of channels (24).
Fix it by comparing to 32 because all shift amounts for an `unsigned
int` must be less than that and everything from bit 24 upwards is
ignored by `ni6527_set_edge_detection()` anyway.
Fixes: 110f9e687c1a8 ("staging: comedi: ni_6527: support
INSN_CONFIG_DIGITAL_TRIG")
Cc: # 3.17+
Signed-off-by: Ian Abbott
---
drivers/staging/comedi/drivers/ni_6527.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/ni_6527.c
b/drivers/staging/comedi/drivers/ni_6527.c
index 4d1eccb5041d..4518c2680b7c 100644
--- a/drivers/staging/comedi/drivers/ni_6527.c
+++ b/drivers/staging/comedi/drivers/ni_6527.c
@@ -332,7 +332,7 @@ static int ni6527_intr_insn_config(struct comedi_device
*dev,
case COMEDI_DIGITAL_TRIG_ENABLE_EDGES:
/* check shift amount */
shift = data[3];
- if (shift >= s->n_chan) {
+ if (shift >= 32) {
mask = 0;
rising = 0;
falling = 0;
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192e: Fixed the space and indentation coding styles
rtllib_crypt_ccmp.c: Fixed the error - space required before the
open parenthesis '(' on line #281.
rtllib_crypt_ccmp.c: Fixed the warning - suspect code indent for
conditional statements on line #338
Signed-off-by: Darshan D V
---
drivers/staging/rtl8192e/rtllib_crypt_ccmp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c
b/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c
index 0cbf4a1a326b..b60e2a109ce4 100644
--- a/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c
+++ b/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c
@@ -278,7 +278,7 @@ static int rtllib_ccmp_decrypt(struct sk_buff *skb, int
hdr_len, void *priv)
int aad_len, ret;
req = aead_request_alloc(key->tfm, GFP_ATOMIC);
- if(!req)
+ if (!req)
return -ENOMEM;
aad_len = ccmp_init_iv_and_aad(hdr, pn, iv, aad);
@@ -337,7 +337,7 @@ static int rtllib_ccmp_set_key(void *key, int len, u8 *seq,
void *priv)
}
if (crypto_aead_setauthsize(data->tfm, CCMP_MIC_LEN) ||
crypto_aead_setkey(data->tfm, data->key, CCMP_TK_LEN))
- return -1;
+ return -1;
} else if (len == 0) {
data->key_set = 0;
} else {
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
linux/drivers/staging/pi433/
hello Im looking for information on the pi433 driver. Who is currently maintaining the driver? as the original author appears not to have made any alterations since the original commit, and links are no longer valid. Im looking to determine what would be necessary to confirm/implement functionality using the RFM69HCW and, initially, more specifically the SparkFun RFM69 Breakout( https://www.sparkfun.com/products/12823). As a side question can you tell what or where i can find information on driver naming conventions? as the pi433 driver to me looks like it should really be named after the RFM69 series of chips/modules rather than a specific PCB for that module which appears to not be available and multiple alternatives exist for. Thank you for your time. Christopher tyerman ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 2/9] media: staging: dt-bindings: rkisp1: add required items in i2c example
On Thu, Jul 2, 2020 at 1:13 PM Helen Koike wrote:
>
> Add missing required items in Rockchip ISP1 dt-bindings example for
> a complete i2c node.
>
> Signed-off-by: Helen Koike
> ---
>
> Changes in v2:
> - new patch in the series
> ---
> .../devicetree/bindings/media/rockchip-isp1.yaml | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
>
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> index a77b6ec500c95..8c7904845788d 100644
> ---
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> +++
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> @@ -169,6 +169,11 @@ examples:
> };
>
> i2c7: i2c@ff16 {
> +compatible = "rockchip,rk3399-i2c";
> +reg = <0x0 0xff16 0x0 0x1000>;
This will give a warning now as the default cell sizes are 1.
> +interrupts = ;
> +clocks = <&cru SCLK_I2C7>, <&cru PCLK_I2C7>;
> +clock-names = "i2c", "pclk";
Just drop the unit address rather than adding all this.
> clock-frequency = <40>;
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.26.0
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/9] media: staging: dt-bindings: rkisp1: add missing required nodes
On Thu, Jul 2, 2020 at 1:13 PM Helen Koike wrote: > > Add missing required nodes in json-schema yaml file for > Rockchip ISP1 dt-bindings. > > Signed-off-by: Helen Koike > --- > > Changes in v2: > - New patch in the series > --- > .../devicetree/bindings/media/rockchip-isp1.yaml | 8 > 1 file changed, 8 insertions(+) Acked-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 3/9] media: staging: dt-bindings: rkisp1: re-order properties
On Thu, Jul 2, 2020 at 1:13 PM Helen Koike wrote: > > Organize properties order in dt-binbings to move it out of staging. typo > > On top: compatible, reg and interrupts. > Then alphabetical order, then properties starting with '#'. > > Signed-off-by: Helen Koike > > --- > > V2: > - this is a new patch in the series > --- > .../bindings/media/rockchip-isp1.yaml | 32 +-- > 1 file changed, 16 insertions(+), 16 deletions(-) Acked-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 4/9] media: staging: dt-bindings: rkisp1: fix "no reg" error in parent node
On Thu, Jul 2, 2020 at 1:13 PM Helen Koike wrote:
>
> Fix the following error found with make ARCH=arm64 dt_binding_check:
>
> Documentation/devicetree/bindings/media/rockchip-isp1.example.dts:24.27-101.11:
> Warning (unit_address_vs_reg): /example-0/parent@0: node has a unit name, but
> no reg or ranges property
>
> Reported-by: Johan Jonker
> Signed-off-by: Helen Koike
> ---
>
> V3:
> - this is a new patch in the series
> ---
> .../Documentation/devicetree/bindings/media/rockchip-isp1.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
>
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> index e5b9c0574e352..4d111ef2e89c7 100644
> ---
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> +++
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> @@ -126,6 +126,7 @@ examples:
> #include
>
> parent0: parent@0 {
> +reg = <0 0>;
Just drop the unit-address.
> #address-cells = <2>;
> #size-cells = <2>;
>
> --
> 2.26.0
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 5/9] media: staging: rkisp1: remove unecessary clocks
On Thu, Jul 2, 2020 at 1:13 PM Helen Koike wrote:
>
> aclk_isp_wrap is a child of aclk_isp, and hclk_isp_wrap is a child of
> hclk_isp, thus we can remove parents from the list.
But it looks like it is the wrap clocks you are removing.
>
> Also, for the isp0, we only need the ISP clock, ACLK and HCLK.
> In the future we'll need a pixel clock for RK3288 and RK3399, and a JPEG
> clock for RK3288.
>
> So with the goal to cleanup the dt-bindings and remove it from staging,
> simplify clock names to isp, aclk and hclk.
>
> For reference, this is the isp clock topology on RK3399:
>
> xin24m
> pll_npll
>npll
> clk_isp1
> clk_isp0
> pll_cpll
>cpll
> aclk_isp1
> aclk_isp1_noc
> hclk_isp1
> aclk_isp1_wrapper
> hclk_isp1_noc
> aclk_isp0
> hclk_isp1_wrapper
> aclk_isp0_wrapper
> aclk_isp0_noc
> hclk_isp0
> hclk_isp0_wrapper
> hclk_isp0_noc
> pclkin_isp1_wrapper
>
> Signed-off-by: Helen Koike
>
> ---
>
> Changes in V4:
> - update binding according to suggestion by Robin Murphy
> on https://patchwork.kernel.org/patch/11475007/
>
> Changes in V3:
> - this is a new patch in the series
> ---
> .../bindings/media/rockchip-isp1.yaml | 30 +--
> drivers/staging/media/rkisp1/rkisp1-dev.c | 8 ++---
> 2 files changed, 17 insertions(+), 21 deletions(-)
>
> diff --git
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
>
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> index 4d111ef2e89c7..f10c53d008748 100644
> ---
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> +++
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> @@ -24,20 +24,20 @@ properties:
> maxItems: 1
>
>clocks:
> -items:
> - - description: ISP clock
> - - description: ISP AXI clock clock
> - - description: ISP AXI clock wrapper clock
> - - description: ISP AHB clock clock
> - - description: ISP AHB wrapper clock
This is the correct way to describe multiple clocks.
> +maxItems: 5
Now the 4th and 5th clock are undefined.
> +minItems: 3
> +description:
> + ISP clock
> + ISP AXI clock
> + ISP AHB clock
>
>clock-names:
> +maxItems: 5
This should not be more than the number of entries in 'items'.
> +minItems: 3
> items:
> - - const: clk_isp
> - - const: aclk_isp
> - - const: aclk_isp_wrap
> - - const: hclk_isp
> - - const: hclk_isp_wrap
> + - const: isp
> + - const: aclk
> + - const: hclk
>
>iommus:
> maxItems: 1
> @@ -135,11 +135,9 @@ examples:
> reg = <0x0 0xff91 0x0 0x4000>;
> interrupts = ;
> clocks = <&cru SCLK_ISP0>,
> - <&cru ACLK_ISP0>, <&cru ACLK_ISP0_WRAPPER>,
> - <&cru HCLK_ISP0>, <&cru HCLK_ISP0_WRAPPER>;
> -clock-names = "clk_isp",
> - "aclk_isp", "aclk_isp_wrap",
> - "hclk_isp", "hclk_isp_wrap";
> + <&cru ACLK_ISP0_WRAPPER>,
> + <&cru HCLK_ISP0_WRAPPER>;
> +clock-names = "isp", "aclk", "hclk";
> iommus = <&isp0_mmu>;
> phys = <&dphy>;
> phy-names = "dphy";
> diff --git a/drivers/staging/media/rkisp1/rkisp1-dev.c
> b/drivers/staging/media/rkisp1/rkisp1-dev.c
> index f38801fea10d9..175ac25fe99fa 100644
> --- a/drivers/staging/media/rkisp1/rkisp1-dev.c
> +++ b/drivers/staging/media/rkisp1/rkisp1-dev.c
> @@ -406,11 +406,9 @@ static irqreturn_t rkisp1_isr(int irq, void *ctx)
> }
>
> static const char * const rk3399_isp_clks[] = {
> - "clk_isp",
> - "aclk_isp",
> - "hclk_isp",
> - "aclk_isp_wrap",
> - "hclk_isp_wrap",
> + "isp",
> + "aclk",
> + "hclk",
> };
>
> static const struct rkisp1_match_data rk3399_isp_clk_data = {
> --
> 2.26.0
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 5/9] media: staging: rkisp1: remove unecessary clocks
Hi Rob, Thanks for your review. On 7/17/20 2:49 PM, Rob Herring wrote: > On Thu, Jul 2, 2020 at 1:13 PM Helen Koike wrote: >> >> aclk_isp_wrap is a child of aclk_isp, and hclk_isp_wrap is a child of >> hclk_isp, thus we can remove parents from the list. > > But it looks like it is the wrap clocks you are removing. >From this binding yes, but the idea is to add in the dt wherever clock responsible for the full ACLK path for instance. In the example below, clock aclk_isp is ACLK_ISP0_WRAPPER. Does this make sense? > >> >> Also, for the isp0, we only need the ISP clock, ACLK and HCLK. >> In the future we'll need a pixel clock for RK3288 and RK3399, and a JPEG >> clock for RK3288. >> >> So with the goal to cleanup the dt-bindings and remove it from staging, >> simplify clock names to isp, aclk and hclk. >> >> For reference, this is the isp clock topology on RK3399: >> >> xin24m >> pll_npll >>npll >> clk_isp1 >> clk_isp0 >> pll_cpll >>cpll >> aclk_isp1 >> aclk_isp1_noc >> hclk_isp1 >> aclk_isp1_wrapper >> hclk_isp1_noc >> aclk_isp0 >> hclk_isp1_wrapper >> aclk_isp0_wrapper >> aclk_isp0_noc >> hclk_isp0 >> hclk_isp0_wrapper >> hclk_isp0_noc >> pclkin_isp1_wrapper >> >> Signed-off-by: Helen Koike >> >> --- >> >> Changes in V4: >> - update binding according to suggestion by Robin Murphy >> on https://patchwork.kernel.org/patch/11475007/ >> >> Changes in V3: >> - this is a new patch in the series >> --- >> .../bindings/media/rockchip-isp1.yaml | 30 +-- >> drivers/staging/media/rkisp1/rkisp1-dev.c | 8 ++--- >> 2 files changed, 17 insertions(+), 21 deletions(-) >> >> diff --git >> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml >> >> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml >> index 4d111ef2e89c7..f10c53d008748 100644 >> --- >> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml >> +++ >> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml >> @@ -24,20 +24,20 @@ properties: >> maxItems: 1 >> >>clocks: >> -items: >> - - description: ISP clock >> - - description: ISP AXI clock clock >> - - description: ISP AXI clock wrapper clock >> - - description: ISP AHB clock clock >> - - description: ISP AHB wrapper clock > > This is the correct way to describe multiple clocks. The idea was to prepare for rk3288 and rk3399 isp1, as suggested here https://patchwork.kernel.org/patch/11475007/#23462085 Or should we do: clocks: oneOf: # rk3288 clocks - items: - description: ISP clock - description: ISP AXI clock - description: ISP AHB clock - description: ISP Pixel clock - description: ISP JPEG source clock # rk3399 isp0 clocks - items: - description: ISP clock - description: ISP AXI clock - description: ISP AHB clock # rk3399 isp1 clocks - items: - description: ISP clock - description: ISP AXI clock - description: ISP AHB clock - description: ISP Pixel clock ? > >> +maxItems: 5 > > Now the 4th and 5th clock are undefined. > >> +minItems: 3 >> +description: >> + ISP clock >> + ISP AXI clock >> + ISP AHB clock >> >>clock-names: >> +maxItems: 5 > > This should not be more than the number of entries in 'items'. > If we follow what I wrote above, should we have: clock-names: oneOf: # rk3288 clocks - items: - const: clk_isp - const: aclk_isp - const: hclk_isp - const: pclk_isp_in - const: sclk_isp_jpe # rk3399 isp0 clocks - items: - const: clk_isp - const: aclk_isp - const: hclk_isp # rk3399 isp1 clocks - items: - const: clk_isp - const: aclk_isp - const: hclk_isp - const: pclk_isp ? Thanks Helen >> +minItems: 3 >> items: >> - - const: clk_isp >> - - const: aclk_isp >> - - const: aclk_isp_wrap >> - - const: hclk_isp >> - - const: hclk_isp_wrap >> + - const: isp >> + - const: aclk >> + - const: hclk >> >>iommus: >> maxItems: 1 >> @@ -135,11 +135,9 @@ examples: >> reg = <0x0 0xff91 0x0 0x4000>; >> interrupts = ; >> clocks = <&cru SCLK_ISP0>, >> - <&cru ACLK_ISP0>, <&cru ACLK_ISP0_WRAPPER>, >> - <&cru HCLK_ISP0>, <&cru HCLK_ISP0_WRAPPER>; >> -clock-names = "clk_isp", >> - "aclk_isp", "aclk_isp_wrap", >> - "hclk_isp", "hclk_isp_wrap"; >> + <&cru ACLK_I
Re: [PATCH v4 5/9] media: staging: rkisp1: remove unecessary clocks
On Fri, Jul 17, 2020 at 12:14 PM Helen Koike wrote:
>
> Hi Rob,
>
> Thanks for your review.
>
> On 7/17/20 2:49 PM, Rob Herring wrote:
> > On Thu, Jul 2, 2020 at 1:13 PM Helen Koike
> > wrote:
> >>
> >> aclk_isp_wrap is a child of aclk_isp, and hclk_isp_wrap is a child of
> >> hclk_isp, thus we can remove parents from the list.
> >
> > But it looks like it is the wrap clocks you are removing.
>
> From this binding yes, but the idea is to add in the dt wherever clock
> responsible for the full ACLK path for instance.
> In the example below, clock aclk_isp is ACLK_ISP0_WRAPPER.
> Does this make sense?
Just perhaps clarify the renaming.
>
> >
> >>
> >> Also, for the isp0, we only need the ISP clock, ACLK and HCLK.
> >> In the future we'll need a pixel clock for RK3288 and RK3399, and a JPEG
> >> clock for RK3288.
> >>
> >> So with the goal to cleanup the dt-bindings and remove it from staging,
> >> simplify clock names to isp, aclk and hclk.
> >>
> >> For reference, this is the isp clock topology on RK3399:
> >>
> >> xin24m
> >> pll_npll
> >>npll
> >> clk_isp1
> >> clk_isp0
> >> pll_cpll
> >>cpll
> >> aclk_isp1
> >> aclk_isp1_noc
> >> hclk_isp1
> >> aclk_isp1_wrapper
> >> hclk_isp1_noc
> >> aclk_isp0
> >> hclk_isp1_wrapper
> >> aclk_isp0_wrapper
> >> aclk_isp0_noc
> >> hclk_isp0
> >> hclk_isp0_wrapper
> >> hclk_isp0_noc
> >> pclkin_isp1_wrapper
> >>
> >> Signed-off-by: Helen Koike
> >>
> >> ---
> >>
> >> Changes in V4:
> >> - update binding according to suggestion by Robin Murphy
> >> on https://patchwork.kernel.org/patch/11475007/
> >>
> >> Changes in V3:
> >> - this is a new patch in the series
> >> ---
> >> .../bindings/media/rockchip-isp1.yaml | 30 +--
> >> drivers/staging/media/rkisp1/rkisp1-dev.c | 8 ++---
> >> 2 files changed, 17 insertions(+), 21 deletions(-)
> >>
> >> diff --git
> >> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> >>
> >> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> >> index 4d111ef2e89c7..f10c53d008748 100644
> >> ---
> >> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> >> +++
> >> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> >> @@ -24,20 +24,20 @@ properties:
> >> maxItems: 1
> >>
> >>clocks:
> >> -items:
> >> - - description: ISP clock
> >> - - description: ISP AXI clock clock
> >> - - description: ISP AXI clock wrapper clock
> >> - - description: ISP AHB clock clock
> >> - - description: ISP AHB wrapper clock
> >
> > This is the correct way to describe multiple clocks.
>
> The idea was to prepare for rk3288 and rk3399 isp1, as suggested here
> https://patchwork.kernel.org/patch/11475007/#23462085
>
> Or should we do:
>
> clocks:
> oneOf:
> # rk3288 clocks
> - items:
> - description: ISP clock
> - description: ISP AXI clock
> - description: ISP AHB clock
> - description: ISP Pixel clock
> - description: ISP JPEG source clock
The main section should have this and 'minItems: 3'. IOW, it's a
superset of what's valid. Then you can restrict specific compatibles
further with an if/then schema. For rk3288, you need one with
'minItems: 5'.
> # rk3399 isp0 clocks
> - items:
> - description: ISP clock
> - description: ISP AXI clock
> - description: ISP AHB clock
And this would be an if/then schema based on the compatible string and
defining 'maxItems: 3'.
> # rk3399 isp1 clocks
> - items:
> - description: ISP clock
> - description: ISP AXI clock
> - description: ISP AHB clock
> - description: ISP Pixel clock
And an if/then with { minItems: 4, maxItems: 4 }. Or really since
these are just different instances, just combine them into 1
conditional allowing 3 or 4 clocks.
There are lots of examples to follow in the tree.
Rob
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Mail delivery failed: returning message to sender
This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: a...@afaq-uae.com: SMTP error from remote server for RCPT TO command, host: mail.afaq-uae.com (192.254.234.232) reason: 550 No Such User Here --- The header of the original message is following. --- Received: from infongp-us88.perfora.net ([74.208.59.50]) by mrelay.perfora.net (mreueus002 [172.19.143.3]) with ESMTPA (Nemesis) id 0LwJuC-1kuem42Huw-0180yy for ; Sat, 18 Jul 2020 03:26:18 +0200 Received: from 196.52.84.39 (IP may be forged by CGI script) by infongp-us88.perfora.net with HTTP id 0ETqMg-1kvTzL1PRN-017WEp; Fri, 17 Jul 2020 21:26:18 -0400 X-Sender-Info: <767207...@infongp-us88.perfora.net> Date: Fri, 17 Jul 2020 21:26:18 -0400 Message-Id: <0etqmg-1kvtzl1prn-017...@infongp-us88.perfora.net> Precedence: bulk To: a...@afaq-uae.com Subject: Message from a site visitor Wiе mаn 15469 EUR ein Мonat im pаssivеn Einкommen bildet: http://lvpa.laptop100.website/ba From: driverdev-devel@linuxdriverproject.org Reply-To: driverdev-devel@linuxdriverproject.org X-Provags-ID: V03:K1:lxkeILYLTWsx6DFCQWXADLtAJuTt2P4RW3gem0ZuA0wCuXUnLD1 siSY8Gwi57IwIQnICdmNZ6Nv2NJDXFrxoSmHech3TKfozNJ5x7ZT1szQN6fmnTHEZnN8clP 1OP4obMDL4iapzP01ewGmOPPG9h0h6pWxXI1cRQ+70i9W5D9Y6qXO0biI5yrXdYCXRQtHvr jIda8GbVgIaf4ZMhM0QfG7F5rMYsS4YlAOn7U9axyU= X-Spam-Flag: YES X-UI-Out-Filterresults: junk:10;V03:K0:dmWE92kUSdE=:MfvyJDxRuTYt+6LseB3JwmZq aB1JvNjua/Dyd+EWUyXQOkeciVfUTtZRQsUMRabY+47MvGvoBcZCmOgu9VuVTHeOi3q0ZNCJm jQ9oEtexp8rkdXvjLp22CipyoIqZcSLitEPObh2moVfqmT9PjZSZfsNcXApo2UW1kQttciPbq 8ezwqA+gloj+GBjRqjTyJ7hwmYd9Ild1UYxj60OBj1RWHuNG+LBjxo2bJLe737Hisw/w/dW99 QzR0u8DKT+PS8VPEbvh62pvDBRkYjyqyWAv2XfQpRBPaLQ5H9PKIEHaNnCu8k2mpvSf+Eb1T8 xtg8oQQT8PLHkKC9U5KAgmOyLdDVh6Jv52+1T1OsZG2ugREvemh6viUFUO3B0SoRly6XWiIsK u1TwBMH2AWb6S/+ca7GxMm3xAjijLjCmdqr+M/bx4uep0Fe97W8WP3m5Hmdr6L7C9zyYU499F QGe6f9imLNgjW8+onTR9hLoCF1ySlFsTBTm4WCR4OCmfsDy31snl5zr8hQftSYM7uHTQZPmp7 3a+0j+SnbbTlXQASkjK7+AzyeDFW4ihBXds8zgXaQ9+d+ysUxWDRuA1Xf1qK16jjvO+QslaSz wvpYT0+K9jfscSvS3trx//gvOpxheJRU6l8WPniYji6KruHn14JVvTpR6MGPSp8cD6JVu6NW+ 0GZSPO+TI3WOTSCIkuiZPJECqE6OAp575b+RKc+us3S5WFOH4R04y2Pnif9TNFkpoSDHncBZQ 86YuQJ8bADVS0pP/sg0BeI3E3fuGs2RGteh04Aaisxc4HUIL7Mqixq2ynykXQu97F8cuBE7bY YhdoBx3DX+HcoN/s2U7EaXsI2D9j2o24HYHkrM8WDwqUReduMcitFltj2Dy1fs+KACshkvmp8 3g7EYjLIJvgdMwjW9H7+Tz9fdKIr/JHI/zjPjMXS1nu4rBbDIOR+XdTTlZHDCPEYks2rzduuH KVCUW03MkTFmizACRCTeUu5+5Yw/gBCyrr1lUoWTWRQJd5p0+6DOHOK8CNcawzh8l4ucLws8N L9NaGFrLROlYAeM6qvp5qCFIEw7qHAEjhmRqFYwVQ9gjSDEj8u5T/k0D3na6YT5A== ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello 18/07/2020.
My name is Reem Hashimy, the Emirates Minister of State and Managing Director of the United Arab Emirates (Dubai) World Expo 2020 Committee which has been postponed to run from 1 October 2021 to 31 March 2022 because of the Covid-19 pandemic. I am writing to you to manage the funds I received as financial gratification from various foreign companies I assisted to receive a participation slot in the coming event. The amount is $44,762,906.00 United States dollars. I can not personally manage the fund in my country because of social restrictions on married Muslim women. For this reason, an agreement was reached with a consulting firm to keep the funds with a bank pending when I have a trusted partner to manage the fund. The details will be discussed on your indication of interest with capacity to manage the fund. My Regards, Reem Hashimy. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] media: atomisp: reorganize the code under gmin_subdev_add()
The gmin_subdev_add() currently doesn't use ACPI device
power management. In order to prepare for adding support
for it, let's shift some things, placing the PM-related
stuff at the end of the probing logic.
Let's also store the current gs on a temporary var, in
order to simplify the source code.
Signed-off-by: Mauro Carvalho Chehab
---
.../media/atomisp/pci/atomisp_gmin_platform.c | 119 +-
1 file changed, 60 insertions(+), 59 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index cb360b8399e5..81d89d8c549a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -447,6 +447,7 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
{
struct i2c_client *power = NULL, *client = v4l2_get_subdevdata(subdev);
struct acpi_device *adev;
+ struct gmin_subdev *gs;
acpi_handle handle;
struct device *dev;
int i, ret, clock_num;
@@ -457,16 +458,39 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
dev = &client->dev;
handle = ACPI_HANDLE(dev);
-
- // FIXME: may need to release resources allocated by
acpi_bus_get_device()
- if (!handle || acpi_bus_get_device(handle, &adev)) {
- dev_err(dev, "Error could not get ACPI device\n");
- return NULL;
- }
+ adev = ACPI_COMPANION(&client->dev);
dev_info(&client->dev, "%s: ACPI detected it on bus ID=%s, HID=%s\n",
__func__, acpi_device_bid(adev), acpi_device_hid(adev));
+ for (i = 0; i < MAX_SUBDEVS && gmin_subdevs[i].subdev; i++)
+ ;
+ if (i >= MAX_SUBDEVS)
+ return NULL;
+
+ gs = &gmin_subdevs[i];
+ gs->subdev = subdev;
+
+ /*WA:CHT requires XTAL clock as PLL is not stable.*/
+ gmin_subdevs[i].clock_src = gmin_get_var_int(dev, false, "ClkSrc",
+ VLV2_CLK_PLL_19P2MHZ);
+
+ gs->csi_port = gmin_get_var_int(dev, false, "CsiPort", 0);
+ gs->csi_lanes = gmin_get_var_int(dev, false, "CsiLanes", 1);
+
+ gs->gpio0 = gpiod_get_index(dev, NULL, 0, GPIOD_OUT_LOW);
+ if (IS_ERR(gs->gpio0))
+ gs->gpio0 = NULL;
+
+ gs->gpio1 = gpiod_get_index(dev, NULL, 1, GPIOD_OUT_LOW);
+ if (IS_ERR(gs->gpio1))
+ gs->gpio1 = NULL;
+
+ /*
+* FIXME: the code below doesn't rely on ACPI device_pm.c code to
+* set clocks and do power management.
+*/
+
if (!pmic_id) {
if (gmin_i2c_dev_exists(dev, PMIC_ACPI_TI, &power))
pmic_id = PMIC_TI;
@@ -478,13 +502,8 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
pmic_id = PMIC_REGULATOR;
}
- for (i = 0; i < MAX_SUBDEVS && gmin_subdevs[i].subdev; i++)
- ;
- if (i >= MAX_SUBDEVS)
- return NULL;
-
if (power) {
- gmin_subdevs[i].pwm_i2c_addr = power->addr;
+ gs->pwm_i2c_addr = power->addr;
dev_info(dev,
"gmin: power management provided via %s (i2c addr
0x%02x)\n",
pmic_name[pmic_id], power->addr);
@@ -493,17 +512,7 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
pmic_name[pmic_id]);
}
- gmin_subdevs[i].subdev = subdev;
-
- /*WA:CHT requires XTAL clock as PLL is not stable.*/
- gmin_subdevs[i].clock_src = gmin_get_var_int(dev, false, "ClkSrc",
- VLV2_CLK_PLL_19P2MHZ);
- gmin_subdevs[i].csi_port = gmin_get_var_int(dev, false, "CsiPort", 0);
- gmin_subdevs[i].csi_lanes = gmin_get_var_int(dev, false, "CsiLanes", 1);
-
/*
-* FIXME:
-*
* According with :
*
https://github.com/projectceladon/hardware-intel-kernelflinger/blob/master/doc/fastboot.md
*
@@ -526,9 +535,9 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
snprintf(gmin_pmc_clk_name, sizeof(gmin_pmc_clk_name),
"%s_%d", "pmc_plt_clk", clock_num);
- gmin_subdevs[i].pmc_clk = devm_clk_get(dev, gmin_pmc_clk_name);
- if (IS_ERR(gmin_subdevs[i].pmc_clk)) {
- ret = PTR_ERR(gmin_subdevs[i].pmc_clk);
+ gs->pmc_clk = devm_clk_get(dev, gmin_pmc_clk_name);
+ if (IS_ERR(gs->pmc_clk)) {
+ ret = PTR_ERR(gs->pmc_clk);
dev_err(dev,
"Failed to get clk from %s : %d\n",
@@ -549,25 +558,17 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
* to disable a clock that has not been enabled,
* we need to enable the clock first.
*/
- ret = clk_prepare_enable(gm
[PATCH 1/3] media: rkvdec: Fix H264 scaling list order
From: Jonas Karlman
The Rockchip Video Decoder driver is expecting that the values in a
scaling list are in zig-zag order and applies the inverse scanning process
to get the values in matrix order.
Commit 0b0393d59eb4 ("media: uapi: h264: clarify expected
scaling_list_4x4/8x8 order") clarified that the values in the scaling list
should already be in matrix order.
Fix this by removing the reordering and change to use two memcpy.
Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Jonas Karlman
Tested-by: Nicolas Dufresne
Reviewed-by: Ezequiel Garcia
[hverkuil-ci...@xs4all.nl: rkvdec_scaling_matrix -> rkvdec_h264_scaling_list]
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/rkvdec/rkvdec-h264.c | 66 +++---
1 file changed, 20 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c
b/drivers/staging/media/rkvdec/rkvdec-h264.c
index cd4980d06be7..7b66e2743a4f 100644
--- a/drivers/staging/media/rkvdec/rkvdec-h264.c
+++ b/drivers/staging/media/rkvdec/rkvdec-h264.c
@@ -18,11 +18,16 @@
/* Size with u32 units. */
#define RKV_CABAC_INIT_BUFFER_SIZE (3680 + 128)
#define RKV_RPS_SIZE ((128 + 128) / 4)
-#define RKV_SCALING_LIST_SIZE (6 * 16 + 6 * 64 + 128)
#define RKV_ERROR_INFO_SIZE(256 * 144 * 4)
#define RKVDEC_NUM_REFLIST 3
+struct rkvdec_h264_scaling_list {
+ u8 scaling_list_4x4[6][16];
+ u8 scaling_list_8x8[6][64];
+ u8 padding[128];
+};
+
struct rkvdec_sps_pps_packet {
u32 info[8];
};
@@ -86,7 +91,7 @@ struct rkvdec_ps_field {
/* Data structure describing auxiliary buffer format. */
struct rkvdec_h264_priv_tbl {
s8 cabac_table[4][464][2];
- u8 scaling_list[RKV_SCALING_LIST_SIZE];
+ struct rkvdec_h264_scaling_list scaling_list;
u32 rps[RKV_RPS_SIZE];
struct rkvdec_sps_pps_packet param_set[256];
u8 err_info[RKV_ERROR_INFO_SIZE];
@@ -785,56 +790,25 @@ static void assemble_hw_rps(struct rkvdec_ctx *ctx,
}
}
-/*
- * NOTE: The values in a scaling list are in zig-zag order, apply inverse
- * scanning process to get the values in matrix order.
- */
-static const u32 zig_zag_4x4[16] = {
- 0, 1, 4, 8, 5, 2, 3, 6, 9, 12, 13, 10, 7, 11, 14, 15
-};
-
-static const u32 zig_zag_8x8[64] = {
- 0, 1, 8, 16, 9, 2, 3, 10, 17, 24, 32, 25, 18, 11, 4, 5,
- 12, 19, 26, 33, 40, 48, 41, 34, 27, 20, 13, 6, 7, 14, 21, 28,
- 35, 42, 49, 56, 57, 50, 43, 36, 29, 22, 15, 23, 30, 37, 44, 51,
- 58, 59, 52, 45, 38, 31, 39, 46, 53, 60, 61, 54, 47, 55, 62, 63
-};
-
-static void reorder_scaling_list(struct rkvdec_ctx *ctx,
-struct rkvdec_h264_run *run)
+static void assemble_hw_scaling_list(struct rkvdec_ctx *ctx,
+struct rkvdec_h264_run *run)
{
const struct v4l2_ctrl_h264_scaling_matrix *scaling =
run->scaling_matrix;
- const size_t num_list_4x4 = ARRAY_SIZE(scaling->scaling_list_4x4);
- const size_t list_len_4x4 = ARRAY_SIZE(scaling->scaling_list_4x4[0]);
- const size_t num_list_8x8 = ARRAY_SIZE(scaling->scaling_list_8x8);
- const size_t list_len_8x8 = ARRAY_SIZE(scaling->scaling_list_8x8[0]);
struct rkvdec_h264_ctx *h264_ctx = ctx->priv;
struct rkvdec_h264_priv_tbl *tbl = h264_ctx->priv_tbl.cpu;
- u8 *dst = tbl->scaling_list;
- const u8 *src;
- int i, j;
- BUILD_BUG_ON(ARRAY_SIZE(zig_zag_4x4) != list_len_4x4);
- BUILD_BUG_ON(ARRAY_SIZE(zig_zag_8x8) != list_len_8x8);
- BUILD_BUG_ON(ARRAY_SIZE(tbl->scaling_list) <
-num_list_4x4 * list_len_4x4 +
-num_list_8x8 * list_len_8x8);
+ BUILD_BUG_ON(sizeof(tbl->scaling_list.scaling_list_4x4) !=
+sizeof(scaling->scaling_list_4x4));
+ BUILD_BUG_ON(sizeof(tbl->scaling_list.scaling_list_8x8) !=
+sizeof(scaling->scaling_list_8x8));
- src = &scaling->scaling_list_4x4[0][0];
- for (i = 0; i < num_list_4x4; ++i) {
- for (j = 0; j < list_len_4x4; ++j)
- dst[zig_zag_4x4[j]] = src[j];
- src += list_len_4x4;
- dst += list_len_4x4;
- }
+ memcpy(tbl->scaling_list.scaling_list_4x4,
+ scaling->scaling_list_4x4,
+ sizeof(scaling->scaling_list_4x4));
- src = &scaling->scaling_list_8x8[0][0];
- for (i = 0; i < num_list_8x8; ++i) {
- for (j = 0; j < list_len_8x8; ++j)
- dst[zig_zag_8x8[j]] = src[j];
- src += list_len_8x8;
- dst += list_len_8x8;
- }
+ memcpy(tbl->scaling_list.scaling_list_8x8,
+ scaling->scaling_list_8x8,
+ sizeof(scaling->scaling_list_8x8));
}
/*
@@ -1126,7 +1100,7 @@ static int rkvdec_h264_run(struct rkvdec_ctx *ctx)
v4l
[PATCH 2/3] media: atomisp: fix the handling of clock number
Right now, the driver is not doing the right thing to detect
the clock like used by the sensor, at least on devices
without the gmin's EFI vars.
Add some notes at the code to explain why and skip the wrong
value provided by the _DSM table.
Signed-off-by: Mauro Carvalho Chehab
---
.../media/atomisp/pci/atomisp_gmin_platform.c | 49 ---
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 1af9da8acf4c..cb360b8399e5 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -26,6 +26,9 @@ enum clock_rate {
#define CLK_RATE_19_2MHZ 1920
#define CLK_RATE_25_0MHZ 2500
+/* Valid clock number range from 0 to 5 */
+#define MAX_CLK_COUNT 5
+
/* X-Powers AXP288 register set */
#define ALDO1_SEL_REG 0x28
#define ALDO1_CTRL3_REG0x13
@@ -61,7 +64,6 @@ enum clock_rate {
struct gmin_subdev {
struct v4l2_subdev *subdev;
- int clock_num;
enum clock_rate clock_src;
bool clock_on;
struct clk *pmc_clk;
@@ -447,7 +449,7 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
struct acpi_device *adev;
acpi_handle handle;
struct device *dev;
- int i, ret;
+ int i, ret, clock_num;
if (!client)
return NULL;
@@ -492,17 +494,37 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
}
gmin_subdevs[i].subdev = subdev;
- gmin_subdevs[i].clock_num = gmin_get_var_int(dev, false, "CamClk", 0);
+
/*WA:CHT requires XTAL clock as PLL is not stable.*/
gmin_subdevs[i].clock_src = gmin_get_var_int(dev, false, "ClkSrc",
VLV2_CLK_PLL_19P2MHZ);
gmin_subdevs[i].csi_port = gmin_get_var_int(dev, false, "CsiPort", 0);
gmin_subdevs[i].csi_lanes = gmin_get_var_int(dev, false, "CsiLanes", 1);
- /* get PMC clock with clock framework */
- snprintf(gmin_pmc_clk_name,
-sizeof(gmin_pmc_clk_name),
-"%s_%d", "pmc_plt_clk", gmin_subdevs[i].clock_num);
+ /*
+* FIXME:
+*
+* According with :
+*
https://github.com/projectceladon/hardware-intel-kernelflinger/blob/master/doc/fastboot.md
+*
+* The "CamClk" EFI var is set via fastboot on some Android devices,
+* and seems to contain the number of the clock used to feed the
+* sensor.
+*
+* On systems with a proper ACPI table, this is given via the _PR0
+* power resource table. The logic below should first check if there
+* is a power resource already, falling back to the EFI vars detection
+* otherwise.
+*/
+ clock_num = gmin_get_var_int(dev, false, "CamClk", -1);
+
+ if (clock_num < 0 || clock_num > MAX_CLK_COUNT) {
+ dev_err(dev, "Invalid clock number\n");
+ return NULL;
+ }
+
+ snprintf(gmin_pmc_clk_name, sizeof(gmin_pmc_clk_name),
+"%s_%d", "pmc_plt_clk", clock_num);
gmin_subdevs[i].pmc_clk = devm_clk_get(dev, gmin_pmc_clk_name);
if (IS_ERR(gmin_subdevs[i].pmc_clk)) {
@@ -515,6 +537,7 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
return NULL;
}
+ dev_info(dev, "Will use CLK%d (%s)\n", clock_num, gmin_pmc_clk_name);
/*
* The firmware might enable the clock at
@@ -957,6 +980,18 @@ static int gmin_get_config_dsm_var(struct device *dev,
union acpi_object *obj, *cur = NULL;
int i;
+ /*
+* The data reported by "CamClk" seems to be either 0 or 1 at the
+* _DSM table.
+*
+* At the ACPI tables we looked so far, this is not related to the
+* actual clock source for the sensor, which is given by the
+* _PR0 ACPI table. So, ignore it, as otherwise this will be
+* set to a wrong value.
+*/
+ if (!strcmp(var, "CamClk"))
+ return -EINVAL;
+
obj = acpi_evaluate_dsm(handle, &atomisp_dsm_guid, 0, 0, NULL);
if (!obj) {
dev_info_once(dev, "Didn't find ACPI _DSM table.\n");
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] media: rkvdec: Fix H264 scaling list order
Em Sat, 18 Jul 2020 07:05:54 +0200
Mauro Carvalho Chehab escreveu:
> From: Jonas Karlman
>
> The Rockchip Video Decoder driver is expecting that the values in a
> scaling list are in zig-zag order and applies the inverse scanning process
> to get the values in matrix order.
>
> Commit 0b0393d59eb4 ("media: uapi: h264: clarify expected
> scaling_list_4x4/8x8 order") clarified that the values in the scaling list
> should already be in matrix order.
>
> Fix this by removing the reordering and change to use two memcpy.
Please ignore this one. This patch is already merged, and it is
not related to the 2 atomisp patches on this short series.
Thanks,
Mauro
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: clear tabstop style issues
Clear tabstop style issues reported by checkpatch.
WARNING: Statements should start on a tabstop
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_ioctl_set.c| 2 +-
drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c | 2 +-
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
index fa88e8b2852d..26e5193cfd6c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
@@ -343,7 +343,7 @@ u8 rtw_set_802_11_infrastructure_mode(struct adapter
*padapter,
*pold_state == Ndis802_11IBSS) {
if (check_fwstate(pmlmepriv, _FW_LINKED))
rtw_indicate_disconnect(padapter); /* will clr
Linked_state; before this function, we must have checked whether issue
dis-assoc_cmd or not */
- }
+ }
*pold_state = networktype;
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
index 740004d71a15..2baef9a285c0 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
@@ -145,7 +145,7 @@ void rtw_hal_set_odm_var(struct adapter *Adapter, enum
hal_odm_variable eVariabl
} else {
DBG_88E("### Clean STA_(%d) info\n",
psta->mac_id);
ODM_CmnInfoPtrArrayHook(podmpriv,
ODM_CMNINFO_STA_STATUS, psta->mac_id, NULL);
- }
+ }
}
break;
case HAL_ODM_P2P_STATE:
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index 5e6f7f0ed009..2e83d24fcb09 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -811,7 +811,7 @@ static int rtw_wx_set_pmkid(struct net_device *dev,
psecuritypriv->PMKIDList[j].bUsed = false;
break;
}
- }
+ }
} else if (pPMK->cmd == IW_PMKSA_FLUSH) {
DBG_88E("[rtw_wx_set_pmkid] IW_PMKSA_FLUSH!\n");
memset(&psecuritypriv->PMKIDList[0], 0x00, sizeof(struct
rt_pmkid_list) * NUM_PMKID_CACHE);
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
