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
