[V25,0/3] misc: Add driver support for Data Capture and Compare unit(DCC)

  DCC(Data Capture and Compare) is a DMA engine designed for debugging purposes.
In case of a system crash or manual software triggers by the user the DCC hardware
stores the value at the register addresses which can be used for debugging purposes.
The DCC driver provides the user with debugfs interface to configure the register
addresses. The options that the DCC hardware provides include reading from registers,
writing to registers, first reading and then writing to registers and looping
through the values of the same register.

In certain cases a register write needs to be executed for accessing the rest of the
registers, also the user might want to record the changing values of a register with
time for which he has the option to use the loop feature.

The options mentioned above are exposed to the user by debugfs files once the driver
is probed. The details and usage of this debugfs files are documented in
Documentation/ABI/testing/debugfs-driver-dcc.

As an example let us consider a couple of debug scenarios where DCC has been proved to be
effective for debugging purposes:-

i)TimeStamp Related Issue

On SC7180, there was a coresight timestamp issue where it would occasionally be all 0
instead of proper timestamp values.

Proper timestamp:
Idx:3373; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x13004d8f5b7aa; CC=0x9e

Zero timestamp:
Idx:3387; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x0; CC=0xa2

Now this is a non-fatal issue and doesn't need a system reset, but still needs
to be rootcaused and fixed for those who do care about coresight etm traces.
Since this is a timestamp issue, we would be looking for any timestamp related
clocks and such.

We get all the clk register details from IP documentation and configure it
via DCC config_read debugfs node. Before that we set the current linked list.

/* Program the linked list with the addresses */
echo R 0x10c004 > /sys/kernel/debug/qcom-dcc/../3/config
echo R 0x10c008 > /sys/kernel/debug/qcom-dcc/../3/config
echo R 0x10c00c > /sys/kernel/debug/qcom-dcc/../3/config
echo R 0x10c010 > /sys/kernel/debug/qcom-dcc/../3/config
..... and so on for other timestamp related clk registers

/* Other way of specifying is in "addr len" pair, in below case it
specifies to capture 4 words starting 0x10C004 */

echo R 0x10C004 4 > /sys/kernel/debug/qcom-dcc/../3/config_read

/* Enable DCC */
echo 1 > /sys/kernel/debug/qcom-dcc/../3/enable

/* Run the timestamp test for working case */

/* Send SW trigger */
echo 1 > /sys/kernel/debug/qcom-dcc/../trigger

/* Read SRAM */
cat /dev/dcc_sram > dcc_sram1.bin

/* Run the timestamp test for non-working case */

/* Send SW trigger */
echo 1 > /sys/kernel/debug/qcom-dcc/../trigger

/* Read SRAM */
cat /dev/dcc_sram > dcc_sram2.bin

Get the parser from [1] and checkout the latest branch.

/* Parse the SRAM bin */
python dcc_parser.py -s dcc_sram1.bin --v2 -o output/
python dcc_parser.py -s dcc_sram2.bin --v2 -o output/

Sample parsed output of dcc_sram1.bin:

<hwioDump version="1">
         <timestamp>03/14/21</timestamp>
             <generator>Linux DCC Parser</generator>
                 <chip name="None" version="None">
                 <register address="0x0010c004" value="0x80000000" />
                 <register address="0x0010c008" value="0x00000008" />
                 <register address="0x0010c00c" value="0x80004220" />
                 <register address="0x0010c010" value="0x80000000" />
             </chip>
     <next_ll_offset>next_ll_offset : 0x1c </next_ll_offset>
</hwioDump>

ii)NOC register errors

A particular class of registers called NOC which are functional registers was reporting
errors while logging the values.To trace these errors the DCC has been used effectively.
The steps followed were similar to the ones mentioned above.
In addition to NOC registers a few other dependent registers were configured in DCC to
monitor it's values during a crash. A look at the dependent register values revealed that
the crash was happening due to a secured access to one of these dependent registers.
All these debugging activity and finding the root cause was achieved using DCC.

DCC parser is available at the following open source location

https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser

Changes in v25

* Updated the documentation of the structure dcc_config_entry as per the comments in V23
* Updated the documentation of the dcc Kconfig definition as per comment in V24
* Used u64 where applicable
* Removed the mutex locks where it is not needed
* Removed the use of unlikely keyword
* Renamed "nr_link_list" to "max_link_list"

Souradeep Chowdhury (3):
  dt-bindings: misc: qcom,dcc: Add the dtschema
  misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
  MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
    support

 Documentation/ABI/testing/debugfs-driver-dcc  |   10 +-
 .../devicetree/bindings/misc/qcom,dcc.yaml    |   44 +
 MAINTAINERS                                   |    8 +
 drivers/misc/Kconfig                          |    8 +
 drivers/misc/Makefile                         |    1 +
 drivers/misc/qcom-dcc.c                       | 1312 +++++++++++++++++
 6 files changed, 1378 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml
 create mode 100644 drivers/misc/qcom-dcc.c
  

On 6/28/2023 3:53 PM, Souradeep Chowdhury wrote:
> DCC(Data Capture and Compare) is a DMA engine designed for debugging purposes.
> In case of a system crash or manual software triggers by the user the DCC hardware
> stores the value at the register addresses which can be used for debugging purposes.
> The DCC driver provides the user with debugfs interface to configure the register
> addresses. The options that the DCC hardware provides include reading from registers,
> writing to registers, first reading and then writing to registers and looping
> through the values of the same register.
> 
> In certain cases a register write needs to be executed for accessing the rest of the
> registers, also the user might want to record the changing values of a register with
> time for which he has the option to use the loop feature.
> 
> The options mentioned above are exposed to the user by debugfs files once the driver
> is probed. The details and usage of this debugfs files are documented in
> Documentation/ABI/testing/debugfs-driver-dcc.
> 
> As an example let us consider a couple of debug scenarios where DCC has been proved to be
> effective for debugging purposes:-
> 
> i)TimeStamp Related Issue
> 
> On SC7180, there was a coresight timestamp issue where it would occasionally be all 0
> instead of proper timestamp values.
> 
> Proper timestamp:
> Idx:3373; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x13004d8f5b7aa; CC=0x9e
> 
> Zero timestamp:
> Idx:3387; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x0; CC=0xa2
> 
> Now this is a non-fatal issue and doesn't need a system reset, but still needs
> to be rootcaused and fixed for those who do care about coresight etm traces.
> Since this is a timestamp issue, we would be looking for any timestamp related
> clocks and such.
> 
> We get all the clk register details from IP documentation and configure it
> via DCC config_read debugfs node. Before that we set the current linked list.
> 
> /* Program the linked list with the addresses */
> echo R 0x10c004 > /sys/kernel/debug/qcom-dcc/../3/config
> echo R 0x10c008 > /sys/kernel/debug/qcom-dcc/../3/config
> echo R 0x10c00c > /sys/kernel/debug/qcom-dcc/../3/config
> echo R 0x10c010 > /sys/kernel/debug/qcom-dcc/../3/config
> ..... and so on for other timestamp related clk registers
> 
> /* Other way of specifying is in "addr len" pair, in below case it
> specifies to capture 4 words starting 0x10C004 */
> 
> echo R 0x10C004 4 > /sys/kernel/debug/qcom-dcc/../3/config_read
> 
> /* Enable DCC */
> echo 1 > /sys/kernel/debug/qcom-dcc/../3/enable
> 
> /* Run the timestamp test for working case */
> 
> /* Send SW trigger */
> echo 1 > /sys/kernel/debug/qcom-dcc/../trigger
> 
> /* Read SRAM */
> cat /dev/dcc_sram > dcc_sram1.bin
> 
> /* Run the timestamp test for non-working case */
> 
> /* Send SW trigger */
> echo 1 > /sys/kernel/debug/qcom-dcc/../trigger
> 
> /* Read SRAM */
> cat /dev/dcc_sram > dcc_sram2.bin
> 
> Get the parser from [1] and checkout the latest branch.
> 
> /* Parse the SRAM bin */
> python dcc_parser.py -s dcc_sram1.bin --v2 -o output/
> python dcc_parser.py -s dcc_sram2.bin --v2 -o output/
> 
> Sample parsed output of dcc_sram1.bin:
> 
> <hwioDump version="1">
>           <timestamp>03/14/21</timestamp>
>               <generator>Linux DCC Parser</generator>
>                   <chip name="None" version="None">
>                   <register address="0x0010c004" value="0x80000000" />
>                   <register address="0x0010c008" value="0x00000008" />
>                   <register address="0x0010c00c" value="0x80004220" />
>                   <register address="0x0010c010" value="0x80000000" />
>               </chip>
>       <next_ll_offset>next_ll_offset : 0x1c </next_ll_offset>
> </hwioDump>
> 
> ii)NOC register errors
> 
> A particular class of registers called NOC which are functional registers was reporting
> errors while logging the values.To trace these errors the DCC has been used effectively.
> The steps followed were similar to the ones mentioned above.
> In addition to NOC registers a few other dependent registers were configured in DCC to
> monitor it's values during a crash. A look at the dependent register values revealed that
> the crash was happening due to a secured access to one of these dependent registers.
> All these debugging activity and finding the root cause was achieved using DCC.
> 
> DCC parser is available at the following open source location
> 
> https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser
> 
> Changes in v25
> 
> * Updated the documentation of the structure dcc_config_entry as per the comments in V23
> * Updated the documentation of the dcc Kconfig definition as per comment in V24
> * Used u64 where applicable
> * Removed the mutex locks where it is not needed
> * Removed the use of unlikely keyword
> * Renamed "nr_link_list" to "max_link_list"
> 
> Souradeep Chowdhury (3):
>    dt-bindings: misc: qcom,dcc: Add the dtschema
>    misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
>    MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
>      support
> 
>   Documentation/ABI/testing/debugfs-driver-dcc  |   10 +-
>   .../devicetree/bindings/misc/qcom,dcc.yaml    |   44 +
>   MAINTAINERS                                   |    8 +
>   drivers/misc/Kconfig                          |    8 +
>   drivers/misc/Makefile                         |    1 +
>   drivers/misc/qcom-dcc.c                       | 1312 +++++++++++++++++
>   6 files changed, 1378 insertions(+), 5 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml
>   create mode 100644 drivers/misc/qcom-dcc.c
> 

