Message-ID: <20130711042210.GA23660@kroah.com>
Date:	Wed, 10 Jul 2013 21:22:10 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Akhil Goyal <akhil.goyal@...escale.com>
Cc:	arnd@...db.de, lars@...afoo.de, robin.getz@...log.com,
	Michael.Hennerich@...log.com, lars-peter.clausen@...log.com,
	linux-kernel@...r.kernel.org, pankaj.chauhan@...escale.com
Subject: Re: [PATCH v2 0/4] Radio device framework

On Thu, Jul 11, 2013 at 09:29:49AM +0530, Akhil Goyal wrote:
> On 7/8/2013 3:19 PM, akhil.goyal@...escale.com wrote:
> >From: Akhil Goyal<akhil.goyal@...escale.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.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists