On Sat, Dec 13 2014 at 1:46:45 am GMT, Silvio Fricke silvio.fri...@gmail.com
wrote:
Hi Silvio,
I have found some dts entries which are not evaluated by the drivers. This
patch remove this entries from the dts files.
Jason has mentioned I should CC: Thomas, Marc and him self to this
mails.
On 12/12/14 18:14, Arnd Bergmann wrote:
On Friday 12 December 2014 08:53:44 Ray Jui wrote:
On 12/12/2014 4:14 AM, Arnd Bergmann wrote:
On Thursday 11 December 2014 18:36:54 Ray Jui wrote:
index 000..040bc0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@
Hi VishnuPatekar,
The patch mangling for this set seems to have gone a bit wrong I'm afraid,
a lot of the patches have my fixup commit messages (which should have
disappeared when squashing in the patches), please replace those by proper
commit messages describing what the patch actually does.
Nikolaus Schulz schrieb am 12.12.2014 um 16:58:
On Sat, Dec 06, 2014 at 12:36:19PM +0100, Hartmut Knaack wrote:
Nikolaus Schulz schrieb am 24.11.2014 um 20:50:
The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
interface.
Changes in v2:
* Use DMA-safe buffer for SPI
Hartmut Knaack schrieb am 13.12.2014 um 12:18:
Nikolaus Schulz schrieb am 12.12.2014 um 16:58:
On Sat, Dec 06, 2014 at 12:36:19PM +0100, Hartmut Knaack wrote:
Nikolaus Schulz schrieb am 24.11.2014 um 20:50:
The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
interface.
On 12/13/2014 12:18 PM, Hartmut Knaack wrote:
[...]
According to your DT bindings, the regulator from property vref-supply should
be used. This is missing here.
Uhm, it's right below, no?
Looking into your DT bindings patch (which unfortunately didn't make it into our
list), you specify
On 11/24/2014 08:50 PM, Nikolaus Schulz wrote:
[...]
+const struct iio_chan_spec dac8554_channels[] = {
static
[...]
+ ret = of_property_read_u32(spi-dev.of_node, address, addr);
This should probably have vendor prefix.
+ if (ret || addr 0 || addr 2) {
+
On 12/06/2014 12:36 PM, Hartmut Knaack wrote:
[...]
+static int dac8554_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long m)
Commonly, m
2) why is this tied to the tty core and not the serial core
if this is only for UART?
I'm a bit baffled why you would try and tie it to serial core given that
serial core only covers a random subset of the uart drivers we have. If
we have a USB connected device with USB gpio lines doing
On Fri, 12 Dec 2014 08:02:48 -0500
Which brings up another point: why not do this in the runtime power
management;
ie, turn on the slave device when the master device is turned on? Sebastian
recently made the 8250 driver power-managed per access, which would enable
significant power savings
Silvio, Marc,
On Sat, Dec 13, 2014 at 09:21:23AM +, Marc Zyngier wrote:
On Sat, Dec 13 2014 at 1:46:45 am GMT, Silvio Fricke
silvio.fri...@gmail.com wrote:
Hi Silvio,
I have found some dts entries which are not evaluated by the drivers. This
patch remove this entries from the dts
Hi,
On Fri, Dec 12, 2014 at 11:59:20AM +, Grant Likely wrote:
[...]
--- a/Documentation/devicetree/bindings/serial/of-serial.txt
+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
@@ -39,6 +39,10 @@ Optional properties:
driver is allowed to detect support for the
The patch exposes the available i2c busses on the PowerNV platform
to the kernel and implements the bus driver to support i2c and
smbus commands.
The driver uses the platform device infrastructure to probe the busses
on the platform and registers them with the i2c driver framework.
Signed-off-by:
Hi Andy,
On Wed, Dec 10, 2014 at 08:32:56PM +0200, Andy Shevchenko wrote:
On Sun, 2014-12-07 at 23:21 -0800, Dmitry Torokhov wrote:
We do not need to roll our own implementation of delayed work now that we
have proper implementation of mod_delayed_work.
For interrupt-only driven buttons
On Saturday 13 December 2014 11:05:52 Arend van Spriel wrote:
Makes sense. I think that is what Hauke meant by adding
additional support for registering to bcma. So the discovery info is a
piece of read-only memory in the chip. Its address is stored in the
chipcommon core register space.
Hello Hans,
Please find my comments inlined.
On 12/13/14, Hans de Goede hdego...@redhat.com wrote:
Hi VishnuPatekar,
The patch mangling for this set seems to have gone a bit wrong I'm afraid
No, this time I've corrected it. Infact, last version of patch did not
used the status bit error
On Sat, Dec 13, 2014 at 5:46 PM, Sebastian Reichel s...@kernel.org wrote:
Hi,
On Fri, Dec 12, 2014 at 11:59:20AM +, Grant Likely wrote:
[...]
--- a/Documentation/devicetree/bindings/serial/of-serial.txt
+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
@@ -39,6 +39,10 @@
Hi,
On Fri, Dec 12, 2014 at 11:24 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
hi,
On Saturday 13 December 2014 05:49 AM, Doug Anderson wrote:
Yunzhi,
On Fri, Dec 12, 2014 at 7:07 AM, Yunzhi Li l...@rock-chips.com wrote:
This patch to add a generic PHY driver for ROCKCHIP usb PHYs,
Hi Andrew, Uwe,
Andrew, the first patch of this series is a new version of the one you
have in your tree, providing the changes asked by Uwe (i.e. you can
just replace yours by that one). If you prefer an additional commit over
what you already have, do not hesitate to tell me. Below, you have a
This patch adds alarm support to Intersil ISL12057 driver. This allows
to configure the chip to generate an interrupt when the alarm matches
current time value. Alarm can be programmed up to one month in the
future and is accurate to the second.
The patch was developed to support two different
Now that alarm support for ISL12057 chip is available, let's use a
feature of the driver dedicated to NETGEAR ReadyNAS 102 specific
routing of RTC IRQ#2 pin; on the device, this pin is not connected
to the SoC but to a PMIC, which allows the device to be powered
up when RTC alarm rings.
For that
Now that alarm support for ISL12057 chip is available, let's use a
feature of the driver dedicated to NETGEAR ReadyNAS 104 specific
routing of RTC IRQ#2 pin; on the device, this pin is not connected
to the SoC but to a PMIC, which allows the device to be powered
up when RTC alarm rings.
For that
Now that alarm support for ISL12057 chip is available, let's use a
feature of the driver dedicated to NETGEAR ReadyNAS 2120 specific
routing of RTC IRQ#1 pin; on the device, this pin is not connected
to the SoC but to a PMIC, which allows the device to be powered
up when RTC alarm rings.
For
When Intersil ISL12057 driver was introduced by commit 70e123373c05
(rtc: Add support for Intersil ISL12057 I2C RTC chip), the vendor
prefix 'isl' was used instead of the expected 'isil' (Intersil
NASDAQ symbol) and documented in vendor-prefixes.txt.
Recently, a patch from Philip Zabel
24 matches
Mail list logo
