linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Akhil Goyal <akhil.goyal@freescale.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: <arnd@arndb.de>, <lars@metafoo.de>, <robin.getz@analog.com>,
	<Michael.Hennerich@analog.com>, <lars-peter.clausen@analog.com>,
	<linux-kernel@vger.kernel.org>, <pankaj.chauhan@freescale.com>
Subject: Re: [PATCH v2 0/4] Radio device framework
Date: Mon, 5 Aug 2013 16:48:57 +0530	[thread overview]
Message-ID: <51FF8A21.7020508@freescale.com> (raw)
In-Reply-To: <20130711042210.GA23660@kroah.com>

On 7/11/2013 9:52 AM, Greg KH wrote:
> On Thu, Jul 11, 2013 at 09:29:49AM +0530, Akhil Goyal wrote:
>> On 7/8/2013 3:19 PM, akhil.goyal@freescale.com wrote:
>>> From: Akhil Goyal<akhil.goyal@freescale.com>
>>>
>>> RF signal path is integral part of any system that transmits/receives RF
>>> (radio frequency) signals. In these systems Data is processed/converted
>>> to IQ samples (digital representation a RF signal) and passed to a RFIC
>>> (RF PHY) which converts the digital RF signal (IQ samples) to analog and
>>> transmits over antenna.
>>>
>>> Typically The signal path consists of multiple components:
>>>
>>> Antenna controller<->   vector signal processors<->   RFIC<->   Antenna
>>>
>>> Each of these components have specific functionalities:
>>>
>>> 1. Antenna controller: Framing of digital IQ data into protocol specific frames.
>>> 2. vector signal processors: For conditioning of signal.
>>> 3. RFIC : converts digital IQ data to analog signal which is transmitted/received on/from Air.
>>>
>>> Also it is desirable to control the complete signal path, for example:
>>> bringing the complete signal path up/down etc.
>>>
>>> The radio device framework introduces a way to accommodate the RF signal
>>> paths.  One signal path is represented as a RF device (rf0, rf1 etc), and
>>> it can contain multiple components which have their individual vendor
>>> specific drivers. The framework provides mechanism by which individual
>>> components can register with RF framework, and the framework will handle the binding
>>> of individual component devices to a RF device. RF device exports the control
>>> interfaces to user space, and this user space interface is independent of
>>> component (vendor specific) drivers.
>>>
>>> This patch set include
>>> 1. RF Interface: Independent of phy or antenna controller.
>>> 2. AIC driver: Antenna interface Controller(AIC) of Hetrogenous SOC's
>>> like BSC9131, BSC9132
>>> 4. Device tree bindings for AIC.
>>> 5. Device tree changes for BSC9131-AIC
>>>
>>> changes in v2:
>>> 1. incorporated comments for handling pointers in user space API structures.
>>> 2. Removed patches for AD9361 phy driver. It shall be sent once a proper
>>> driver is in place for AD9361 chip
>>> 3. Removed Device tree nodes/bindings for AD9361
>>> 4. Incorporated comments for proper handling of wait_events
>>> 5. Added Documentation for IOCTL APIs and the structures used.
>>> 6. Inserted paddings in user space structures.
>>> 7. Reorganized code for rfdev.c to remove forward declaration and broke the
>>> rf_ioctl() function to handle local structures correctly.
>>> 8. Corrected the error handling for mutex used.
>>>
>>
>> Hi Arnd/Greg,
>>
>> It has been 3-4 days for this patch set and there are no review
>> comments on these patches. Please suggest a way forward for the
>> patch set. I have incorporated all the review comments for v1.
>
> We are thick in the middle of the merge window for 3.11-rc1 and have
> _no_ time for reviewing anything new, please give us a chance to catch
> up with our existing work before asking about new stuff that is not
> going to happen until 3.12 at the earliest.
>
> In sort, patience please.
>
Hi Greg,

I could see some patches for 3.12 on the mailing list. Shall I resend 
the patches on the list or is it still on your TODO list.

-Akhil



      reply	other threads:[~2013-08-05 11:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-08  9:49 [PATCH v2 0/4] Radio device framework akhil.goyal
2013-07-08  9:49 ` [PATCH v2 1/4] drivers/misc: Support for RF interface " akhil.goyal
2013-07-08  9:50   ` [PATCH v2 2/4] drivers/misc/rf: AIC: Freescale Antenna Interface controller driver akhil.goyal
2013-07-08  9:50     ` [PATCH v2 3/4] binding: Add device tree bindings for freescale AIC akhil.goyal
2013-07-08  9:50       ` [PATCH v2 4/4] BSC9131rdb/dts: Add nodes for supporting AIC akhil.goyal
2013-07-11  3:59 ` [PATCH v2 0/4] Radio device framework Akhil Goyal
2013-07-11  4:22   ` Greg KH
2013-08-05 11:18     ` Akhil Goyal [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51FF8A21.7020508@freescale.com \
    --to=akhil.goyal@freescale.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=lars-peter.clausen@analog.com \
    --cc=lars@metafoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pankaj.chauhan@freescale.com \
    --cc=robin.getz@analog.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).