Gentle ping
  

On Tue, Jul 18, 2023 at 10:33:09AM +0530, Souradeep Chowdhury wrote:
> On 6/28/2023 3:53 PM, Souradeep Chowdhury wrote:
> > Souradeep Chowdhury (3):
> >    dt-bindings: misc: qcom,dcc: Add the dtschema
> >    misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
> >    MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
> >      support
> > 
> >   Documentation/ABI/testing/debugfs-driver-dcc  |   10 +-
> >   .../devicetree/bindings/misc/qcom,dcc.yaml    |   44 +
> >   MAINTAINERS                                   |    8 +
> >   drivers/misc/Kconfig                          |    8 +
> >   drivers/misc/Makefile                         |    1 +
> >   drivers/misc/qcom-dcc.c                       | 1312 +++++++++++++++++
> >   6 files changed, 1378 insertions(+), 5 deletions(-)
> >   create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml
> >   create mode 100644 drivers/misc/qcom-dcc.c
> > 
> 
> Gentle ping

$ mdfrm -c mail/todo/
1480 messages in todo/

Please relax, and help out by reviewing other patches on the mailing
lists in order to relieve the burden of maintainers and move your
patches higher up the list.

thanks,

greg k-h
  

On 6/28/2023 3:53 PM, Souradeep Chowdhury wrote:
> DCC(Data Capture and Compare) is a DMA engine designed for debugging purposes.
> In case of a system crash or manual software triggers by the user the DCC hardware
> stores the value at the register addresses which can be used for debugging purposes.
> The DCC driver provides the user with debugfs interface to configure the register
> addresses. The options that the DCC hardware provides include reading from registers,
> writing to registers, first reading and then writing to registers and looping
> through the values of the same register.
> 
> In certain cases a register write needs to be executed for accessing the rest of the
> registers, also the user might want to record the changing values of a register with
> time for which he has the option to use the loop feature.
> 
> The options mentioned above are exposed to the user by debugfs files once the driver
> is probed. The details and usage of this debugfs files are documented in
> Documentation/ABI/testing/debugfs-driver-dcc.
> 
> As an example let us consider a couple of debug scenarios where DCC has been proved to be
> effective for debugging purposes:-
> 
> i)TimeStamp Related Issue
> 
> On SC7180, there was a coresight timestamp issue where it would occasionally be all 0
> instead of proper timestamp values.
> 
> Proper timestamp:
> Idx:3373; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x13004d8f5b7aa; CC=0x9e
> 
> Zero timestamp:
> Idx:3387; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x0; CC=0xa2
> 
> Now this is a non-fatal issue and doesn't need a system reset, but still needs
> to be rootcaused and fixed for those who do care about coresight etm traces.
> Since this is a timestamp issue, we would be looking for any timestamp related
> clocks and such.
> 
> We get all the clk register details from IP documentation and configure it
> via DCC config_read debugfs node. Before that we set the current linked list.
> 
> /* Program the linked list with the addresses */
> echo R 0x10c004 > /sys/kernel/debug/qcom-dcc/../3/config
> echo R 0x10c008 > /sys/kernel/debug/qcom-dcc/../3/config
> echo R 0x10c00c > /sys/kernel/debug/qcom-dcc/../3/config
> echo R 0x10c010 > /sys/kernel/debug/qcom-dcc/../3/config
> ..... and so on for other timestamp related clk registers
> 
> /* Other way of specifying is in "addr len" pair, in below case it
> specifies to capture 4 words starting 0x10C004 */
> 
> echo R 0x10C004 4 > /sys/kernel/debug/qcom-dcc/../3/config_read
> 
> /* Enable DCC */
> echo 1 > /sys/kernel/debug/qcom-dcc/../3/enable
> 
> /* Run the timestamp test for working case */
> 
> /* Send SW trigger */
> echo 1 > /sys/kernel/debug/qcom-dcc/../trigger
> 
> /* Read SRAM */
> cat /dev/dcc_sram > dcc_sram1.bin
> 
> /* Run the timestamp test for non-working case */
> 
> /* Send SW trigger */
> echo 1 > /sys/kernel/debug/qcom-dcc/../trigger
> 
> /* Read SRAM */
> cat /dev/dcc_sram > dcc_sram2.bin
> 
> Get the parser from [1] and checkout the latest branch.
> 
> /* Parse the SRAM bin */
> python dcc_parser.py -s dcc_sram1.bin --v2 -o output/
> python dcc_parser.py -s dcc_sram2.bin --v2 -o output/
> 
> Sample parsed output of dcc_sram1.bin:
> 
> <hwioDump version="1">
>           <timestamp>03/14/21</timestamp>
>               <generator>Linux DCC Parser</generator>
>                   <chip name="None" version="None">
>                   <register address="0x0010c004" value="0x80000000" />
>                   <register address="0x0010c008" value="0x00000008" />
>                   <register address="0x0010c00c" value="0x80004220" />
>                   <register address="0x0010c010" value="0x80000000" />
>               </chip>
>       <next_ll_offset>next_ll_offset : 0x1c </next_ll_offset>
> </hwioDump>
> 
> ii)NOC register errors
> 
> A particular class of registers called NOC which are functional registers was reporting
> errors while logging the values.To trace these errors the DCC has been used effectively.
> The steps followed were similar to the ones mentioned above.
> In addition to NOC registers a few other dependent registers were configured in DCC to
> monitor it's values during a crash. A look at the dependent register values revealed that
> the crash was happening due to a secured access to one of these dependent registers.
> All these debugging activity and finding the root cause was achieved using DCC.
> 
> DCC parser is available at the following open source location
> 
> https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser
> 
> Changes in v25
> 
> * Updated the documentation of the structure dcc_config_entry as per the comments in V23
> * Updated the documentation of the dcc Kconfig definition as per comment in V24
> * Used u64 where applicable
> * Removed the mutex locks where it is not needed
> * Removed the use of unlikely keyword
> * Renamed "nr_link_list" to "max_link_list"
> 
> Souradeep Chowdhury (3):
>    dt-bindings: misc: qcom,dcc: Add the dtschema
>    misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
>    MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
>      support
> 
>   Documentation/ABI/testing/debugfs-driver-dcc  |   10 +-
>   .../devicetree/bindings/misc/qcom,dcc.yaml    |   44 +
>   MAINTAINERS                                   |    8 +
>   drivers/misc/Kconfig                          |    8 +
>   drivers/misc/Makefile                         |    1 +
>   drivers/misc/qcom-dcc.c                       | 1312 +++++++++++++++++
>   6 files changed, 1378 insertions(+), 5 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml
>   create mode 100644 drivers/misc/qcom-dcc.c

