From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 71DC83C5DBE for ; Thu, 9 Jul 2026 21:46:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783633568; cv=none; b=UYLxK1mh3T6VxobJqChaEM36PGOB5AGRjdBHho4k9sg2/E5vxMbL8UxQSN9mmZPYQtvLzP8eSIsEbiQFKJ0yECc5atwGdPOUw5OtR1OS3i4q55R6S+ITonGrEl5P6yrDHglm/ZG2uLeIdVCwckfY5uio1n2GyGRrzZa87DflIok= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783633568; c=relaxed/simple; bh=MXG6F+XOaJjTHz4SHrXau2henaRyFb9pRMsdcqxvSUQ=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qlYumlB+QYUxqxquJdB3I/3f4NEebhtlcLFvfcgBpCsgcZGd+t9LWOAAabyV+nVIgbDa0OSsbOf6TMXxnSeFK52ZKyuCugndy0rE58KMRcupbWiX2Q3Yz1MDToU6SYgqYUq5QabskXnj+8SlcSrU39n2gJ4woTA7WF1eM+mV1+s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=VMPFIP5V; arc=none smtp.client-ip=209.85.221.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="VMPFIP5V" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-472326ca506so231191f8f.2 for ; Thu, 09 Jul 2026 14:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783633566; x=1784238366; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:subject:cc:to:from:date:message-id:from:to:cc:subject :date:message-id:reply-to:content-type; bh=VkbACm5M+XrCUV3Z7NNaW5IbCVSb/enbC9nT9Rpc0jM=; b=VMPFIP5VmYlPsYdxH/RzSJ6YIXQzfqwwW4TxGyWMyNeZJmO8ZBRMeZAfUmud4k3ZUU cmrDSyB5V1N8jey9jGLTwytFgVx0mzGCAuxjMfbsTjC5XITv0HadgKAdwgr1fGNtXE+f dABxE6ik17BUHEPzQTfon56MxZsKBWFr9NXRZP310hRtR9kwsF6vZR+YSwdAK37qcp1t 7SnqFISUE5EAfyIET7Xb9vDHYBwETw9iHVil+492YuKakTW5Cg7qA3KGbpe/Qjfme1+a GgZN1BracjpPpnZJwiimk/gkL03jSUxdHwZLnHLD3qqL/U8jccLENEbyEHeBFLFeltmP IUXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783633566; x=1784238366; h=in-reply-to:content-disposition:content-type:mime-version :references:subject:cc:to:from:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=VkbACm5M+XrCUV3Z7NNaW5IbCVSb/enbC9nT9Rpc0jM=; b=ezkiwjYojeiL7VxfBYx8ZNDesOtFAJDVFBB3n8O/GRVF8cUQzPK9k053Kvjwvsj8Ys ugZMWI7C4SGqvE+eExffyMQH1MAivFBem4RM6LnYGi/aih2z2OyABbFBqv/157I4zhyX S/qA/I6pqo5LfbtyjO6/4zKrnTbSHOl2kL4WJnAy1jpk2m5yoDKCCRDWvsKmoB8sQeMw rsOgc63/BIgi7gvQMAeeMQlVYbNNyk52KbkvBp+OKQ46WHc3wetnOD5Hwz1bMs3HFZ0u i+t/vnCSqJYscQjTCtQ6tFHfaB2lgE7iN4sJsQr6iDJTeQCbLE6urkxsMn/N1WHAF97c kNfA== X-Forwarded-Encrypted: i=1; AHgh+Royldfb9ym/vNW8IxoEdP/sPfOFXTegBkGG0v/ZQ+IntGspHLQNuq6js6bmBN5GFhLClLZFPC91/vRq7go=@vger.kernel.org X-Gm-Message-State: AOJu0Yxh9fmMCDtIAzFHm06wTv74X/1B/sKwUic+uuKuy0ElpbkrOiAd AAb+N2mWR4Oq0BIqLPN6glfcYP3ofc+ApmDx45gDDvpuKkKB4xnBy2OP X-Gm-Gg: AfdE7cmI1XJU/p4rlxwXx/Ec4rfApUAzVVc1xw70cMOHvxTKucykXE4WJXbXbZm88Vp RPof6e2DnlWvreuM9Pnm/X2oqWazVbn0RUYMzLp5xpQjtHZI5ph23lFVDdfMTVsKh2p3rm65h4x o2cQfJGwYot7nPcLMwfJRmRZqdAvU59q/7WgfiL00gxrb8PihW6jsaJfeZdPGi8m8l+dEuS2p27 SUmkdJHfOdV0e1rkYehUrq203jkNgANvehzXjisrtdomlQGk7FGo+TcryNeAhaV9+0ZLVmmpMkb b62lw+eRknVuHQicw8y3h1itqsMtC/qktSM3sLaREbv3KtdxRCC8kGk8R4uabsN8Y86/T4ZaAuM +6DJTeH+o9edtQqod2+hcD4Q69ielzoy2YbaQgEK0tegf6H7WUE9oBpcUzme6hs6+NnZ8jJ7H/v MiI5iL/tYGEG13J9ts38HWcOt18TpSruSCijqlSYLS+/Q7qtGAiP5hAL/2/MYBz0+m14q4tINZX A== X-Received: by 2002:a05:6000:2385:b0:475:f0f0:9ef0 with SMTP id ffacd0b85a97d-47df0782dfcmr9126719f8f.53.1783633565738; Thu, 09 Jul 2026 14:46:05 -0700 (PDT) Received: from Ansuel-XPS. (host-95-248-227-210.retail.telecomitalia.it. [95.248.227.210]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47a9b4d850dsm55980888f8f.0.2026.07.09.14.46.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 14:46:05 -0700 (PDT) Message-ID: <6a50169d.41a38e5f.1bb169.a6d5@mx.google.com> X-Google-Original-Message-ID: Date: Thu, 9 Jul 2026 23:46:02 +0200 From: Christian Marangi To: Andy Shevchenko Cc: Greg Kroah-Hartman , Jiri Slaby , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Benjamin Larsson , John Ogness , Marco Felsch , Gerhard Engleder , Jiaxun Yang , Randy Dunlap , Binbin Zhou , Rong Zhang , Lukas Wunner , Lubomir Rintel , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org Subject: Re: [PATCH 3/4] serial: 8250: map UAPI port type to internal enum References: <20260709205656.319531-1-ansuelsmth@gmail.com> <20260709205656.319531-4-ansuelsmth@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jul 10, 2026 at 12:37:48AM +0300, Andy Shevchenko wrote: > On Thu, Jul 09, 2026 at 10:56:51PM +0200, Christian Marangi wrote: > > There is currently some confusion when a new 8250 UART device needs to be > > defined with the related index for uart_config[] to be directly defined in > > UAPI header. > > > > There isn't any specific reason to define the index directly in UAPI header > > unless it's also needed to be defined for userspace usage. > > > > To try to address this confusion and making it clear how these specific > > index should be defined and where, create a dedicated enum in 8250.h > > with all the current defined values in UAPI header and document how these > > id should be defined. > > > > Rename the define in 8250_port.c with the new UART_ prefix. > > This will bring a wide field for the all possible conflicts and doesn't really > solve the issue. Why not simply kill the UAPI part of the definitions for good? > (Move the all, except the first 13) to be internal to the kernel. > I mean... With correct review from maintainers, conflict won't happen. I don't feel it's that easy to kill UAPI header... userspace stuff and we don't kill userspace. The previous suggested solution was to stop declaring stuff in UAPI header and start declaring in the internal header making the situation even worse and error prone with id conflict. This can really be prevent only by correct review of the change. (or keep using UAPI) Maybe other have better ideas on this. On net we have a similar problem and the implementation is mostly similar with duplicated reference and some BUILD_BUG magic. -- Ansuel