[PATCH] net: tipc: prevent possible null deref of link

[Cengiz Can]

`tipc_node_apply_property` does a null check on a `tipc_link_entry`
pointer but also accesses the same pointer out of the null check block.

This triggers a warning on Coverity Static Analyzer because we're
implying that `e->link` can BE null.

Move "Update MTU for node link entry" line into if block to make sure
that we're not in a state that `e->link` is null.

Signed-off-by: Cengiz Can 
---
 net/tipc/node.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/tipc/node.c b/net/tipc/node.c
index c95d037fde51..83978d5dae59 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -2181,9 +2181,11 @@ void tipc_node_apply_property(struct net *net, struct 
tipc_bearer *b,
);
else if (prop == TIPC_NLA_PROP_MTU)
tipc_link_set_mtu(e->link, b->mtu);
+
+   /* Update MTU for node link entry */
+   e->mtu = tipc_link_mss(e->link);
}
-   /* Update MTU for node link entry */
-   e->mtu = tipc_link_mss(e->link);
+
tipc_node_write_unlock(n);
tipc_bearer_xmit(net, bearer_id, , >maddr, NULL);
}
-- 
2.29.2

[PATCH] media: vidtv: fix read after free

[Cengiz Can]

`vidtv_channel_si_destroy` function has a call to
`vidtv_psi_pat_table_destroy` that frees Program Association Table.

However it is followed by a loop that iterates over the count of Program
Map Tables. This obviously accesses an invalid memory.

Eliminate this by making a copy of num_pmt before free'ing Program
Association Table and loop on it instead.

Signed-off-by: Cengiz Can 
---
 drivers/media/test-drivers/vidtv/vidtv_channel.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/test-drivers/vidtv/vidtv_channel.c 
b/drivers/media/test-drivers/vidtv/vidtv_channel.c
index 8ad6c0744d36..4af39a8786a7 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_channel.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_channel.c
@@ -503,10 +503,13 @@ int vidtv_channel_si_init(struct vidtv_mux *m)
 void vidtv_channel_si_destroy(struct vidtv_mux *m)
 {
u32 i;
+   u16 num_pmt;
+
+   num_pmt = m->si.pat->num_pmt;
 
vidtv_psi_pat_table_destroy(m->si.pat);
 
-   for (i = 0; i < m->si.pat->num_pmt; ++i)
+   for (i = 0; i < num_pmt; ++i)
vidtv_psi_pmt_table_destroy(m->si.pmt_secs[i]);
 
kfree(m->si.pmt_secs);
-- 
2.29.2

[PATCH] dt-bindings: fsl-imx-drm: fix example compatible string

[Cengiz Can]

Example `display-subsystem` has an incorrect compatible string.

Required properties section tells that developers should use
"fsl,imx-display-subsystem" as "compatible" string but the example
misses 'imx-' prefix.

Change example to have correct "compatible" string.

Signed-off-by: Cengiz Can 
---
 Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
index 5a99490c17b9..3c35338a2867 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
@@ -12,7 +12,7 @@ Required properties:
 example:
 
 display-subsystem {
-   compatible = "fsl,display-subsystem";
+   compatible = "fsl,imx-display-subsystem";
ports = <_di0>;
 };
 
-- 
2.29.2

Re: [PATCH] infiniband: remove unnecessary fallthrough usage

[Cengiz Can]

On 2020-08-31 18:34, Jason Gunthorpe wrote:

On Mon, Aug 31, 2020 at 06:30:34PM +0300, Cengiz Can wrote:
Since /* fallthrough */ comments are deprecated[1], they are being 
replaced

by new 'fallthrough' pseudo-keyword.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?\
highlight=fallthrough#implicit-switch-case-fall-through

This sometimes leads to unreachable code warnings by static analyzers,
particularly in this case, Coverity Scanner. (CID 1466512)

Remove unnecessary 'fallthrough' keywords to prevent dead code
warnings.

Signed-off-by: Cengiz Can 
---
 drivers/infiniband/hw/qib/qib_mad.c | 2 --
 1 file changed, 2 deletions(-)


Alex beat you to it:

https://patchwork.kernel.org/patch/11736039/


Well, I'm glad it's fixed :)

Thanks for sharing



Thanks,
Jason


--
Cengiz Can
@cengiz_io

[PATCH] infiniband: remove unnecessary fallthrough usage

[Cengiz Can]

Since /* fallthrough */ comments are deprecated[1], they are being replaced
by new 'fallthrough' pseudo-keyword.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?\
highlight=fallthrough#implicit-switch-case-fall-through

This sometimes leads to unreachable code warnings by static analyzers,
particularly in this case, Coverity Scanner. (CID 1466512)

Remove unnecessary 'fallthrough' keywords to prevent dead code
warnings.

Signed-off-by: Cengiz Can 
---
 drivers/infiniband/hw/qib/qib_mad.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/infiniband/hw/qib/qib_mad.c 