Gentle Ping
  

On 8/3/2023 12:06 AM, Souradeep Chowdhury wrote:
> 
> 
> On 6/28/2023 3:53 PM, Souradeep Chowdhury wrote:

...

>>
>> https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser
>>
>> Changes in v25
>>
>> * Updated the documentation of the structure dcc_config_entry as per 
>> the comments in V23
>> * Updated the documentation of the dcc Kconfig definition as per 
>> comment in V24
>> * Used u64 where applicable
>> * Removed the mutex locks where it is not needed
>> * Removed the use of unlikely keyword
>> * Renamed "nr_link_list" to "max_link_list"
>>
>> Souradeep Chowdhury (3):
>>    dt-bindings: misc: qcom,dcc: Add the dtschema
>>    misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
>>    MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
>>      support
>>
>>   Documentation/ABI/testing/debugfs-driver-dcc  |   10 +-
>>   .../devicetree/bindings/misc/qcom,dcc.yaml    |   44 +
>>   MAINTAINERS                                   |    8 +
>>   drivers/misc/Kconfig                          |    8 +
>>   drivers/misc/Makefile                         |    1 +
>>   drivers/misc/qcom-dcc.c                       | 1312 +++++++++++++++++
>>   6 files changed, 1378 insertions(+), 5 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml
>>   create mode 100644 drivers/misc/qcom-dcc.c
> 
> Gentle Ping

