From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EEB19C636CC for ; Tue, 31 Jan 2023 18:17:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230109AbjAaSR3 (ORCPT ); Tue, 31 Jan 2023 13:17:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229488AbjAaSR1 (ORCPT ); Tue, 31 Jan 2023 13:17:27 -0500 Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0759E14234 for ; Tue, 31 Jan 2023 10:17:27 -0800 (PST) Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-4c131bede4bso214734047b3.5 for ; Tue, 31 Jan 2023 10:17:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FvdAZD01d8l2dE2yYKs95f5aYb2hmlRgz5dCsUMJuqc=; b=mj0IrcCsuervH4LzfdcuQVY+qIdS49hTvLNTEpZON0scxgtX2UJZgOEy4IS6Uiy3N3 /uFAyQ+iU+eYBtwXEkiXtsEIVmv0j/FnyeaCq2A4EKYR2x3bNBwS7EfDrGuW7MSLWB/A da+jryzDREJYJokFjWTq5SzjKOJmwF8lDDk+A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FvdAZD01d8l2dE2yYKs95f5aYb2hmlRgz5dCsUMJuqc=; b=CkiDHsgahmYUv+NDaYCTyLIM+5QHFEdKBwK8TaZxvVmIxM9Iuc4tHhUTK/7pmu5Kv6 Fshq8DWEtHWQDnGLaXEOpARgIcROg+MQ3wlPFAEx+BpFNggbRICXjXiVbQDmH5CpvAPg qPuxhhBXu4x1tWrEENvO9jJ6BgrAN8I3Y/3hHP1XBqzxDlZ4t6W/X3NX4eo/w/hoWl+L riKAq3qHgMPEWBnj2zsxKADuG6nMjHmtZ3UmUhGbNjAMp9wB0N2iP/RL6V4Q+lcE2uzp pIIoqGlbBQGMYI/QPMFrq7uX/fiUEn1fWxr1Dxwy07LkAbgNqx2YiqR0jduXNy1BR6wx q1gg== X-Gm-Message-State: AO0yUKV0qf8rir1OcfsGZphgNG52M22YwnodNMlDvEq8RgGl5fvD8AcV GBGzOkbsniL/NML6M6ADJclIladXqDFkpIOVLgDtV7HH4sd/dw== X-Google-Smtp-Source: AK7set9Ho9990bCiAPi6W5tf4wuIgRKLoCIYpoMYERmBL6WCAN7Vp/gWEdWfZnfLnz1nlp6of9x83VoHN6qHiT/Xl0k= X-Received: by 2002:a81:52ce:0:b0:506:60ca:21c3 with SMTP id g197-20020a8152ce000000b0050660ca21c3mr4156259ywb.197.1675189046291; Tue, 31 Jan 2023 10:17:26 -0800 (PST) MIME-Version: 1.0 References: <20230113182626.1149539-1-pmalani@chromium.org> In-Reply-To: From: Prashant Malani Date: Tue, 31 Jan 2023 10:17:14 -0800 Message-ID: Subject: Re: [PATCH] platform/chrome: cros_typec_vdm: Fix VDO copy To: Tzung-Bi Shih Cc: linux-kernel@vger.kernel.org, chrome-platform@lists.linux.dev, bleung@chromium.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Tzung-Bi, On Mon, Jan 30, 2023 at 7:49 PM Tzung-Bi Shih wrote: > > On Fri, Jan 13, 2023 at 06:26:26PM +0000, Prashant Malani wrote: > > The usage of memcpy() affects the representation of the VDOs as they are > > copied to the EC Host Command buffer. Specifically, all higher order > > bits get dropped (for example: a VDO of 0x406 just gets copied as 0x6). > > memcpy() is byte-oriented; however, `vdo` is a pointer to u32. > > > Avoid this by explicitly copying each VDO in the array. The number of > > VDOs generated by alternate mode drivers in their VDMs is almost always > > just 1 (apart from the header) so this doesn't affect performance in a > > meaningful way). > > Although the patch has applied, I am wondering if the following would be a > better way to fix the issue: > > memcpy(&vdm_req.vdm_data[1], vdo, (cnt - 1) * sizeof(*vdo)); Yeah, that's right; I forgot that 'cnt' is "number of VDOs" and not "number of bytes" :S As I mentioned, in a vast majority of cases, the number of VDOs is just 1, so I wouldn't bother and just leave this as it is (since there is no major benefit apart from saving 1 line).