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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3DC7CC7EE29 for ; Fri, 9 Jun 2023 19:16:11 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6978984791; Fri, 9 Jun 2023 21:16:09 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="YSJoeHlS"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D357785E73; Fri, 9 Jun 2023 21:16:06 +0200 (CEST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 43D71846E5 for ; Fri, 9 Jun 2023 21:16:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=cfsworks@gmail.com Received: by mail-io1-xd32.google.com with SMTP id ca18e2360f4ac-777a6ebb542so88791739f.0 for ; Fri, 09 Jun 2023 12:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686338163; x=1688930163; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=bdjm1CRct0vw2eMXbvJpBLmdcXsf8PZs8LNIMrRmoH4=; b=YSJoeHlS5XmHl18fJbdmkilweMzo/aF4n+z908WkITIgqTWOsYX9i1dWkbrIiGjCE0 JqYnDzXrNUAK9O/LVSpVRZdoMzWY4zvqn67XP+fVhhgrg7t6xGssGsihsGyxUqMNc5fi U+9uqfL+3HRWNLatAzfqftglxwQjkROa/DUHWDe5WrcIqScR6AbxAaGr4Oa362tSqw7G 3Km/j1+afPgVrfFr33Rb0X1MhAD55tGmRGnek1Ao5hdHs20IS7pS2DNh+/m9e/GBNQ7V WnUULUGBnBW6att0L5LEKmeVON3szwlYl7mrubDPPWBR3kOM6mDJPyOo74HaIqY+6x5X yGBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686338163; x=1688930163; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bdjm1CRct0vw2eMXbvJpBLmdcXsf8PZs8LNIMrRmoH4=; b=QJ25JhTC4WsmSXcu8mR9VjrMi2MkSiYRTfw9HfXY0RSltA8+jB7mPOYedTw3+bpCHI 46d3gM3QhQAg6w7k3zmXGMnJ7T3Whsf6umQzckP2F1kwoZZPu4IdHYx3D0i46ufaIOG4 ws1SBCUh63FLdKf6Pi+fq4W1ef0z1RbntOJbHjSrh/N7PZ7mkL5FLKdpw8oPOkrOMsin p4TAcOxIZoinFlNzmwIoV/kyWPi0YyYv+Ybqd2mrbtLOsFO8/DKUngTdNkUL4GxcFZSF 06gwp+qps8c1NjAiKemRo9u93nK/tFnuhHmTFQTvtJ/vYV3mkn7ce86dEJc08Z1PwizC 4hvg== X-Gm-Message-State: AC+VfDzFcrHZW3dvVRfxWzMQmD2LQ9R179upM137UcgoEPOCfNZagoBV 4HvON0BfnIx1v5+YBfSAR7DpI1An5He3WxxN X-Google-Smtp-Source: ACHHUZ4pBVavf3mTGpV5Yc1ZbIrEl33ICojPhpiv2nHB+hFV2KctrrsjH+13dxzS6Ej5sp5Q/hkaug== X-Received: by 2002:a5e:8416:0:b0:777:b8c8:d7db with SMTP id h22-20020a5e8416000000b00777b8c8d7dbmr2568126ioj.1.1686338162795; Fri, 09 Jun 2023 12:16:02 -0700 (PDT) Received: from ?IPV6:2001:470:42c4:101:d264:8856:b4e9:a431? ([2001:470:42c4:101:d264:8856:b4e9:a431]) by smtp.gmail.com with ESMTPSA id b19-20020a6be713000000b00777b7fdbbffsm1223075ioh.8.2023.06.09.12.16.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jun 2023 12:16:02 -0700 (PDT) Message-ID: <8a921ccb-cdc3-80a0-d155-708e908fd712@gmail.com> Date: Fri, 9 Jun 2023 13:16:00 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization Content-Language: en-US To: Andre Przywara Cc: u-boot@lists.denx.de, Jagan Teki , Marek Vasut References: <20230607231644.28203-1-CFSworks@gmail.com> <20230607231644.28203-3-CFSworks@gmail.com> <20230609111330.1f3f59a9@donnerap.cambridge.arm.com> From: Sam Edwards In-Reply-To: <20230609111330.1f3f59a9@donnerap.cambridge.arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean Hi Andre, I've applied most of this feedback (most of which comes as a relief; I dislike inventing names for mystery bits) in preparation to send a v2, but had two questions: On 6/9/23 04:13, Andre Przywara wrote: >> The new comments and function name are not from any official source, >> but are updated to mirror how the Linux kernel sources treat this >> mystery magic bit. If we wanted to confirm that this speculation is >> correct, we could verify that SRAM-D is inaccessible whenever the >> bit is set, and then try clearing it again while the MUSB is in use >> to see what debris gets left behind in SRAM-D. >> >> This cleanup also adds a TODO comment about runtime discovery >> of the SYSCON base, per discussion with Andre. > > thanks for sending this, looks good. Some stylistic comments below. I take it that this (in combination with your review on 1/2) means you concur with my speculated purpose of the mystery bit. If so, I'd like to rephrase the above paragraph in the commit message to: """ The new comments and function name are not from any official source, but are updated to mirror how the Linux kernel sources treat this mystery magic bit. This also reflects what's been observed on actual hardware: SRAM-D is inaccessible by the CPU when the bit is set, and the MUSB unit crashes when this bit is cleared while USB is in use, leaving behind debris in SRAM-D from its use as a "scratch space." """ Does this accurately reflect what you've seen, particularly (especially) that last line, or should I end the commentary at "is in use."? > I think we should use "non-net" commenting style, with the "/*" on a line > on its own. This seems to be an obscure term of art, and searching "non-net comment" and "non-net style" on Google isn't finding me any style guide or set of rules to check against. (Amusingly: if I search for the "net" style, I get a lot of .NET suggestions.) The main thing I'm trying to figure out is if it also demands */ on its own line, which I would intuitively think makes sense (it does look better to me that way), but I'm unsure if your lack of critique at the closing side of my multiline comments means you would prefer: /* * A block of text that's long enough to become a * multiline comment and ends up looking like this */ Thanks for your quick and thorough feedback, Sam