Thank you for the reminder Souradeep. Greg and others, please see if we 
need any changes here or it can be picked up?
  

On Thu, Aug 03, 2023 at 07:35:18AM -0700, Trilok Soni wrote:
> On 8/3/2023 12:06 AM, Souradeep Chowdhury wrote:
> > 
> > 
> > On 6/28/2023 3:53 PM, Souradeep Chowdhury wrote:
> 
> ...
> 
> > > 
> > > https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser
> > > 
> > > Changes in v25
> > > 
> > > * Updated the documentation of the structure dcc_config_entry as per
> > > the comments in V23
> > > * Updated the documentation of the dcc Kconfig definition as per
> > > comment in V24
> > > * Used u64 where applicable
> > > * Removed the mutex locks where it is not needed
> > > * Removed the use of unlikely keyword
> > > * Renamed "nr_link_list" to "max_link_list"
> > > 
> > > Souradeep Chowdhury (3):
> > >    dt-bindings: misc: qcom,dcc: Add the dtschema
> > >    misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
> > >    MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
> > >      support
> > > 
> > >   Documentation/ABI/testing/debugfs-driver-dcc  |   10 +-
> > >   .../devicetree/bindings/misc/qcom,dcc.yaml    |   44 +
> > >   MAINTAINERS                                   |    8 +
> > >   drivers/misc/Kconfig                          |    8 +
> > >   drivers/misc/Makefile                         |    1 +
> > >   drivers/misc/qcom-dcc.c                       | 1312 +++++++++++++++++
> > >   6 files changed, 1378 insertions(+), 5 deletions(-)
> > >   create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml
> > >   create mode 100644 drivers/misc/qcom-dcc.c
> > 
> > Gentle Ping
> 
> Thank you for the reminder Souradeep. Greg and others, please see if we need
> any changes here or it can be picked up?

It would help if the code would actually build:

drivers/misc/qcom-dcc.c: In function ‘ready_read’:
drivers/misc/qcom-dcc.c:853:13: error: unused variable ‘ret’ [-Werror=unused-variable]
  853 |         int ret = 0;
      |             ^~~

{sigh}

How in the world was this ever tested?

greg k-h
  

On Fri, Aug 04, 2023 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 03, 2023 at 07:35:18AM -0700, Trilok Soni wrote:
> > On 8/3/2023 12:06 AM, Souradeep Chowdhury wrote:
> > > 
> > > 
> > > On 6/28/2023 3:53 PM, Souradeep Chowdhury wrote:
> > 
> > ...
> > 
> > > > 
> > > > https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser
> > > > 
> > > > Changes in v25
> > > > 
> > > > * Updated the documentation of the structure dcc_config_entry as per
> > > > the comments in V23
> > > > * Updated the documentation of the dcc Kconfig definition as per
> > > > comment in V24
> > > > * Used u64 where applicable
> > > > * Removed the mutex locks where it is not needed
> > > > * Removed the use of unlikely keyword
> > > > * Renamed "nr_link_list" to "max_link_list"
> > > > 
> > > > Souradeep Chowdhury (3):
> > > >    dt-bindings: misc: qcom,dcc: Add the dtschema
> > > >    misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
> > > >    MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
> > > >      support
> > > > 
> > > >   Documentation/ABI/testing/debugfs-driver-dcc  |   10 +-
> > > >   .../devicetree/bindings/misc/qcom,dcc.yaml    |   44 +
> > > >   MAINTAINERS                                   |    8 +
> > > >   drivers/misc/Kconfig                          |    8 +
> > > >   drivers/misc/Makefile                         |    1 +
> > > >   drivers/misc/qcom-dcc.c                       | 1312 +++++++++++++++++
> > > >   6 files changed, 1378 insertions(+), 5 deletions(-)
> > > >   create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml
> > > >   create mode 100644 drivers/misc/qcom-dcc.c
> > > 
> > > Gentle Ping
> > 
> > Thank you for the reminder Souradeep. Greg and others, please see if we need
> > any changes here or it can be picked up?
> 
> It would help if the code would actually build:
> 
> drivers/misc/qcom-dcc.c: In function ‘ready_read’:
> drivers/misc/qcom-dcc.c:853:13: error: unused variable ‘ret’ [-Werror=unused-variable]
>   853 |         int ret = 0;
>       |             ^~~
> 
> {sigh}
> 
> How in the world was this ever tested?

Ok, next time I want to see some QCOM engineers to sign off on this that
it was actually tested and they can back it up that this is ready to be
merged.  When the code doesn't even build, that is a huge red flag that
this whole thing is being rushed as it obviously was never tested in the
form that was submitted for inclusion.

You all know better than this.

greg k-h
  

On 8/4/2023 7:19 PM, Greg Kroah-Hartman wrote:
> On Fri, Aug 04, 2023 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
>> On Thu, Aug 03, 2023 at 07:35:18AM -0700, Trilok Soni wrote:
>>> On 8/3/2023 12:06 AM, Souradeep Chowdhury wrote:
>>>>
>>>>
>>>> On 6/28/2023 3:53 PM, Souradeep Chowdhury wrote:
>>>
>>> ...
>>>
>>>>>
>>>>> https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser
>>>>>
>>>>> Changes in v25
>>>>>
>>>>> * Updated the documentation of the structure dcc_config_entry as per
>>>>> the comments in V23
>>>>> * Updated the documentation of the dcc Kconfig definition as per
>>>>> comment in V24
>>>>> * Used u64 where applicable
>>>>> * Removed the mutex locks where it is not needed
>>>>> * Removed the use of unlikely keyword
>>>>> * Renamed "nr_link_list" to "max_link_list"
>>>>>
>>>>> Souradeep Chowdhury (3):
>>>>>     dt-bindings: misc: qcom,dcc: Add the dtschema
>>>>>     misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
>>>>>     MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
>>>>>       support
>>>>>
>>>>>    Documentation/ABI/testing/debugfs-driver-dcc  |   10 +-
>>>>>    .../devicetree/bindings/misc/qcom,dcc.yaml    |   44 +
>>>>>    MAINTAINERS                                   |    8 +
>>>>>    drivers/misc/Kconfig                          |    8 +
>>>>>    drivers/misc/Makefile                         |    1 +
>>>>>    drivers/misc/qcom-dcc.c                       | 1312 +++++++++++++++++
>>>>>    6 files changed, 1378 insertions(+), 5 deletions(-)
>>>>>    create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml
>>>>>    create mode 100644 drivers/misc/qcom-dcc.c
>>>>
>>>> Gentle Ping
>>>
>>> Thank you for the reminder Souradeep. Greg and others, please see if we need
>>> any changes here or it can be picked up?
>>
>> It would help if the code would actually build:
>>
>> drivers/misc/qcom-dcc.c: In function ‘ready_read’:
>> drivers/misc/qcom-dcc.c:853:13: error: unused variable ‘ret’ [-Werror=unused-variable]
>>    853 |         int ret = 0;
>>        |             ^~~
>>
>> {sigh}
>>
>> How in the world was this ever tested?
> 
> Ok, next time I want to see some QCOM engineers to sign off on this that
> it was actually tested and they can back it up that this is ready to be
> merged.  When the code doesn't even build, that is a huge red flag that
> this whole thing is being rushed as it obviously was never tested in the
> form that was submitted for inclusion.
> 
> You all know better than this.

