On Fri, Jun 15, 2018 at 2:08 AM Jani Nikula <jani.nikula@xxxxxxxxx> wrote: > > 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. A change like this would be a matter of having a sed/cocci/whatever script that can be reproduced later. The end result can be split in logical chunks for review/merge, I never said it ought to be in one patch. Lucas De Marchi > > 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 -- Lucas De Marchi _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
