On 1/15/2015 3:59 AM, Wolfram Sang wrote:
+ case M_CMD_STATUS_LOST_ARB:
+ dev_err(dev->device, "lost bus arbitration\n");
>>> I wouldn't dev_err that, only dev_dbg. I'm not sure how usual the errors
>>> for the next two cases is, maybe degrade them to dev_dbg, too?
>>>
>>
On 1/15/2015 3:59 AM, Wolfram Sang wrote:
+ case M_CMD_STATUS_LOST_ARB:
+ dev_err(dev-device, lost bus arbitration\n);
I wouldn't dev_err that, only dev_dbg. I'm not sure how usual the errors
for the next two cases is, maybe degrade them to dev_dbg, too?
These errors are rare,
> >> + case M_CMD_STATUS_LOST_ARB:
> >> + dev_err(dev->device, "lost bus arbitration\n");
> > I wouldn't dev_err that, only dev_dbg. I'm not sure how usual the errors
> > for the next two cases is, maybe degrade them to dev_dbg, too?
> >
> These errors are rare, and it's nice to keep
+ case M_CMD_STATUS_LOST_ARB:
+ dev_err(dev-device, lost bus arbitration\n);
I wouldn't dev_err that, only dev_dbg. I'm not sure how usual the errors
for the next two cases is, maybe degrade them to dev_dbg, too?
These errors are rare, and it's nice to keep them at the
On 1/13/2015 11:51 PM, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jan 13, 2015 at 06:14:17PM -0800, Ray Jui wrote:
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
>>> irq == 0 should be handled as error, too.
>>>
>> Ah. I thought zero is a valid global interrupt number, and I
On 1/13/2015 11:51 PM, Uwe Kleine-König wrote:
Hello,
On Tue, Jan 13, 2015 at 06:14:17PM -0800, Ray Jui wrote:
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
irq == 0 should be handled as error, too.
Ah. I thought zero is a valid global interrupt number, and I see other
drivers
Hello,
On Tue, Jan 13, 2015 at 06:14:17PM -0800, Ray Jui wrote:
> >> + irq = platform_get_irq(pdev, 0);
> >> + if (irq < 0) {
> > irq == 0 should be handled as error, too.
> >
> Ah. I thought zero is a valid global interrupt number, and I see other
> drivers checking against < 0 as well. Is my
On 1/13/2015 2:50 PM, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Dec 09, 2014 at 07:57:11PM -0800, Ray Jui wrote:
>> Add initial support to the Broadcom iProc I2C controller found in the
>> iProc family of SoCs.
>>
>> The iProc I2C controller has separate internal TX and RX FIFOs, each has
>>
Hello,
On Tue, Dec 09, 2014 at 07:57:11PM -0800, Ray Jui wrote:
> Add initial support to the Broadcom iProc I2C controller found in the
> iProc family of SoCs.
>
> The iProc I2C controller has separate internal TX and RX FIFOs, each has
> a size of 64 bytes. The iProc I2C controller supports two
Hello,
On Tue, Jan 13, 2015 at 06:14:17PM -0800, Ray Jui wrote:
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
irq == 0 should be handled as error, too.
Ah. I thought zero is a valid global interrupt number, and I see other
drivers checking against 0 as well. Is my understanding
On 1/13/2015 2:50 PM, Uwe Kleine-König wrote:
Hello,
On Tue, Dec 09, 2014 at 07:57:11PM -0800, Ray Jui wrote:
Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64
Hello,
On Tue, Dec 09, 2014 at 07:57:11PM -0800, Ray Jui wrote:
Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports two bus
Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports two bus speeds
including standard mode (100kHz) and fast mode (400kHz)
Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports two bus speeds
including standard mode (100kHz) and fast mode (400kHz)
14 matches
Mail list logo