My apologies on missing out on this, it is a W=1 level compilation 
warning that got suppressed on a normal kernel build. I will be
posting V26 by correcting this. Otherwise, this driver has no
functional issues and is already ported in downstream kernels.

> 
> greg k-h
  

On Mon, Aug 07, 2023 at 11:03:45PM +0530, Souradeep Chowdhury wrote:
> 
> 
> On 8/4/2023 7:19 PM, Greg Kroah-Hartman wrote:
> > On Fri, Aug 04, 2023 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Aug 03, 2023 at 07:35:18AM -0700, Trilok Soni wrote:
> > > > On 8/3/2023 12:06 AM, Souradeep Chowdhury wrote:
> > > > > 
> > > > > 
> > > > > On 6/28/2023 3:53 PM, Souradeep Chowdhury wrote:
> > > > 
> > > > ...
> > > > 
> > > > > > 
> > > > > > https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser
> > > > > > 
> > > > > > Changes in v25
> > > > > > 
> > > > > > * Updated the documentation of the structure dcc_config_entry as per
> > > > > > the comments in V23
> > > > > > * Updated the documentation of the dcc Kconfig definition as per
> > > > > > comment in V24
> > > > > > * Used u64 where applicable
> > > > > > * Removed the mutex locks where it is not needed
> > > > > > * Removed the use of unlikely keyword
> > > > > > * Renamed "nr_link_list" to "max_link_list"
> > > > > > 
> > > > > > Souradeep Chowdhury (3):
> > > > > >     dt-bindings: misc: qcom,dcc: Add the dtschema
> > > > > >     misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
> > > > > >     MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
> > > > > >       support
> > > > > > 
> > > > > >    Documentation/ABI/testing/debugfs-driver-dcc  |   10 +-
> > > > > >    .../devicetree/bindings/misc/qcom,dcc.yaml    |   44 +
> > > > > >    MAINTAINERS                                   |    8 +
> > > > > >    drivers/misc/Kconfig                          |    8 +
> > > > > >    drivers/misc/Makefile                         |    1 +
> > > > > >    drivers/misc/qcom-dcc.c                       | 1312 +++++++++++++++++
> > > > > >    6 files changed, 1378 insertions(+), 5 deletions(-)
> > > > > >    create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml
> > > > > >    create mode 100644 drivers/misc/qcom-dcc.c
> > > > > 
> > > > > Gentle Ping
> > > > 
> > > > Thank you for the reminder Souradeep. Greg and others, please see if we need
> > > > any changes here or it can be picked up?
> > > 
> > > It would help if the code would actually build:
> > > 
> > > drivers/misc/qcom-dcc.c: In function ‘ready_read’:
> > > drivers/misc/qcom-dcc.c:853:13: error: unused variable ‘ret’ [-Werror=unused-variable]
> > >    853 |         int ret = 0;
> > >        |             ^~~
> > > 
> > > {sigh}
> > > 
> > > How in the world was this ever tested?
> > 
> > Ok, next time I want to see some QCOM engineers to sign off on this that
> > it was actually tested and they can back it up that this is ready to be
> > merged.  When the code doesn't even build, that is a huge red flag that
> > this whole thing is being rushed as it obviously was never tested in the
> > form that was submitted for inclusion.
> > 
> > You all know better than this.
> 
> My apologies on missing out on this, it is a W=1 level compilation warning
> that got suppressed on a normal kernel build.

