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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CF6FDC3DA6E for ; Fri, 5 Jan 2024 10:23:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2fi9LCKt9PW40XHdIQKyODILQL0ULCjm3TrRZZAetvQ=; b=SqMRLxMBSHfWZK OSdyTU+g3Dw/eK8jSjPciJSteBhwVytrLLM7LobvUQGvifDHd13P8oym++LgzoBfiZj5+cILMwssB NtQpLi7EXz8OeAAiFPIf9tQz5KgP0rSgJAUZ9k+2rUNTt+V/3mvhZMHsIMAL771iKFjMnKz0WDu8u 8r1X/c4iXLTgbKtg9VJMd4/AYiskvjwNMgfPDKHOdoJQTWkDkqFuwhCiPl330EAQ1mHMtV8NHr3jT a688lRCxo2gkMlyYWm+s+Hs/VtC1IYZnyGgKJPig53ap+uiiEHdTDq7oaFXTHG0BSZq04S7E1GZzQ nkToeRhX16jen9EjDDdQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rLhLr-00GW76-0d; Fri, 05 Jan 2024 10:22:55 +0000 Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rLhLn-00GW6k-2T for linux-arm-kernel@lists.infradead.org; Fri, 05 Jan 2024 10:22:53 +0000 Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2cc7d2c1ff0so16891551fa.3 for ; Fri, 05 Jan 2024 02:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1704450169; x=1705054969; darn=lists.infradead.org; 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=Otn9loBBsw/UzqwebEZy3Ooa0CujzEAcJwFz8Zj1BXs=; b=gSOIZ/weXkUPdfRPTfQvgcmNxTFkpd+rs5PoUmnYGHGJr1ECjCB2IOFLYZTbyV9DQi hJAnTjpIcn/b/TCX8IgybnQicvk7mADWzfXixeq6vtvKbmhzMshZ1Me5Um0sHmIefGis csVZDNXNU9+j2bXNEvlpXZUoa70v65+yWaxUeQum9XA4ie/HB+56BSl4eCDsKNrV73nP Hz+4bZG+6j7paIHQq80aJllbFePfbSaIXQ52VE3yojxbTctH+Tnx1apsTuRvdaCvyCq7 vHeB5f6DK7RaZUWUJxaTZJ1ZbfEkkAn1cimxqUepRQxKx60AiG9YpljhRj3ezobU6Nd6 9f5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704450169; x=1705054969; 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=Otn9loBBsw/UzqwebEZy3Ooa0CujzEAcJwFz8Zj1BXs=; b=vA/X3gufmu9N2sY8DQr+2uZ82qOoYqz0YRg6VDU1qzHGIzN8m4OmYbqvpAY2GRA9Gt 5Tv8vuMMI3D8DX4RLaruI7AJP3mCH8mNqPFubms7mAY7aen0EDf0reZbMjC8jmaBluNd /FhKhdo5T0mZF2JF/FwUr1Yh/a+T+318m/uUPSEPyIRkI6PKdderKuPuCD0dFLGjTQBx PWm6ZS4JH8zmnaElkhd1/CMu4OimWgfp193cH1cKjkwA3zltJRsVxkNeuLGg2o6+25fN g4WOXpe9nq1phOxLTQqe+DPyzvjVCN3CO8ksJa1IyLZGDmy+X3EUDHkPy7JG71O6yYPB MT6A== X-Gm-Message-State: AOJu0YzYz9rRvyoJfXqT66S5enK0XGS2SiNAwUEVaJeX35AZJShATPRX zy6Rb2M7WZsN+WO+ShRROHqvdYuZ3fUcTZpxHrvZtxYC6SY= X-Google-Smtp-Source: AGHT+IE2UecOtUprnsE+wTP7UJCkRZPB7fx0sJ/qDDVGHx8WV3NGtKzjOZu+swh/2+L77+HG7FmkwQ== X-Received: by 2002:a2e:a9a2:0:b0:2cc:6bf6:cdc6 with SMTP id x34-20020a2ea9a2000000b002cc6bf6cdc6mr1295046ljq.7.1704450169091; Fri, 05 Jan 2024 02:22:49 -0800 (PST) Received: from [192.168.2.107] ([79.115.63.202]) by smtp.gmail.com with ESMTPSA id ek21-20020a056402371500b0055732bd1fc0sm474638edb.82.2024.01.05.02.22.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Jan 2024 02:22:48 -0800 (PST) Message-ID: <19746c85-6eff-4f63-9370-9592ad73f22c@linaro.org> Date: Fri, 5 Jan 2024 10:22:46 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 04/12] tty: serial: samsung: prepare for different IO types Content-Language: en-US To: Greg KH Cc: peter.griffin@linaro.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, mturquette@baylibre.com, sboyd@kernel.org, conor+dt@kernel.org, andi.shyti@kernel.org, alim.akhtar@samsung.com, jirislaby@kernel.org, s.nawrocki@samsung.com, tomasz.figa@gmail.com, cw00.choi@samsung.com, arnd@arndb.de, semen.protsenko@linaro.org, andre.draszik@linaro.org, saravanak@google.com, willmcvicker@google.com, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, linux-serial@vger.kernel.org, kernel-team@android.com References: <20231228125805.661725-1-tudor.ambarus@linaro.org> <20231228125805.661725-5-tudor.ambarus@linaro.org> <2024010432-taco-moneyless-53e2@gregkh> <2024010450-heritage-variety-d72d@gregkh> From: Tudor Ambarus In-Reply-To: <2024010450-heritage-variety-d72d@gregkh> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240105_022251_815444_EA6CA51D X-CRM114-Status: GOOD ( 24.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 1/4/24 15:56, Greg KH wrote: > On Thu, Jan 04, 2024 at 03:41:28PM +0000, Tudor Ambarus wrote: >> >> >> On 1/4/24 15:32, Greg KH wrote: >>> On Thu, Dec 28, 2023 at 12:57:57PM +0000, Tudor Ambarus wrote: >>>> GS101's Connectivity Peripheral blocks (peric0/1 blocks) which >>>> include the I3C and USI (I2C, SPI, UART) only allow 32-bit >>>> register accesses. If using 8-bit register accesses, a SError >>>> Interrupt is raised causing the system unusable. >>>> >>>> Instead of specifying the reg-io-width = 4 everywhere, for each node, >>>> the requirement should be deduced from the compatible. >>>> >>>> Prepare the samsung tty driver to allow IO types different than >>>> UPIO_MEM. ``struct uart_port::iotype`` is an unsigned char where all >>>> its 8 bits are exposed to uapi. We can't make NULL checks on it to >>>> verify if it's set, thus always set it from the driver's data. >>>> >>>> Signed-off-by: Tudor Ambarus >>>> --- >>>> v2: new patch >>>> >>>> drivers/tty/serial/samsung_tty.c | 9 ++++++++- >>>> 1 file changed, 8 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c >>>> index 66bd6c090ace..97ce4b2424af 100644 >>>> --- a/drivers/tty/serial/samsung_tty.c >>>> +++ b/drivers/tty/serial/samsung_tty.c >>>> @@ -72,6 +72,7 @@ struct s3c24xx_uart_info { >>>> const char *name; >>>> enum s3c24xx_port_type type; >>>> unsigned int port_type; >>>> + unsigned char iotype; >>>> unsigned int fifosize; >>>> unsigned long rx_fifomask; >>>> unsigned long rx_fifoshift; >>> >>> Is there a reason you are trying to add unused memory spaces to this >>> structure for no valid reason? I don't think you could have picked a >>> more incorrect place in there to add this :) >>> >>> Please fix. >>> >> >> Will put it after "const char *name". > > If you do, spend some time with the tool, pahole, and see if that's > really the best place for it or not. Might be, might not be, but you > should verify it please. > Thanks! I played with pahole a bit. For arm32 this struct is not as bad defined as for arm64, all members fit in the same cacheline. There are some holes though and 2 cachelines for arm64 where this struct needs some love. The best and minimum invasive change for my iotype member would be to put it before the "has_divslot" member, as the has_divslot bitfield will be combined with the previous field. But I think the entire struct has to be reworked and the driver butchered a bit so that we get to a better memory footprint and a single cacheline. I volunteer to do this in a separate patch set so that we don't block this series. I think the final struct can look as following: struct s3c24xx_uart_info { const char * name; /* 0 8 */ enum s3c24xx_port_type type; /* 8 4 */ unsigned int port_type; /* 12 4 */ unsigned int fifosize; /* 16 4 */ u32 rx_fifomask; /* 20 4 */ u32 rx_fifoshift; /* 24 4 */ u32 rx_fifofull; /* 28 4 */ u32 tx_fifomask; /* 32 4 */ u32 tx_fifoshift; /* 36 4 */ u32 tx_fifofull; /* 40 4 */ u32 clksel_mask; /* 44 4 */ u32 clksel_shift; /* 48 4 */ u32 ucon_mask; /* 52 4 */ u8 def_clk_sel; /* 56 1 */ u8 num_clks; /* 57 1 */ u8 iotype; /* 58 1 */ u8 has_divslot:1; /* 59: 0 1 */ /* size: 64, cachelines: 1, members: 17 */ /* padding: 4 */ /* bit_padding: 7 bits */ }; This looks a lot better than what we have now: /* size: 120, cachelines: 2, members: 17 */ /* sum members: 105, holes: 2, sum holes: 8 */ /* sum bitfield members: 1 bits (0 bytes) */ /* padding: 4 */ /* bit_padding: 23 bits */ /* last cacheline: 56 bytes */ I'll put iotype before has_divslot and then follow up with a patch set to clean the driver. Cheers, ta _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel