On Thu, 14 Jun 2018, Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> wrote: > On Wed, Jun 13, 2018 at 09:55:38AM +0300, Jani Nikula wrote: >> On Tue, 12 Jun 2018, Lucas De Marchi <lucas.de.marchi@xxxxxxxxx> wrote: >> > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula <jani.nikula@xxxxxxxxx> wrote: >> >> >> >> On Tue, 12 Jun 2018, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: >> >> > On 12/06/2018 10:19, Jani Nikula wrote: >> >> >> Semi-RFC. Do we want to do this? Here's a batch of conversions that shouldn't >> >> >> conflict much with in-flight patches. >> >> >> >> >> >> The trouble with mixed use is that it's inconsistent, and any remaining C99 >> >> >> types will encourage their use. We could at least do the low hanging fruit? >> >> > >> >> > Ack from me. Doesn't seem so big to cause much pain. >> >> > >> >> > When you say low-hanging fruit, that implies you only dealt with a >> >> > particular class of occurrences? >> >> >> >> I meant the files which don't have massive amounts of C99 types and >> >> aren't under active development right now. I just wanted to avoid >> >> trouble for starters. ;) >> > >> > If using kernel types is where we want to go (which I agree with), >> > maybe it would be better to have a single conversion rather than >> > several small ones as we are doing with dev_priv -> i915? This allows >> > in-flight-but-not-yet-sent patches to easily keep up with the changes >> > rather than conflicting every other rebase. >> >> I'm thinking we can do a lot of changes without conflicting anything or >> very little. At least for starters before the sudden ripping off the >> band-aid. > > I'm with Lucas. I'd prefer one single massive move than many small ones. > Easier for the internal maintenance. We fix it only once and not one per > day for months and months like dev_priv/i915 case. For everything else, I believe smaller patches are easier. For example, who is going to review the massive change? Halt everything until it's reviewed and merged? For merge conflicts I think git can do a better job of managing the rerere with piecemeal changes. Internal is not the only consideration. BR, Jani. > >> >> BR, >> Jani. >> >> > >> > Lucas De Marchi >> > >> >> >> >> > Also going forward we have to make sure we will be able to stop them >> >> > creeping back in. Is checkpatch perhaps covering this? Or we could put >> >> > something in dim? >> >> >> >> We can stop ignoring PREFER_KERNEL_TYPES in checkpatch (the ignores are >> >> in dim). We don't even have to change everything for that, we just need >> >> to change enough to make the S/N better. People tend to use the types >> >> near the places they change. >> >> >> >> BR, >> >> Jani. >> >> >> >> >> >> > >> >> > Regards, >> >> > >> >> > Tvrtko >> >> > >> >> >> $ git grep "uint\(8\|16\|32\|64\)_t" -- drivers/gpu/drm/i915/ | sed 's/:.*//' | sort | uniq -c | sort -n >> >> >> >> >> >> BR, >> >> >> Jani. >> >> >> >> >> >> >> >> >> Jani Nikula (7): >> >> >> drm/i915/vbt: switch to kernel unsigned int types >> >> >> drm/i915/hdmi: switch to kernel unsigned int types >> >> >> drm/i915/uncore: switch to kernel unsigned int types >> >> >> drm/i915/dvo: switch to kernel unsigned int types >> >> >> drm/i915/backlight: switch to kernel unsigned int types >> >> >> drm/i915/audio: switch to kernel unsigned int types >> >> >> drm/i915/lspcon: switch to kernel unsigned int types >> >> >> >> >> >> drivers/gpu/drm/i915/dvo_ch7017.c | 20 ++++++------ >> >> >> drivers/gpu/drm/i915/dvo_ch7xxx.c | 22 +++++++------- >> >> >> drivers/gpu/drm/i915/dvo_ivch.c | 26 ++++++++-------- >> >> >> drivers/gpu/drm/i915/dvo_ns2501.c | 44 +++++++++++++-------------- >> >> >> drivers/gpu/drm/i915/dvo_sil164.c | 10 +++--- >> >> >> drivers/gpu/drm/i915/dvo_tfp410.c | 16 +++++----- >> >> >> drivers/gpu/drm/i915/intel_audio.c | 36 +++++++++++----------- >> >> >> drivers/gpu/drm/i915/intel_bios.c | 4 +-- >> >> >> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 12 ++++---- >> >> >> drivers/gpu/drm/i915/intel_dvo.c | 2 +- >> >> >> drivers/gpu/drm/i915/intel_hdmi.c | 14 ++++----- >> >> >> drivers/gpu/drm/i915/intel_lspcon.c | 2 +- >> >> >> drivers/gpu/drm/i915/intel_panel.c | 8 ++--- >> >> >> drivers/gpu/drm/i915/intel_uncore.h | 22 +++++++------- >> >> >> drivers/gpu/drm/i915/intel_vbt_defs.h | 2 +- >> >> >> 15 files changed, 120 insertions(+), 120 deletions(-) >> >> >> >> >> >> >> -- >> >> Jani Nikula, Intel Open Source Graphics Center >> >> _______________________________________________ >> >> Intel-gfx mailing list >> >> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >> -- >> Jani Nikula, Intel Open Source Graphics Center >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
