i'm still adding to my kernel janitors page here: https://crashcourse.ca/doku/doku.php?id=linux_kernel_cleanup and after poking around some more this weekend, it seems like there's still a pile of potential cleanup related to simplifying the calculation of the length of an array. recall, this is the explanation of how to calculate the length of an array in C: https://crashcourse.ca/doku/doku.php?id=linux_kernel_cleanup#calculating_the_length_of_an_array recall that the script supplied there allows you to restrict your search to a subdirectory or subsystem, so i chose to focus on: $ cd drivers/gpu/drm/amd/display/dc i ran my script: $ arraysize.sh ./dce/dce_clock_source.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) ./dpp/dcn401/dcn401_dpp_cm.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) ./dpp/dcn401/dcn401_dpp_cm.c: int arr_size = sizeof(dpp_input_csc_matrix) / sizeof(struct dpp_input_csc_matrix); ./dpp/dcn30/dcn30_dpp.c: int arr_size = sizeof(dpp_input_csc_matrix)/sizeof(struct dpp_input_csc_matrix); ./dpp/dcn20/dcn20_dpp_cm.c: int arr_size = sizeof(dpp_input_csc_matrix)/sizeof(struct dpp_input_csc_matrix); ./dpp/dcn10/dcn10_dpp_cm.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) ./dpp/dcn10/dcn10_dpp_cm.c: int arr_size = sizeof(dpp_input_csc_matrix)/sizeof(struct dpp_input_csc_matrix); ./core/dc_hw_sequencer.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) ./dml/dcn20/dcn20_fpu.c: for (k = 0; k < sizeof(wb_arb_params->cli_watermark)/sizeof(wb_arb_params->cli_watermark[0]); k++) { ./dml/dsc/rc_calc_fpu.c: table_size = sizeof(qp_table_##mode##_##bpc##bpc_##max)/sizeof(*qp_table_##mode##_##bpc##bpc_##max); \ ./dce110/dce110_opp_csc_v.c: int arr_size = sizeof(input_csc_matrix)/sizeof(struct input_csc_matrix); ./mpc/dcn30/dcn30_mpc.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) ./mpc/dcn20/dcn20_mpc.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) so what does the above tell us? first, there's obvious simplification, but don't stop there. note that some of those files define "NUM_ELEMENTS()", so that's a hint that that can be simplified, but let's go further and see how many of those files actually *use* the macro they just defined: $ grep -rw NUM_ELEMENTS * core/dc_hw_sequencer.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) core/dc_hw_sequencer.c: int arr_size = NUM_ELEMENTS(output_csc_matrix); dce/dce_clock_source.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) dce/dce_clock_source.c: for (i = 0; i < NUM_ELEMENTS(video_optimized_pixel_rates); i++) { dpp/dcn401/dcn401_dpp_cm.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) dpp/dcn10/dcn10_dpp_cm.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) mpc/dcn30/dcn30_mpc.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) mpc/dcn20/dcn20_mpc.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0])) so it seems that at least a couple of files define that macro without actually using it. this is the sort of analysis you should do. don't blindly submit patches; rather, take your time, and examine the files in their entirety in a subdirectory or subsystem, and check the Git log and/or run "git blame" to see why things are the way they are. thoughts? rday