No, not at all, it showed up on my "normal kernel build", I do not have
"W=1" set at all.

If you did a simple "make allmodconfig" I am pretty sure it would have
tripped this.

How exactly was this tested?

thanks,

greg k-h
  

On 8/7/2023 11:14 PM, Greg Kroah-Hartman wrote:
> On Mon, Aug 07, 2023 at 11:03:45PM +0530, Souradeep Chowdhury wrote:
>>
>>
>> On 8/4/2023 7:19 PM, Greg Kroah-Hartman wrote:
>>> On Fri, Aug 04, 2023 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
>>>> On Thu, Aug 03, 2023 at 07:35:18AM -0700, Trilok Soni wrote:
>>>>> On 8/3/2023 12:06 AM, Souradeep Chowdhury wrote:
>>>>>>
>>>>>>
>>>>>> On 6/28/2023 3:53 PM, Souradeep Chowdhury wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>>>
>>>>>>> https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser
>>>>>>>
>>>>>>> Changes in v25
>>>>>>>
>>>>>>> * Updated the documentation of the structure dcc_config_entry as per
>>>>>>> the comments in V23
>>>>>>> * Updated the documentation of the dcc Kconfig definition as per
>>>>>>> comment in V24
>>>>>>> * Used u64 where applicable
>>>>>>> * Removed the mutex locks where it is not needed
>>>>>>> * Removed the use of unlikely keyword
>>>>>>> * Renamed "nr_link_list" to "max_link_list"
>>>>>>>
>>>>>>> Souradeep Chowdhury (3):
>>>>>>>      dt-bindings: misc: qcom,dcc: Add the dtschema
>>>>>>>      misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
>>>>>>>      MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
>>>>>>>        support
>>>>>>>
>>>>>>>     Documentation/ABI/testing/debugfs-driver-dcc  |   10 +-
>>>>>>>     .../devicetree/bindings/misc/qcom,dcc.yaml    |   44 +
>>>>>>>     MAINTAINERS                                   |    8 +
>>>>>>>     drivers/misc/Kconfig                          |    8 +
>>>>>>>     drivers/misc/Makefile                         |    1 +
>>>>>>>     drivers/misc/qcom-dcc.c                       | 1312 +++++++++++++++++
>>>>>>>     6 files changed, 1378 insertions(+), 5 deletions(-)
>>>>>>>     create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml
>>>>>>>     create mode 100644 drivers/misc/qcom-dcc.c
>>>>>>
>>>>>> Gentle Ping
>>>>>
>>>>> Thank you for the reminder Souradeep. Greg and others, please see if we need
>>>>> any changes here or it can be picked up?
>>>>
>>>> It would help if the code would actually build:
>>>>
>>>> drivers/misc/qcom-dcc.c: In function ‘ready_read’:
>>>> drivers/misc/qcom-dcc.c:853:13: error: unused variable ‘ret’ [-Werror=unused-variable]
>>>>     853 |         int ret = 0;
>>>>         |             ^~~
>>>>
>>>> {sigh}
>>>>
>>>> How in the world was this ever tested?
>>>
>>> Ok, next time I want to see some QCOM engineers to sign off on this that
>>> it was actually tested and they can back it up that this is ready to be
>>> merged.  When the code doesn't even build, that is a huge red flag that
>>> this whole thing is being rushed as it obviously was never tested in the
>>> form that was submitted for inclusion.
>>>
>>> You all know better than this.
>>
>> My apologies on missing out on this, it is a W=1 level compilation warning
>> that got suppressed on a normal kernel build.
> 
> No, not at all, it showed up on my "normal kernel build", I do not have
> "W=1" set at all.
> 
> If you did a simple "make allmodconfig" I am pretty sure it would have
> tripped this.
> 
> How exactly was this tested?

My toolchain interprets this as a W=1 level warning rather than an 
error. So I am able to build the kernel with it. Probably because I
am using an older version. Will correct this in the next version.

> 
> thanks,
> 
> greg k-h