From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 BC4512566C3; Mon, 24 Feb 2025 10:41:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740393670; cv=none; b=GDQwPmlPl1et6J/sfo5jJD1l/f2Lk9cJ7t64alKUAKWXN0U+90Xo+ZmwMv/t1dVYbIKlNojKwXkTeCLKgNw5PirTP8O9dLtsPHtJ1gygP6bNeuUWLCYwC4x7XFnxwKy7s8KNjKZlbZbTjpthndO8fUcfTNqbKlrxgnC4HUwMu58= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740393670; c=relaxed/simple; bh=NeAGyiZOTYfejHkjFw04X6rdOVkivoeAsk4c/Mc/y2w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iHLZZrDHKaMnXMGxnvi9Cf42GtmQZX604qdgsVXkM3YDttvjQxD7QlXBIy5Ev+vjdcclUVF8aI+EKik5DuYPtfDrqr5zR4CbDcvSEVz5qLOIrQB3UwIpe3AnXMVkobF/Fr2tFqmWUwt76JEdwIvkjpL9Wu14K95UXVUdvAz4Nl4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=lUtbff7j; arc=none smtp.client-ip=192.198.163.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="lUtbff7j" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1740393668; x=1771929668; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=NeAGyiZOTYfejHkjFw04X6rdOVkivoeAsk4c/Mc/y2w=; b=lUtbff7jg62FH8P2+VBPUChMvf3LwXff0k7wSB+U0/qxb5ARNPS7Dqu8 5sOe+dl0Sh04BieJwDGUOnQf/9LobfyciOudHL6pOhn5JzPZJXjrLBk94 GO/N2Pcm09L7ZPcPkujtidqYrdyXA6bYwtY7CQPbLU/wL92dMukruRujp IQ7+h3lKjMRU+b8QrroUbzb17NVETq6vg8u/Vpwe0ZKmdN2oy/popmf2o HNZfq0XQP8+yuQBwaos/gDLRrvqDwO8KM97llalgBNiU3Uri6Vf83rDZQ WfCVcg5cgBuAK5fwnNXZBeyjgTrvfXqv53NeAy+xw7QhovUiONHMZ2yvf w==; X-CSE-ConnectionGUID: BOCiEdzGRLO1yZUUHWFMbw== X-CSE-MsgGUID: ZDvuUXGlQYe4I46TgJORcA== X-IronPort-AV: E=McAfee;i="6700,10204,11354"; a="51781404" X-IronPort-AV: E=Sophos;i="6.13,309,1732608000"; d="scan'208";a="51781404" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Feb 2025 02:41:07 -0800 X-CSE-ConnectionGUID: 6KaaqqqiSfyRszbE2a4Y5A== X-CSE-MsgGUID: Yabe8xd7SOilahRgO+AwGQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,309,1732608000"; d="scan'208";a="121107100" Received: from smile.fi.intel.com ([10.237.72.58]) by fmviesa004.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Feb 2025 02:41:01 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1tmVtP-0000000EfTz-3Zey; Mon, 24 Feb 2025 12:40:55 +0200 Date: Mon, 24 Feb 2025 12:40:55 +0200 From: "andriy.shevchenko@linux.intel.com" To: Aditya Garg Cc: "pmladek@suse.com" , "rostedt@goodmis.org" , "linux@rasmusvillemoes.dk" , "senozhatsky@chromium.org" , "corbet@lwn.net" , "maarten.lankhorst@linux.intel.com" , "mripard@kernel.org" , "tzimmermann@suse.de" , "airlied@gmail.com" , "simona@ffwll.ch" , "akpm@linux-foundation.org" , "apw@canonical.com" , "joe@perches.com" , "dwaipayanray1@gmail.com" , "lukas.bulwahn@gmail.com" , "sumit.semwal@linaro.org" , "christian.koenig@amd.com" , "kekrby@gmail.com" , "admin@kodeit.net" , Orlando Chamberlain , "evepolonium@gmail.com" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linux-media@vger.kernel.org" , "linaro-mm-sig@lists.linaro.org" , Hector Martin , "linux@armlinux.org.uk" , "asahi@lists.linux.dev" , Sven Peter , Janne Grunau Subject: Re: [PATCH v2 2/3] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc Message-ID: References: <716BCB0A-785B-463A-86C2-94BD66D5D22E@live.com> <6CB20172-906F-4D13-B5E4-100A9CF74F02@live.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo On Mon, Feb 24, 2025 at 10:32:27AM +0000, Aditya Garg wrote: > > On 24 Feb 2025, at 3:54 PM, andriy.shevchenko@linux.intel.com wrote: > > On Mon, Feb 24, 2025 at 10:18:48AM +0000, Aditya Garg wrote: > >>>> On 24 Feb 2025, at 3:28 PM, andriy.shevchenko@linux.intel.com wrote: > >>> On Sat, Feb 22, 2025 at 03:46:03PM +0000, Aditya Garg wrote: > >>>>>> On 20 Feb 2025, at 10:09 PM, Aditya Garg wrote: ... > >>>>> %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but > >>>>> it's useful to be able to print generic 4-character codes formatted as > >>>>> an integer. Extend it to add format specifiers for printing generic > >>>>> 32-bit FOURCCs with various endian semantics: > >>>>> > >>>>> %p4ch Host-endian > >>>>> %p4cl Little-endian > >>>>> %p4cb Big-endian > >>>>> %p4cr Reverse-endian > >>>>> > >>>>> The endianness determines how bytes are interpreted as a u32, and the > >>>>> FOURCC is then always printed MSByte-first (this is the opposite of > >>>>> V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would > >>>>> allow printing LSByte-first FOURCCs stored in host endian order > >>>>> (other than the hex form being in character order, not the integer > >>>>> value). > >>> > >>> ... > >>> > >>>> BTW, after looking at the comments by Martin [1], its actually better to use > >>>> existing specifiers for the appletbdrm driver. The driver needs the host > >>>> endian as proposed by this patch, so instead of that, we can use %.4s > >>> > >>> Do you mean this patch will not be needed? If this a case, that would be the > >>> best solution. > >> > >> I tested with %4pE, and the results are different from expected. So this > >> would be preferred. Kindly see my latest email with a proposed workaround for > >> the sparse warnings. > > > > %.4s sounded okay, but %4pE is always about escaping and the result may occupy > > %4x memory (octal escaping of non-printable characters). Of course, you may vary > > the escaping classes, but IIRC the octal or hex escaping is unconditional. > > %.4s is used for unsigned int iirc, here it's __le32. No, it's used to 'char *'. in case one may guarantee that it at least is four characters long. > >>>> [1]: https://lore.kernel.org/asahi/E753B391-D2CB-4213-AF82-678ADD5A7644@cutebit.org/ > >>>> > >>>> Alternatively we could add a host endian only. Other endians are not really > >>>> used by any driver AFAIK. The host endian is being used by appletbdrm and > >>>> Asahi Linux’ SMC driver only. -- With Best Regards, Andy Shevchenko