b/drivers/infiniband/hw/qib/qib_mad.c
index e7789e724f56..f972e559a8a7 100644
--- a/drivers/infiniband/hw/qib/qib_mad.c
+++ b/drivers/infiniband/hw/qib/qib_mad.c
@@ -2322,7 +2322,6 @@ static int process_cc(struct ib_device *ibdev, int 
mad_flags,
ret = cc_get_congestion_control_table(ccp, ibdev, port);
goto bail;
 
-   fallthrough;
default:
ccp->status |= IB_SMP_UNSUP_METH_ATTR;
ret = reply((struct ib_smp *) ccp);
@@ -2339,7 +2338,6 @@ static int process_cc(struct ib_device *ibdev, int 
mad_flags,
ret = cc_set_congestion_control_table(ccp, ibdev, port);
goto bail;
 
-   fallthrough;
default:
ccp->status |= IB_SMP_UNSUP_METH_ATTR;
ret = reply((struct ib_smp *) ccp);
-- 
2.28.0

[PATCH v2] staging: atomisp: Remove unnecessary 'fallthrough'

[Cengiz Can]

commit df561f6688fe ("treewide: Use fallthrough pseudo-keyword") from
Gustavo A. R. Silva replaced and standardized /* fallthrough */ comments
with 'fallthrough' pseudo-keyword.

However, in one of the switch-case statements, Coverity Static Analyzer
throws a warning that 'fallthrough' is unreachable due to the adjacent
'return false' statement. (Coverity ID CID 1466511)

In order to fix the unreachable code warning, remove unnecessary
fallthrough keyword.

Signed-off-by: Cengiz Can 
---
 drivers/staging/media/atomisp/pci/atomisp_compat_css20.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c 
b/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c
index 1b2b2c68025b..feb26c221e96 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c
@@ -711,7 +711,6 @@ static bool is_pipe_valid_to_current_run_mode(struct 
atomisp_sub_device *asd,
return true;
 
return false;
-   fallthrough;
case ATOMISP_RUN_MODE_VIDEO:
if (!asd->continuous_mode->val) {
if (pipe_id == IA_CSS_PIPE_ID_VIDEO ||
-- 
2.28.0

[PATCH] staging: atomisp: Fix fallthrough keyword warning

[Cengiz Can]

commit df561f6688fe ("treewide: Use fallthrough pseudo-keyword") from
Gustavo A. R. Silva replaced and standardized /* fallthrough */ comments
with 'fallthrough' pseudo-keyword.

However, in one of the switch-case statements, Coverity Static Analyzer
throws a warning that 'fallthrough' is unreachable due to the adjacent
'return false' statement.

Since 'fallthrough' is actually an empty "do {} while(0)" this might be
due to compiler optimizations. But that needs further investigation.

In order to fix the unreachable code warning, make adjacent 'return
false' a part of the previous if statement's else clause.

Reported-by: Coverity Static Analyzer CID 1466511
Signed-off-by: Cengiz Can 
---
 drivers/staging/media/atomisp/pci/atomisp_compat_css20.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c 
b/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c
index 1b2b2c68025b..aaa2d0e0851b 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_compat_css20.c
@@ -709,8 +709,8 @@ static bool is_pipe_valid_to_current_run_mode(struct 
atomisp_sub_device *asd,
if (pipe_id == IA_CSS_PIPE_ID_CAPTURE ||
pipe_id == IA_CSS_PIPE_ID_PREVIEW)
return true;
-
-   return false;
+   else
+   return false;
fallthrough;
case ATOMISP_RUN_MODE_VIDEO:
if (!asd->continuous_mode->val) {
-- 
2.28.0

Re: [PATCH v6] staging: atomisp: move null check to earlier point

[Cengiz Can]

On August 6, 2020 21:39:21 Greg KH  wrote:


On Thu, Aug 06, 2020 at 09:34:22PM +0300, Cengiz Can wrote:

Hello Andy,

Can I get some feedback on v6 please?



It's been 4 days, in the middle of a merge window, please give people a
chance to catch up on other things...


I wasn't aware of that we're currently in a merge window. Sorry for my 
impatience.




and do not top post please.


Sorry. I was tricked by my mobile email client.



thanks,

greg k-h


Thanks again and I wish a smooth merge window to all maintainers.

Cengiz Can

Re: [PATCH v6] staging: atomisp: move null check to earlier point

[Cengiz Can]

Hello Andy,

Can I get some feedback on v6 please?

I hope it suits your standards this time.

Thank you

On August 2, 2020 01:02:22 Cengiz Can  wrote:


`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.

In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:

 /* Acquired here v */
 struct gmin_subdev *gs = find_gmin_subdev(subdev);

 /*  v--Dereferenced here */
 if (gs->v2p8_gpio >= 0) {
 ...
 }

With this change we're null checking `find_gmin_subdev()` result
and we return an error if that's the case. We also WARN()
for the sake of debugging.

Signed-off-by: Cengiz Can 
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab 
---

Please do note that this change introduces a new return value to
`gmin_v2p8_ctrl()`.

[NEW] - raise a WARN and return -ENODEV if there are no subdevices.
  - return result of `gpio_request` or `gpio_direction_output`.
  - return 0 if GPIO is ON.
  - return results of `regulator_enable` or `regulator_disable`.
  - according to PMIC type, return result of `axp_regulator_set`
or `gmin_i2c_write`.
  - return -EINVAL if unknown PMIC type.

Patch Changelog:
  v4: Fix minor typo in commit message
  v5: Remove typo from email subject
  v6: Remove duplicate Signed-off-by tag

drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c

index 0df46a1af5f0..1ad0246764a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,9 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, 
int on)

int ret;
int value;

+   if (WARN_ON(!gs))
+   return -ENODEV;
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +884,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, 
int on)

pr_err("V2P8 GPIO initialization failed\n");
}

-   if (!gs || gs->v2p8_on == on)
+   if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;

--
2.27.0

[PATCH v6] staging: atomisp: move null check to earlier point

[Cengiz Can]

`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.

In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:

  /* Acquired here v */
  struct gmin_subdev *gs = find_gmin_subdev(subdev);

  /*  v--Dereferenced here */
  if (gs->v2p8_gpio >= 0) {
  ...
  }

With this change we're null checking `find_gmin_subdev()` result
and we return an error if that's the case. We also WARN()
for the sake of debugging.

Signed-off-by: Cengiz Can 
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab 
---

 Please do note that this change introduces a new return value to
 `gmin_v2p8_ctrl()`.

 [NEW] - raise a WARN and return -ENODEV if there are no subdevices.
   - return result of `gpio_request` or `gpio_direction_output`.
   - return 0 if GPIO is ON.
   - return results of `regulator_enable` or `regulator_disable`.
   - according to PMIC type, return result of `axp_regulator_set`
 or `gmin_i2c_write`.
   - return -EINVAL if unknown PMIC type.

 Patch Changelog:
   v4: Fix minor typo in commit message
   v5: Remove typo from email subject
   v6: Remove duplicate Signed-off-by tag

 drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..1ad0246764a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,9 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
int ret;
int value;
 
+   if (WARN_ON(!gs))
+   return -ENODEV;
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +884,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
pr_err("V2P8 GPIO initialization failed\n");
}
 
-   if (!gs || gs->v2p8_on == on)
+   if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
 
-- 
2.27.0

[PATCH v5] staging: atomisp: move null check to earlier point

[Cengiz Can]

`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.

In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:

  /* Acquired here v */
  struct gmin_subdev *gs = find_gmin_subdev(subdev);

  /*  v--Dereferenced here */
  if (gs->v2p8_gpio >= 0) {
  ...
  }

With this change we're null checking `find_gmin_subdev()` result
and we return an error if that's the case. We also WARN()
for the sake of debugging.

Signed-off-by: Cengiz Can 
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab 
Signed-off-by: Cengiz Can 
---

 Please do note that this change introduces a new return value to
 `gmin_v2p8_ctrl()`.

 [NEW] - raise a WARN and return -ENODEV if there are no subdevices.
   - return result of `gpio_request` or `gpio_direction_output`.
   - return 0 if GPIO is ON.
   - return results of `regulator_enable` or `regulator_disable`.
   - according to PMIC type, return result of `axp_regulator_set`
 or `gmin_i2c_write`.
   - return -EINVAL if unknown PMIC type.
 
 Patch Changelog:
   v4: Fix minor typo in commit message
   v5: Remove typo from email subject

 drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..1ad0246764a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,9 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
int ret;
int value;
 
+   if (WARN_ON(!gs))
+   return -ENODEV;
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +884,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
pr_err("V2P8 GPIO initialization failed\n");
}
 
-   if (!gs || gs->v2p8_on == on)
+   if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
 
-- 
2.27.0

[PATCHi v4] staging: atomisp: move null check to earlier point

[Cengiz Can]

`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.

In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:

  /* Acquired here v */
  struct gmin_subdev *gs = find_gmin_subdev(subdev);

  /*  v--Dereferenced here */
  if (gs->v2p8_gpio >= 0) {
  ...
  }

With this change we're null checking `find_gmin_subdev()` result
and we return an error if that's the case. We also WARN()
for the sake of debugging.

Signed-off-by: Cengiz Can 
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab 
Signed-off-by: Cengiz Can 
---

 Please do note that this change introduces a new return value to
 `gmin_v2p8_ctrl`.

 [NEW] - raise a WARN and return -ENODEV if there are no subdevices.
   - return result of `gpio_request` or `gpio_direction_output`.
   - return 0 if GPIO is ON.
   - return results of `regulator_enable` or `regulator_disable`.
   - according to PMIC type, return result of `axp_regulator_set`
 or `gmin_i2c_write`.
   - return -EINVAL if unknown PMIC type.
 
 Patch Changelog:
   v4: Fix minor typo in commit message

 drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..1ad0246764a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,9 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
int ret;
int value;
 
+   if (WARN_ON(!gs))
+   return -ENODEV;
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +884,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
pr_err("V2P8 GPIO initialization failed\n");
}
 
-   if (!gs || gs->v2p8_on == on)
+   if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
 
-- 
2.27.0

[PATCH v3] staging: atomisp: move null check to earlier point

[Cengiz Can]

`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.

In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:

  /* Acquired here v */
  struct gmin_subdev *gs = find_gmin_subdev(subdev);

  /*  v--Dereferenced here */
  if (gs->v2p8_gpio >= 0) {
  ...
  }

With this change we're null checking `find_gmin_subdev()` result
and return we return an error if that's the case. We also WARN()
for the sake of debugging.

Signed-off-by: Cengiz Can 
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab 
---

Please do note that this change introduces a new return value to
 `gmin_v2p8_ctrl`.
 
 [NEW] - raise a WARN and return -ENODEV if there are no subdevices.
   - return result of `gpio_request` or `gpio_direction_output`.
   - return 0 if GPIO is ON.
   - return results of `regulator_enable` or `regulator_disable`.
   - according to PMIC type, return result of `axp_regulator_set`
 or `gmin_i2c_write`.
   - return -EINVAL if unknown PMIC type.

 drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..1ad0246764a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,9 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
int ret;
int value;
 
+   if (WARN_ON(!gs))
+   return -ENODEV;
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +884,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
pr_err("V2P8 GPIO initialization failed\n");
}
 
-   if (!gs || gs->v2p8_on == on)
+   if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
 
-- 
2.27.0

[PATCH v2] staging: atomisp: move null check to earlier point

[Cengiz Can]

`find_gmin_subdev` function that returns a pointer to `struct
gmin_subdev` can return NULL.

In `gmin_v2p8_ctrl` there's a call to this function but the possibility
of a NULL was not checked before its being dereferenced. ie:

```
/* Acquired here v */
struct gmin_subdev *gs = find_gmin_subdev(subdev);

/*  v--Dereferenced here */
if (gs->v2p8_gpio >= 0) {
...
}
```

To avoid the issue, null check has been moved to an earlier point
and return semantics has been changed to reflect this exception.

Please do note that this change introduces a new return value to
`gmin_v2p8_ctrl`.

[NEW] - raise a WARN and return -ENODEV if there are no subdevices.
  - return result of `gpio_request` or `gpio_direction_output`.
  - return 0 if GPIO is ON.
  - return results of `regulator_enable` or `regulator_disable`.
  - according to PMIC type, return result of `axp_regulator_set`
or `gmin_i2c_write`.
  - return -EINVAL if unknown PMIC type.

Caught-by: Coverity Static Analyzer CID 1465536
Signed-off-by: Cengiz Can 
---
 drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..1ad0246764a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,9 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
int ret;
int value;
 
+   if (WARN_ON(!gs))
+   return -ENODEV;
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +884,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
pr_err("V2P8 GPIO initialization failed\n");
}
 
-   if (!gs || gs->v2p8_on == on)
+   if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
 
-- 
2.27.0

Re: [PATCH] staging: atomisp: move null check to earlier point

[Cengiz Can]

On July 30, 2020 11:48:06 Dan Carpenter  wrote:


On Wed, Jul 29, 2020 at 06:13:44PM +0300, Andy Shevchenko wrote:

On Wed, Jul 29, 2020 at 5:00 PM Cengiz Can  wrote:


`find_gmin_subdev` function that returns a pointer to `struct
gmin_subdev` can return NULL.

In `gmin_v2p8_ctrl` there's a call to this function but the possibility
of a NULL was not checked before its being dereferenced. ie:

```
/* Acquired here v */
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
int value;

/*  v--Dereferenced here */
if (gs->v2p8_gpio >= 0) {
 pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
 gs->v2p8_gpio);
 ret = gpio_request(gs->v2p8_gpio, "camera_v2p8");
 if (!ret)
 ret = gpio_direction_output(gs->v2p8_gpio, 0);
 if (ret)
 pr_err("V2P8 GPIO initialization failed\n");
}
```

I have moved the NULL check before deref point.


"Move the NULL check..."
See Submitting Patches documentation how to avoid "This patch", "I", "we", etc.


Noted. Sorry. I'm not a native English speaker.





I always feel like this is a pointless requirement.  We're turning into
bureaucracts.



diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c

index 0df46a1af5f0..8e9c5016f299 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,11 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, 
int on)

 int ret;
 int value;

+   if (!gs) {
+   pr_err("Unable to find gmin subdevice\n");



+   return -EINVAL;


And here is a change of semantics...


Yeah.  The change of semantics should be documented in the commit
message, but it's actually correct.  I discussed this with Mauro earlier
but my bug reporting script didn't CC a mailing list and I didn't
catch it.  Mauro suggested:

   53  > Yet, it could make sense to have something like:
   54  >
   55  >   if (WARN_ON(!gs))
   56  >   return -ENODEV;
   57  >
   58  > at the beginning of the functions that call find_gmin_subdev().


I will be updating v2 according to this.



regards,
dan carpenter

[PATCH] staging: atomisp: move null check to earlier point

[Cengiz Can]

`find_gmin_subdev` function that returns a pointer to `struct
gmin_subdev` can return NULL.

In `gmin_v2p8_ctrl` there's a call to this function but the possibility
of a NULL was not checked before its being dereferenced. ie:

```
/* Acquired here v */
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
int value;

/*  v--Dereferenced here */
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
ret = gpio_request(gs->v2p8_gpio, "camera_v2p8");
if (!ret)
ret = gpio_direction_output(gs->v2p8_gpio, 0);
if (ret)
pr_err("V2P8 GPIO initialization failed\n");
}
```

I have moved the NULL check before deref point.

Caught-by: Coverity Static Analyzer CID 1465536
Signed-off-by: Cengiz Can 
---
 drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..8e9c5016f299 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,11 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
int ret;
int value;
 
+   if (!gs) {
+   pr_err("Unable to find gmin subdevice\n");
+   return -EINVAL;
+   }
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +886,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int 
on)
pr_err("V2P8 GPIO initialization failed\n");
}
 
-   if (!gs || gs->v2p8_on == on)
+   if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
 
-- 
2.27.0

Re: BUG: unable to handle kernel NULL pointer dereference in do_syscall_32_irqs_on

[Cengiz Can]

: f7f83569 R15: c900017b7500
>  is_kernel include/linux/kallsyms.h:44 [inline]
>  is_ksym_addr include/linux/kallsyms.h:50 [inline]
>  kallsyms_lookup+0xc3/0x2e0 kernel/kallsyms.c:290
>  __sprint_symbol+0x9c/0x1c0 kernel/kallsyms.c:363
>  symbol_string+0x14c/0x370 lib/vsprintf.c:969
>  pointer+0x185/0x970 lib/vsprintf.c:2226
>  vsnprintf+0x5b2/0x14f0 lib/vsprintf.c:2624
>  vscnprintf+0x29/0x80 lib/vsprintf.c:2723
>  vprintk_store+0x44/0x4a0 kernel/printk/printk.c:1942
>  vprintk_emit+0x139/0x770 kernel/printk/printk.c:2003
>  vprintk_func+0x8f/0x1a6 kernel/printk/printk_safe.c:393
>  printk+0xba/0xed kernel/printk/printk.c:2070
>  show_ip+0x22/0x30 arch/x86/kernel/dumpstack.c:124
>  show_iret_regs+0x10/0x32 arch/x86/kernel/dumpstack.c:131
>  __show_regs+0x18/0x50 arch/x86/kernel/process_64.c:72
>  show_trace_log_lvl+0x255/0x2b4 arch/x86/kernel/dumpstack.c:274
>  show_regs arch/x86/kernel/dumpstack.c:447 [inline]
>  __die_body arch/x86/kernel/dumpstack.c:393 [inline]
>  __die+0x51/0x90 arch/x86/kernel/dumpstack.c:407
>  no_context+0x56b/0x9f0 arch/x86/mm/fault.c:695
>  __bad_area_nosemaphore+0xa9/0x480 arch/x86/mm/fault.c:789
>  do_user_addr_fault+0x8ce/0xd00 arch/x86/mm/fault.c:1258
> Lost 45 message(s)!
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches

There's no C reproducer for this syzkaller report but I'm trying to
reproduce it, in order to understand and possibly fix it if it's legit.

Wanted to notify if anyone is already working on it or has an idea.

Thank you

Cengiz Can

Re: WARNING in __kernel_read

[Cengiz Can]

Hello,

I'm trying to help clean up syzkaller submissions and this caught my
attention and I wanted to get your advice.

With commit: 6209dd9132e8ea5545cffc84483841e88ea8cc5b `kernel_read` was
modified to use `__kernel_read` by Christoph Hellwig.

One of the syzkaller tests executes following system calls:

open("./file0", O_WRONLY|O_CREAT|O_EXCL|O_DIRECT|0x4, 000) = 5
open("/dev/char/4:1", O_RDWR)   = 6
mount(NULL, "./file0", "9p", 0,
"trans=fd,rfdno=0x0005,wfdno=0x0006,"

This initiates a `__kernel_read` call from `p9_read_work` (and
`p9_fd_read`) and since the `file->f_mode` does not contain FMODE_READ
, a WARN_ON_ONCE is thrown.

```
if (WARN_ON_ONCE(!(file->f_mode & FMODE_READ)))
 return -EINVAL;
```

Can you help me understand what's wrong and fix this issue? 
Is it already being worked on?

Thank you

Cengiz Can

On Tue, 2020-07-14 at 13:02 +0200, Christoph Hellwig wrote:
> On Mon, Jul 13, 2020 at 12:03:17AM -0700, syzbot wrote:
> > Hello,
> > 
> > syzbot found the following crash on:
> 
> This is not a crash, but a WARN_ON_ONCE, someone really needs to fix
> syzbot to report this correctly.
> 
> The fix should be queued up by the 9p maintainers.
> 
> > HEAD commit:a581387e Merge tag 'io_uring-5.8-2020-07-10' of
> > git://git...
> > git tree:   upstream
> > console output: 
> > https://syzkaller.appspot.com/x/log.txt?x=13e730eb10
> > kernel config:  
> > https://syzkaller.appspot.com/x/.config?x=66ad203c2bb6d8b
> > dashboard link: 
> > https://syzkaller.appspot.com/bug?extid=d012ca3f813739c37c25
> > compiler:   gcc (GCC) 10.1.0-syz 20200507
> > syz repro:  
> > https://syzkaller.appspot.com/x/repro.syz?x=12e0222b10
> > C reproducer:   
> > https://syzkaller.appspot.com/x/repro.c?x=162a004f10
> > 
> > The bug was bisected to:
> > 
> > commit 6209dd9132e8ea5545cffc84483841e88ea8cc5b
> > Author: Christoph Hellwig 
> > Date:   Fri May 8 07:00:28 2020 +
> > 
> > fs: implement kernel_read using __kernel_read
> > 
> > bisection log:  
> > https://syzkaller.appspot.com/x/bisect.txt?x=152d91fb10
> > final crash:
> > https://syzkaller.appspot.com/x/report.txt?x=172d91fb10
> > console output: 
> > https://syzkaller.appspot.com/x/log.txt?x=132d91fb10
> > 
> > IMPORTANT: if you fix the bug, please add the following tag to the
> > commit:
> > Reported-by: syzbot+d012ca3f813739c37...@syzkaller.appspotmail.com
> > Fixes: 6209dd9132e8 ("fs: implement kernel_read using
> > __kernel_read")
> > 
> > [ cut here ]
> > WARNING: CPU: 0 PID: 5 at fs/read_write.c:427
> > __kernel_read+0x41d/0x4d0 fs/read_write.c:427
> > Kernel panic - not syncing: panic_on_warn set ...
> > CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.8.0-rc4-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine,
> > BIOS Google 01/01/2011
> > Workqueue: events p9_read_work
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:77 [inline]
> >  dump_stack+0x18f/0x20d lib/dump_stack.c:118
> >  panic+0x2e3/0x75c kernel/panic.c:231
> >  __warn.cold+0x20/0x45 kernel/panic.c:600
> >  report_bug+0x1bd/0x210 lib/bug.c:198
> >  handle_bug+0x38/0x90 arch/x86/kernel/traps.c:235
> >  exc_invalid_op+0x13/0x40 arch/x86/kernel/traps.c:255
> >  asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:542
> > RIP: 0010:__kernel_read+0x41d/0x4d0 fs/read_write.c:427
> > Code: fd ff ff e8 75 19 b6 ff 45 31 c9 45 31 c0 b9 01 00 00 00 4c
> > 89 f2 89 ee 4c 89 ef e8 5d 22 12 00 e9 46 ff ff ff e8 53 19 b6 ff
> > <0f> 0b 49 c7 c4 ea ff ff ff e9 11 fe ff ff 4c 89 f7 e8 2d 76 f5 ff
> > RSP: 0018:c9cbfbc8 EFLAGS: 00010293
> > RAX:  RBX: 8880a9786ac0 RCX: 81bd9ac4
> > RDX: 8880a95a2140 RSI: 81bd9e3d RDI: 0005
> > RBP: 888096bc8060 R08:  R09: 
> > R10:  R11: 11829bdd R12: 081d801e
> > R13: c9cbfc98 R14: 8880a9786b44 R15: 0007
> >  kernel_read+0x52/0x70 fs/read_write.c:457
> >  p9_fd_read net/9p/trans_fd.c:263 [inline]
> >  p9_read_work+0x2ac/0xff0 net/9p/trans_fd.c:298
> >  process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
> >  worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
> >  kthread+0x3b5/0x4a0 kernel/kthread.c:291
> >  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
> > Kernel Offset: disabled
> > Rebooting in 86400 seconds..
> > 
> > 
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkal...@googlegroups.com.
> > 
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > For information about bisection process see: 
> > https://goo.gl/tpsmEJ#bisection
> > syzbot can test patches for this bug, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
> ---end quoted text---

Re: [PATCH v3] kdb: remove unnecessary null check of dbg_io_ops

[Cengiz Can]

Hello Daniel,

On 2020-07-01 01:32, Doug Anderson wrote:


Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 


Wanted to ask about the status of this proposed patch.

I have checked your tree in git.kernel.org but you might be
collecting them somewhere else perhaps.

Thank you for your time

--
Cengiz Can
@cengiz_io

[PATCH v3] kdb: remove unnecessary null check of dbg_io_ops

[Cengiz Can]

`kdb_msg_write` operates on a global `struct kgdb_io *` called
`dbg_io_ops`.

It's initialized in `debug_core.c` and checked throughout the debug
flow.

There's a null check in `kdb_msg_write` which triggers static analyzers
and gives the (almost entirely wrong) impression that it can be null.

Coverity scanner caught this as CID 1465042.

I have removed the unnecessary null check and eliminated false-positive
forward null dereference warning.

Signed-off-by: Cengiz Can 
---
 kernel/debug/kdb/kdb_io.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index 683a799618ad..81783ecaec58 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -545,18 +545,18 @@ static int kdb_search_string(char *searched, char 
*searchfor)
 static void kdb_msg_write(const char *msg, int msg_len)
 {
struct console *c;
+   const char *cp;
+   int len;
 
if (msg_len == 0)
return;
 
-   if (dbg_io_ops) {
-   const char *cp = msg;
-   int len = msg_len;
+   cp = msg;
+   len = msg_len;
 
-   while (len--) {
-   dbg_io_ops->write_char(*cp);
-   cp++;
-   }
+   while (len--) {
+   dbg_io_ops->write_char(*cp);
+   cp++;
}
 
for_each_console(c) {
-- 
2.27.0

Re: [PATCH v2] kdb: remove unnecessary null check of dbg_io_ops

[Cengiz Can]

On June 30, 2020 00:16:54 Doug Anderson  wrote:


Hi,

On Mon, Jun 29, 2020 at 1:50 PM Cengiz Can  wrote:


`kdb_msg_write` operates on a global `struct kgdb_io *` called
`dbg_io_ops`.

It's initialized in `debug_core.c` and checked throughout the debug
flow.

There's a null check in `kdb_msg_write` which triggers static analyzers
and gives the (almost entirely wrong) impression that it can be null.

Coverity scanner caught this as CID 1465042.

I have removed the unnecessary null check and eliminated false-positive
forward null dereference warning.

Signed-off-by: Cengiz Can 
---
kernel/debug/kdb/kdb_io.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index 683a799618ad..4ac59a4fbeec 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -549,14 +549,12 @@ static void kdb_msg_write(const char *msg, int msg_len)
if (msg_len == 0)
   return;

-   if (dbg_io_ops) {
-   const char *cp = msg;
-   int len = msg_len;
+   const char *cp = msg;
+   int len = msg_len;


kernel/debug/kdb/kdb_io.c:552:14:
warning: ISO C90 forbids mixing declarations and code
[-Wdeclaration-after-statement]


Oops!

Sorry for that..

I admit I didn't compile check my second attempt.

/me ducks and covers

Will fix it asap.

Thanks!



-Doug

[PATCH v2] kdb: remove unnecessary null check of dbg_io_ops

[Cengiz Can]

`kdb_msg_write` operates on a global `struct kgdb_io *` called
`dbg_io_ops`.

It's initialized in `debug_core.c` and checked throughout the debug
flow.

There's a null check in `kdb_msg_write` which triggers static analyzers
and gives the (almost entirely wrong) impression that it can be null.

Coverity scanner caught this as CID 1465042.

I have removed the unnecessary null check and eliminated false-positive
forward null dereference warning.

Signed-off-by: Cengiz Can 
---
 kernel/debug/kdb/kdb_io.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index 683a799618ad..4ac59a4fbeec 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -549,14 +549,12 @@ static void kdb_msg_write(const char *msg, int msg_len)
if (msg_len == 0)
return;
 
-   if (dbg_io_ops) {
-   const char *cp = msg;
-   int len = msg_len;
+   const char *cp = msg;
+   int len = msg_len;
 
-   while (len--) {
-   dbg_io_ops->write_char(*cp);
-   cp++;
-   }
+   while (len--) {
+   dbg_io_ops->write_char(*cp);
+   cp++;
}
 
for_each_console(c) {
-- 
2.27.0

[PATCH] kdb: prevent possible null deref in kdb_msg_write

[Cengiz Can]

`kdb_msg_write` operates on a global `struct kgdb_io *` called
`dbg_io_ops`.

Although it is initialized in `debug_core.c`, there's a null check in
`kdb_msg_write` which implies that it can be null whenever we dereference
it in this function call.

Coverity scanner caught this as CID 1465042.

I have modified the function to bail out if `dbg_io_ops` is not properly
initialized.

Signed-off-by: Cengiz Can 
---
 kernel/debug/kdb/kdb_io.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index 683a799618ad..85e579812458 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -549,14 +549,15 @@ static void kdb_msg_write(const char *msg, int msg_len)
if (msg_len == 0)
return;
 
-   if (dbg_io_ops) {
-   const char *cp = msg;
-   int len = msg_len;
+   if (!dbg_io_ops)
+   return;
 
-   while (len--) {
-   dbg_io_ops->write_char(*cp);
-   cp++;
-   }
+   const char *cp = msg;
+   int len = msg_len;
+
+   while (len--) {
+   dbg_io_ops->write_char(*cp);
+   cp++;
}
 
for_each_console(c) {
-- 
2.27.0

Re: [PATCH v2] i2c: i2c-mt65xx: fix NULL ptr dereference

[Cengiz Can]

On 2019-09-30 18:28, Fabien Parent wrote:
Fixes: abf4923e97c3 ("i2c: mediatek: disable zero-length transfers for 
mt8183")

Signed-off-by: Fabien Parent 


Reviewed-by: Cengiz Can 

Re: [PATCH] i2c: pca954x: Add property to skip disabling PCA954x MUX device

[Cengiz Can]

Hello Biwen,

> +   /* Errata ID E-00013 on board LS2088ARDB and LS2088ARDB:
> +* The point here is that you must not disable a mux if there
> +* are no pullups on the input or you mess up the I2C. This
> +* needs to be put into the DTS really as the kernel cannot
> +* know this otherwise.
> +*/

Can you please explain what a "mess up" is?

And also, should we put this new DTS property in related default
bindings? 

If not, are you planning a documentation update for the users to notify
them about this?

-- 
Cengiz Can 

Re: [PATCH v2] i2c: update i2c-dev.h warning in documentation

[Cengiz Can]

> Applied to the docs tree, thanks.  Note that the patch was wrapped by your
> mailer and I had to fix it up; that would be nice to avoid in the future.

Thank you!

I've ditched claws-mail and will use git send-mail instead.

-- 
Cengiz Can

Re: [PATCH v2] i2c: update i2c-dev.h warning in documentation

[Cengiz Can]

> Applied to the docs tree, thanks.  Note that the patch was wrapped by your
> mailer and I had to fix it up; that would be nice to avoid in the future.

Thank you!

I've ditched claws-mail and will use git send-mail instead.

-- 
Cengiz Can

[PATCH] i2c: update i2c-dev.h warning in documentation

[Cengiz Can]

`dev-interface` document gives examples for accessing i2c from
userspace.

There's a note warning developers about the different `i2c-dev.h` header
files which were shipped with the kernel and i2c-tools separately.

However, these commits in i2c-tools repository suggests that the header
files are now identical (in functionality) and `i2c_*` functions are now
defined in a separate header called `i2c/smbus.h`, which is distributed
with i2c-tools:

commit 652619121974 ("Minimize differences with kernel flavor")
commit 93caf007f4cb ("Move SMBus helper functions to include/i2c/smbus.h")

Thus, I've converted the warning paragraph into a historical note and
updated the suggested header files.

Signed-off-by: Cengiz Can <ceng...@gmail.com>
---
Sorry for duplicate mails. My email client hard-wrapped previous patch.

Thanks.

 Documentation/i2c/dev-interface | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index 5ff19447ac44..04d110697863 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -9,21 +9,24 @@ i2c adapters present on your system at a given time. 
i2cdetect is part of
 the i2c-tools package.
 
 I2C device files are character device files with major device number 89
-and a minor device number corresponding to the number assigned as 
-explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ..., 
+and a minor device number corresponding to the number assigned as
+explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
 i2c-10, ...). All 256 minor device numbers are reserved for i2c.
 
 
 C example
 =
 
-So let's say you want to access an i2c adapter from a C program. The
-first thing to do is "#include ". Please note that
-there are two files named "i2c-dev.h" out there, one is distributed
-with the Linux kernel and is meant to be included from kernel
-driver code, the other one is distributed with i2c-tools and is
-meant to be included from user-space programs. You obviously want
-the second one here.
+So let's say you want to access an i2c adapter from a C program. First, you
+need to include these two headers:
+
+  #include 
+  #include 
+
+(Please note that there are two files named "i2c-dev.h" out there. One is
+distributed with the Linux kernel and the other one is included in the
+source tree of i2c-tools. They used to be different in content but since 2012
+they're identical. You should use "linux/i2c-dev.h").
 
 Now, you have to decide which adapter you want to access. You should
 inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
@@ -35,7 +38,7 @@ Next thing, open the device file, as follows:
   int file;
   int adapter_nr = 2; /* probably dynamically determined */
   char filename[20];
-  
+
   snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
   file = open(filename, O_RDWR);
   if (file < 0) {
@@ -69,7 +72,7 @@ the device supports them. Both are illustrated below.
 /* res contains the read word */
   }
 
-  /* Using I2C Write, equivalent of 
+  /* Using I2C Write, equivalent of
  i2c_smbus_write_word_data(file, reg, 0x6543) */
   buf[0] = reg;
   buf[1] = 0x43;
@@ -144,7 +147,7 @@ You can do plain i2c transactions by using read(2) and 
write(2) calls.
 You do not need to pass the address byte; instead, set it through
 ioctl I2C_SLAVE before you try to access the device.
 
-You can do SMBus level transactions (see documentation file smbus-protocol 
+You can do SMBus level transactions (see documentation file smbus-protocol
 for details) through the following functions:
   __s32 i2c_smbus_write_quick(int file, __u8 value);
   __s32 i2c_smbus_read_byte(int file);
@@ -155,7 +158,7 @@ for details) through the following functions:
   __s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
   __s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
   __s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
-  __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length, 
+  __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
 All these transactions return -1 on failure; you can read errno to see
 what happened. The 'write' transactions return 0 on success; the
-- 
2.15.1



-- 
Cengiz Can

[PATCH] i2c: update i2c-dev.h warning in documentation

[Cengiz Can]

`dev-interface` document gives examples for accessing i2c from
userspace.

There's a note warning developers about the different `i2c-dev.h` header
files which were shipped with the kernel and i2c-tools separately.

However, these commits in i2c-tools repository suggests that the header
files are now identical (in functionality) and `i2c_*` functions are now
defined in a separate header called `i2c/smbus.h`, which is distributed
with i2c-tools:

commit 652619121974 ("Minimize differences with kernel flavor")
commit 93caf007f4cb ("Move SMBus helper functions to include/i2c/smbus.h")

Thus, I've converted the warning paragraph into a historical note and
updated the suggested header files.

Signed-off-by: Cengiz Can 
---
Sorry for duplicate mails. My email client hard-wrapped previous patch.

Thanks.

 Documentation/i2c/dev-interface | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index 5ff19447ac44..04d110697863 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -9,21 +9,24 @@ i2c adapters present on your system at a given time. 
i2cdetect is part of
 the i2c-tools package.
 
 I2C device files are character device files with major device number 89
-and a minor device number corresponding to the number assigned as 
-explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ..., 
+and a minor device number corresponding to the number assigned as
+explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
 i2c-10, ...). All 256 minor device numbers are reserved for i2c.
 
 
 C example
 =
 
-So let's say you want to access an i2c adapter from a C program. The
-first thing to do is "#include ". Please note that
-there are two files named "i2c-dev.h" out there, one is distributed
-with the Linux kernel and is meant to be included from kernel
-driver code, the other one is distributed with i2c-tools and is
-meant to be included from user-space programs. You obviously want
-the second one here.
+So let's say you want to access an i2c adapter from a C program. First, you
+need to include these two headers:
+
+  #include 
+  #include 
+
+(Please note that there are two files named "i2c-dev.h" out there. One is
+distributed with the Linux kernel and the other one is included in the
+source tree of i2c-tools. They used to be different in content but since 2012
+they're identical. You should use "linux/i2c-dev.h").
 
 Now, you have to decide which adapter you want to access. You should
 inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
@@ -35,7 +38,7 @@ Next thing, open the device file, as follows:
   int file;
   int adapter_nr = 2; /* probably dynamically determined */
   char filename[20];
-  
+
   snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
   file = open(filename, O_RDWR);
   if (file < 0) {
@@ -69,7 +72,7 @@ the device supports them. Both are illustrated below.
 /* res contains the read word */
   }
 
-  /* Using I2C Write, equivalent of 
+  /* Using I2C Write, equivalent of
  i2c_smbus_write_word_data(file, reg, 0x6543) */
   buf[0] = reg;
   buf[1] = 0x43;
@@ -144,7 +147,7 @@ You can do plain i2c transactions by using read(2) and 
write(2) calls.
 You do not need to pass the address byte; instead, set it through
 ioctl I2C_SLAVE before you try to access the device.
 
-You can do SMBus level transactions (see documentation file smbus-protocol 
+You can do SMBus level transactions (see documentation file smbus-protocol
 for details) through the following functions:
   __s32 i2c_smbus_write_quick(int file, __u8 value);
   __s32 i2c_smbus_read_byte(int file);
@@ -155,7 +158,7 @@ for details) through the following functions:
   __s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
   __s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
   __s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
-  __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length, 
+  __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
 All these transactions return -1 on failure; you can read errno to see
 what happened. The 'write' transactions return 0 on success; the
-- 
2.15.1



-- 
Cengiz Can

[PATCH] i2c: update i2c-dev.h warning in documentation

[Cengiz Can]

`dev-interface` document gives examples for accessing i2c from
userspace.

There's a note warning developers about the different `i2c-dev.h` header
files which were shipped with the kernel and i2c-tools separately.

However, these commits in i2c-tools repository suggests that the header
files are now identical (in functionality) and `i2c_*` functions are now
defined in a separate header called `i2c/smbus.h`, which is distributed
with i2c-tools:

commit 652619121974 ("Minimize differences with kernel flavor")
commit 93caf007f4cb ("Move SMBus helper functions to include/i2c/smbus.h")

Thus, I've converted the warning paragraph into a historical note and
updated the suggested header files.

Signed-off-by: Cengiz Can <ceng...@gmail.com>
---
 Documentation/i2c/dev-interface | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/Documentation/i2c/dev-interface
b/Documentation/i2c/dev-interface index 5ff19447ac44..04d110697863
100644 --- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -9,21 +9,24 @@ i2c adapters present on your system at a given time.
i2cdetect is part of the i2c-tools package.
 
 I2C device files are character device files with major device number 89
-and a minor device number corresponding to the number assigned as 
-explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ..., 
+and a minor device number corresponding to the number assigned as
+explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
 i2c-10, ...). All 256 minor device numbers are reserved for i2c.
 
 
 C example
 =
 
-So let's say you want to access an i2c adapter from a C program. The
-first thing to do is "#include ". Please note that
-there are two files named "i2c-dev.h" out there, one is distributed
-with the Linux kernel and is meant to be included from kernel
-driver code, the other one is distributed with i2c-tools and is
-meant to be included from user-space programs. You obviously want
-the second one here.
+So let's say you want to access an i2c adapter from a C program.
First, you +need to include these two headers:
+
+  #include 
+  #include 
+
+(Please note that there are two files named "i2c-dev.h" out there. One
is +distributed with the Linux kernel and the other one is included in
the +source tree of i2c-tools. They used to be different in content but
since 2012 +they're identical. You should use "linux/i2c-dev.h").
 
 Now, you have to decide which adapter you want to access. You should
 inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
@@ -35,7 +38,7 @@ Next thing, open the device file, as follows:
   int file;
   int adapter_nr = 2; /* probably dynamically determined */
   char filename[20];
-  
+
   snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
   file = open(filename, O_RDWR);
   if (file < 0) {
@@ -69,7 +72,7 @@ the device supports them. Both are illustrated below.
 /* res contains the read word */
   }
 
-  /* Using I2C Write, equivalent of 
+  /* Using I2C Write, equivalent of
  i2c_smbus_write_word_data(file, reg, 0x6543) */
   buf[0] = reg;
   buf[1] = 0x43;
@@ -144,7 +147,7 @@ You can do plain i2c transactions by using read(2)
and write(2) calls. You do not need to pass the address byte; instead,
set it through ioctl I2C_SLAVE before you try to access the device.
 
-You can do SMBus level transactions (see documentation file
smbus-protocol +You can do SMBus level transactions (see documentation
file smbus-protocol for details) through the following functions:
   __s32 i2c_smbus_write_quick(int file, __u8 value);
   __s32 i2c_smbus_read_byte(int file);
@@ -155,7 +158,7 @@ for details) through the following functions:
   __s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
   __s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
   __s32 i2c_smbus_read_block_data(int file, __u8 command, __u8
*values);
-  __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8
length, 
+  __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
 All these transactions return -1 on failure; you can read errno to see
 what happened. The 'write' transactions return 0 on success; the
-- 
2.15.1

[PATCH] i2c: update i2c-dev.h warning in documentation

[Cengiz Can]

`dev-interface` document gives examples for accessing i2c from
userspace.

There's a note warning developers about the different `i2c-dev.h` header
files which were shipped with the kernel and i2c-tools separately.

However, these commits in i2c-tools repository suggests that the header
files are now identical (in functionality) and `i2c_*` functions are now
defined in a separate header called `i2c/smbus.h`, which is distributed
with i2c-tools:

commit 652619121974 ("Minimize differences with kernel flavor")
commit 93caf007f4cb ("Move SMBus helper functions to include/i2c/smbus.h")

Thus, I've converted the warning paragraph into a historical note and
updated the suggested header files.

Signed-off-by: Cengiz Can 
---
 Documentation/i2c/dev-interface | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/Documentation/i2c/dev-interface
b/Documentation/i2c/dev-interface index 5ff19447ac44..04d110697863
100644 --- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -9,21 +9,24 @@ i2c adapters present on your system at a given time.
i2cdetect is part of the i2c-tools package.
 
 I2C device files are character device files with major device number 89
-and a minor device number corresponding to the number assigned as 
-explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ..., 
+and a minor device number corresponding to the number assigned as
+explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
 i2c-10, ...). All 256 minor device numbers are reserved for i2c.
 
 
 C example
 =
 
-So let's say you want to access an i2c adapter from a C program. The
-first thing to do is "#include ". Please note that
-there are two files named "i2c-dev.h" out there, one is distributed
-with the Linux kernel and is meant to be included from kernel
-driver code, the other one is distributed with i2c-tools and is
-meant to be included from user-space programs. You obviously want
-the second one here.
+So let's say you want to access an i2c adapter from a C program.
First, you +need to include these two headers:
+
+  #include 
+  #include 
+
+(Please note that there are two files named "i2c-dev.h" out there. One
is +distributed with the Linux kernel and the other one is included in
the +source tree of i2c-tools. They used to be different in content but
since 2012 +they're identical. You should use "linux/i2c-dev.h").
 
 Now, you have to decide which adapter you want to access. You should
 inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
@@ -35,7 +38,7 @@ Next thing, open the device file, as follows:
   int file;
   int adapter_nr = 2; /* probably dynamically determined */
   char filename[20];
-  
+
   snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
   file = open(filename, O_RDWR);
   if (file < 0) {
@@ -69,7 +72,7 @@ the device supports them. Both are illustrated below.
 /* res contains the read word */
   }
 
-  /* Using I2C Write, equivalent of 
+  /* Using I2C Write, equivalent of
  i2c_smbus_write_word_data(file, reg, 0x6543) */
   buf[0] = reg;
   buf[1] = 0x43;
@@ -144,7 +147,7 @@ You can do plain i2c transactions by using read(2)
and write(2) calls. You do not need to pass the address byte; instead,
set it through ioctl I2C_SLAVE before you try to access the device.
 
-You can do SMBus level transactions (see documentation file
smbus-protocol +You can do SMBus level transactions (see documentation
file smbus-protocol for details) through the following functions:
   __s32 i2c_smbus_write_quick(int file, __u8 value);
   __s32 i2c_smbus_read_byte(int file);
@@ -155,7 +158,7 @@ for details) through the following functions:
   __s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
   __s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
   __s32 i2c_smbus_read_block_data(int file, __u8 command, __u8
*values);
-  __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8
length, 
+  __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
 All these transactions return -1 on failure; you can read errno to see
 what happened. The 'write' transactions return 0 on success; the
-- 
2.15.1

unregister_netdevice: waiting for lo to become free. Usage count = 1

[Cengiz Can]

Hello!

In case anyone wondering (like I did) if this is still an issue, it's not.

It was fixed in 4.12.

unregister_netdevice: waiting for lo to become free. Usage count = 1

[Cengiz Can]

Hello!

In case anyone wondering (like I did) if this is still an issue, it's not.

It was fixed in 4.12.

[PATCH] hwmon: applesmc: fix deprecated hwmon_device_register call

[Cengiz Can]

Hello.

This is my first patch attempt on drivers so I might be completely wrong.

applesmc driver was using the deprecated `hwmon_device_register` call for
some reason. And that causes a deprecation warning in dmesg.

I've replaced the call with `hwmon_device_register_with_info` and booted
my MBP 11,2 with it.

The warning is no longer shown. And the functionality doesn't seem to be
broken.

Thank you for reading this.

Signed-off-by: Cengiz Can <ceng...@gmail.com>
---
 drivers/hwmon/applesmc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index 0af7fd311979..6e897310151a 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -1326,7 +1326,11 @@ static int __init applesmc_init(void)
if (ret)
goto out_light_sysfs;
 
-   hwmon_dev = hwmon_device_register(>dev);
+   hwmon_dev = hwmon_device_register_with_info(>dev,
+  "applesmcbacklight",
+  NULL,
+  NULL,
+  NULL);
if (IS_ERR(hwmon_dev)) {
ret = PTR_ERR(hwmon_dev);
goto out_light_ledclass;
-- 
2.13.2

[PATCH] hwmon: applesmc: fix deprecated hwmon_device_register call

[Cengiz Can]

Hello.

This is my first patch attempt on drivers so I might be completely wrong.

applesmc driver was using the deprecated `hwmon_device_register` call for
some reason. And that causes a deprecation warning in dmesg.

I've replaced the call with `hwmon_device_register_with_info` and booted
my MBP 11,2 with it.

The warning is no longer shown. And the functionality doesn't seem to be
broken.

Thank you for reading this.

Signed-off-by: Cengiz Can 
---
 drivers/hwmon/applesmc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index 0af7fd311979..6e897310151a 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -1326,7 +1326,11 @@ static int __init applesmc_init(void)
if (ret)
goto out_light_sysfs;
 
-   hwmon_dev = hwmon_device_register(>dev);
+   hwmon_dev = hwmon_device_register_with_info(>dev,
+  "applesmcbacklight",
+  NULL,
+  NULL,
+  NULL);
if (IS_ERR(hwmon_dev)) {
ret = PTR_ERR(hwmon_dev);
goto out_light_ledclass;
-- 
2.13.2