From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH 2/3] lx6464es: dump MAC in standard form Date: Wed, 29 May 2013 14:15:47 +0200 Message-ID: References: <1369821802-2308-1-git-send-email-andriy.shevchenko@linux.intel.com> <1369821802-2308-2-git-send-email-andriy.shevchenko@linux.intel.com> <1369825257.29283.229.camel@smile> <1369827067.29283.237.camel@smile> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 801BA261AE8 for ; Wed, 29 May 2013 14:15:07 +0200 (CEST) In-Reply-To: <1369827067.29283.237.camel@smile> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Andy Shevchenko Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Wed, 29 May 2013 14:31:07 +0300, Andy Shevchenko wrote: > > On Wed, 2013-05-29 at 13:03 +0200, Takashi Iwai wrote: > > > > > > - sprintf(card->shortname, "LX6464ES %02X.%02X.%02X.%02X.%02X.%02X", > > > > > - chip->mac_address[0], chip->mac_address[1], chip->mac_address[2], > > > > > - chip->mac_address[3], chip->mac_address[4], chip->mac_address[5]); > > > > > + sprintf(card->shortname, "LX6464ES %pM", chip->mac_address); > > > > > > > > This will change from the upper to the lower case, thus it'll lead to > > > > an incompatible name string, unfortunately. > > > > > > Who is the user of this string? > > > > It's exposed to the user-space via ioctl and it can be used as an id > > string. So this will break user-space compatibility. > > MAC is theoretically set of arbitrary 6 bytes. > Only what I can see here is the difference between '.' and ':' as a > delimiter. But the MAC address form is defined in IEEE 802 standards. It doesn't matter whether it's a valid MAC representation or not. The problem is only that this patch will change the string representation, thus it becomes incompatible with older kernels. That's the only point. > Anyway, I am okay if you reject this one. Good :) thanks, Takashi > -- > Andy Shevchenko > Intel Finland Oy >