From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 41847330650 for ; Thu, 22 Jan 2026 14:39:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769092780; cv=none; b=hB39sAAf+wJd8j3M6cnnrCUdJkknfD+83HKp7mHz0Vft81aXugxJnpvR4OMuucpR7S0CeMGxpLtSn9Ps1DvnemLmMSAOiwE53nrl3/Vqa9W7h0KCnuwb+tJCtm4vJe/RzEM5XRfIBM0JrAHQotEPpN8sc6QFLAuIUZb6wwzLs/o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769092780; c=relaxed/simple; bh=AyBx9ppTx2BOTSfVtDmCqmRyEQ5NyXpywR5T7qhsqCk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZrGFs6XEsWIWro6WCiAOm9KKduau6i35Ih8QcWVqQqLQ4mOGRFXYUROP4H9qMeqMBpwxjWQmNk0IQiqNknaqMqThoovgLdR0oaB3YhKA+wLKNsNV3SxRBlbwXR9s7pHefesuaGaoCK7EtGE8a63uKhUsTuUNMajzBZMSfumchj0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TjSPSYIH; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=KPUZ9xPj; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TjSPSYIH"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="KPUZ9xPj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769092778; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=AczRkdluSYBOb5Po7BaEkCw/6UsPxAzciCTctPOT6H8=; b=TjSPSYIHH4yVxFxP0QWkByGqymLctmswnVF3llUaTHiSxUO72HpHijqHtwOBv07CL3Xk5I KEg/fN5yBGlFiMg3L94MSfEvCUAzE265qtTJYaNKJkaCfBnPMRphziYGWNs1x31P/iF4Hk 4osXMPKYjBgkDXxVzGv07caEZYGBwFE= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-669-nQ6dzrQ5NKy_r9SZpp5IPQ-1; Thu, 22 Jan 2026 09:39:36 -0500 X-MC-Unique: nQ6dzrQ5NKy_r9SZpp5IPQ-1 X-Mimecast-MFC-AGG-ID: nQ6dzrQ5NKy_r9SZpp5IPQ_1769092776 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4801e9e7159so11093825e9.1 for ; Thu, 22 Jan 2026 06:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1769092775; x=1769697575; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=AczRkdluSYBOb5Po7BaEkCw/6UsPxAzciCTctPOT6H8=; b=KPUZ9xPjAls+M+TsDjS85T0+OPCLVHQlqfgSluR/1rPjx8i5Otps+dvdSptbh2eAS3 7OFOaM1f06KA4isS05QEGOP5VvITrR4C9nCdBXiLDJxxWulNJXW7uCt/dQ+HmB79wv9M Rxjs/hWFa2DM1idkmzUyuWFeDrLIzppr2lzvdVm7O6w/3urPxANLTaKe8NKLL9MlIyiJ h0SYDLhiWm5qG2Udy3ltkqDgFI16eSbmFCT3VmJUcSulTmzQbvKaGUlIttf+toqVnIyQ 39zsWyBgqtQr5LNTwgFcOFMn3p681sDQFPYAYKLtn43i7fd1SkTue0fOkU8NYrdRmJ27 hsuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769092775; x=1769697575; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AczRkdluSYBOb5Po7BaEkCw/6UsPxAzciCTctPOT6H8=; b=ovR0rrMG265rjoMCa8H/XDTEeoe/ZQtqyhj/LrLMoOuzPXHIJ4XNvpxNiIAh1fk6IZ fBQDq8/t6X/vYpN9b82ExZQQNopXl+2oKLyk+cBAEIX1vwQoQT34W6YyPjDKysgmmQQa F/I/l8v5nQxPf9d22TI2Ek5cnFn5NlAABKXF4qzO3j9B1Ymgz+ivXdauSFFtRlUs2OeG g/DpOVG4lw1q2X0xxFzSXGgAaYEJyTWpEzfnXForaKsXFz5CPFyYGeSh3R8mksfgeEHf v+Y4gj+9LfMOvYKWma3zDC5Ayd0Y61K/Vjvc1XawiZPKcEf8YcU3PidN63oZcn3evnwK IuOg== X-Forwarded-Encrypted: i=1; AJvYcCUj/DJ4rh53rTyKP9Lj1a25DEfS/7sVz7xHl+QBpHatPzN7UpGpqQos7pkU79qGjhcU3zENd21fcDFTKuY=@vger.kernel.org X-Gm-Message-State: AOJu0Yy23KnF1UDD5B+KhLI474wlsipU2dBBMaOSlVA1zdhVoNAV4qGT 71zG9kqFEXhrEBfmB34m1XGYuZppB2gRUPWseKZlhO8lzwrfHHz9xwMS7T4PUPJovXmjN7sRycv szhnjlLgE6phFvnM4U0RiQ6U4WfMS3LNJKsmRkasIiBr4vvYUsFG+Ik5yDnSHXiKtVMyQcpoM7Q == X-Gm-Gg: AZuq6aKBlws3TfVm4k76rHB4kVXZ4Uh/B6Qtzl0FiKr9BxKW0cbYFdBbZodwM1fFLV4 vUuR7n/L5PQWxPxgZylcCl36xvw8KXMwiowDS/gvippYM+1dJPEAF9vOA1sLpJNmtp9PqUSgkBn w1JSj6bzt6Q6+dHmPOMT9S1a6JavGowOFJ/ugznNt7JTY1vKs4ya5B/cTAdZI69ORRIt3MZQyKr Bc4FEnWtOJCeua/3TdzYD4Q6wl1KSPop/nNhVZG0/w4QJjTpaCKVJxEfszVPlN0C0lLWe7ZaAXA P0twyZhEcRi7xhxIsLkkSRFvD0Nuww3d7HQ13b2Ll7wad0Ukmy7NVgZy9ItMFQ== X-Received: by 2002:a05:600c:6388:b0:477:9a28:b0a4 with SMTP id 5b1f17b1804b1-4803e713cc2mr134482995e9.0.1769092775249; Thu, 22 Jan 2026 06:39:35 -0800 (PST) X-Received: by 2002:a05:600c:6388:b0:477:9a28:b0a4 with SMTP id 5b1f17b1804b1-4803e713cc2mr134482615e9.0.1769092774800; Thu, 22 Jan 2026 06:39:34 -0800 (PST) Received: from localhost ([2a01:e0a:b25:f902::ff]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804704b712sm69536185e9.8.2026.01.22.06.39.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 06:39:34 -0800 (PST) Date: Thu, 22 Jan 2026 15:39:33 +0100 From: Maxime Ripard To: Linus Torvalds Cc: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org, Michal Wilczynski , Richard Genoud Subject: Re: [GIT PULL] pwm: Two fixes and a maintainer update Message-ID: <20260122-bold-sticky-wapiti-1dffa2@houat> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="tviorlllw7c6qgpe" Content-Disposition: inline In-Reply-To: --tviorlllw7c6qgpe Content-Type: text/plain; protected-headers=v1; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [GIT PULL] pwm: Two fixes and a maintainer update MIME-Version: 1.0 Hi, Going a bit off topic here, sorry. On Tue, Jan 20, 2026 at 10:11:27AM -0800, Linus Torvalds wrote: > On Tue, 20 Jan 2026 at 01:32, Uwe Kleine-K=F6nig > wrote: > > > > You might argue that this is an ABI change [..] >=20 > Pretty much any change can be an ABI change - even totally new > interfaces change behavior in that something that didn't use to do > anything now does something. >=20 > And we've actually very much have had things like that happen too, > when broken user space did something odd, and adding a completely new > file in /proc (or something like that) just broke broken user space. >=20 > And any bugfix that changes visible behavior is also an "ABI change", > and so there is no practical meaning to the whole otion. >=20 > So I absolutely detest the whole notion of "ABI changes". It's a > meaningless concept, and I hate it with a passion, because it then > results in the "opposite" situation where some projects seem to think > that ABI changes are perfectly fine as long as they go along with > version number changes. >=20 > The Linux rule for regressions is basically based on the philosophical > question of "If a tree falls in the forest, and nobody is around to > hear it, does it make a sound?". >=20 > So the only thing that matters is if something breaks user-*conscious* be= havior. >=20 > And when that happens, the distinction between "bug fix" and "new > feature" and "ABI change" matters not one whit, and the change needs > to be done differently. >=20 > Anyway, I agree that the whole "return proper -EFAULT on user copy > failures" is clearly the right thing to do, and I do not disagree with > the patch at all. >=20 > I just wanted to point out that the argument about whether it's an ABI > change or not is irrelevant. If it turns out that some program - not a > test script, but something with relevance to conscious user > expectations - depended on the old broken behavior, then it needs to > be done some other way. >=20 > So whether somebody "argues" that the change is an ABI change or not > is simply not relevant to anything. >=20 > Obviously some changes are more likely to be user-visible than others, > so people should take that into account in how careful you need to be > about a patch. Where do we draw the line then, if there's any? I have a particular example in mind with v4l2. With some drivers, and because pixel order naming is confusing and inconsistent in the media industry as a whole, we ended up with drivers capturing framebuffers with the wrong pixel order (blue and red inverted) compared to documented order for the format they were requesting. And rejecting the format with the "right" order. We've been tip-toeing about this to fix it in order to avoid any regression in some tools. Should we just consider those drivers "wrong", treat it as a bugfix, and expect userspace applications to request the format they actually rely on? Or should we continue what we've tried to do and try to support the right format, and the old format for backward compatibility? Thanks! Maxime --tviorlllw7c6qgpe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCaXI2ngAKCRAnX84Zoj2+ dgJ7AYDpbQJxEMpzWS8HBtJ8aMqO/SOUizvQJyLMA2h9iEHAeYvCFgPMXEGbiBmQ fIcsr+4Bf39X6wSz5IqJRFOuob8+hzIldI2nbbd9973I69pvV5eiv21BytycP/Is LQove+Vwug== =LsnN -----END PGP SIGNATURE----- --tviorlllw7c6qgpe--