From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753078AbcBOMOT (ORCPT ); Mon, 15 Feb 2016 07:14:19 -0500 Received: from foss.arm.com ([217.140.101.70]:44823 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753010AbcBOMOR (ORCPT ); Mon, 15 Feb 2016 07:14:17 -0500 Subject: Re: [PATCH 0/4] mailbox: mailbox-test: support single channel with separate Tx and Rx buffer To: Lee Jones References: <1455210808-29395-1-git-send-email-sudeep.holla@arm.com> <20160212091718.GT20693@x1> <56BDA8E3.8060800@arm.com> Cc: Sudeep Holla , Jassi Brar , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org From: Sudeep Holla Organization: ARM Message-ID: <56C1C116.2060702@arm.com> Date: Mon, 15 Feb 2016 12:14:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BDA8E3.8060800@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Lee, On 12/02/16 09:41, Sudeep Holla wrote: > > > On 12/02/16 09:17, Lee Jones wrote: >> On Thu, 11 Feb 2016, Sudeep Holla wrote: >> >>> Hi Lee, Jassi, >>> >>> Assuming mailbox-test was designed to be generic, I am trying to extend >>> it to support single channel with separate Tx and Rx buffer. With these >>> changes I am able to test arm_mhu driver. However I couldn't understand >>> the intention of converting buffer to ASCII hex dump in read method. >>> I have a local change to remove that so that it can deal with any data >>> in any format(e.g. some protocol format) >> >> Not sure quite what you mean. Hexdump can handle any data? If the >> hex value read isn't an ASCII value, a '.' is printed on the right >> hand side. What data are you expecting that you can't analyse with >> hexdump? >> > > Sorry for not being clear. Hexdump can handle any data. I do see that > it displays quite nicely at the driver level which is nice. > > However my question was why is the the buffer copied to user space is > not the original raw data, rather it's ASCII converted which is good for > nice logging. > > One of the use-case the testing guys wants is the check the protocol > specification using this. In their case they expect the test driver to > send the raw data as is from the driver rather than the converted ASCII > buffer. I tend to agree with them for 2 reasons: > > 1. userspace can do the conversion if required > 2. the input buffer is not converted(i.e. in the write path), so it's > bit of inconsistent there. > Thoughts on this or am I still not clear ? -- Regards, Sudeep