lkml.org 
[lkml]   [2020]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v2 01/12] drm/i915/dp: convert to struct drm_device based logging macros.
    Date
    On Thu, 06 Feb 2020, Wambui Karuga <wambui.karugax@gmail.com> wrote:
    > @@ -5990,11 +6040,13 @@ int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
    > static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
    > u8 *bksv)
    > {
    > + struct intel_dp *intel_dp = &intel_dig_port->dp;
    > ssize_t ret;
    > ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BKSV, bksv,
    > DRM_HDCP_KSV_LEN);
    > if (ret != DRM_HDCP_KSV_LEN) {
    > - DRM_DEBUG_KMS("Read Bksv from DP/AUX failed (%zd)\n", ret);
    > + drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
    > + "Read Bksv from DP/AUX failed (%zd)\n", ret);
    > return ret >= 0 ? -EIO : ret;
    > }

    If you're introducing local variables just for logging, I would prefer
    it to be i915.

    struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);

    ...

    drm_dbg_kms(&i915->drm, ...);

    If you look at dp_to_i915() it actually converts intel_dp back to
    intel_digital_port, and then does the above to it, to get at i915. This
    is an unnecessary dance.

    It's fine to use &dp_to_i915(intel_dp)->drm when there are only a couple
    of logging calls in a function, and intel_dp is already there. But any
    more than that, and I'd add the i915 local variable. For example, but
    not limited to, intel_dp_handle_test_request() would benefit from i915
    local var.

    BR,
    Jani.


    --
    Jani Nikula, Intel Open Source Graphics Center

    \
     
     \ /
      Last update: 2020-02-11 15:03    [W:3.168 / U:0.628 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site