Re: [PATCH] bluetooth: Add hci_h4p driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Pavel,

>>> Add HCI driver for H4 with Nokia extensions. This device is used on
>>> Nokia N900 cell phone.
>>> 
>>> Older version of this driver lived in staging, before being reverted
>>> in a4102f90e87cfaa3fdbed6fdf469b23f0eeb4bfd .
>>> 
>>> Signed-off-by: Pavel Machek <pavel@xxxxxx>
>>> Thanks-to: Sebastian Reichel <sre@xxxxxxxxxx>
>>> Thanks-to: Joe Perches <joe@xxxxxxxxxxx>
>>> 
>>> ---
>>> 
>>> Please apply,
>>> 								Pavel
>>> 
>>> 
>>> Kconfig      |   10 
>>> Makefile     |    4 
>>> nokia_core.c | 1149 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> nokia_fw.c   |   99 +++++
>>> nokia_h4p.h  |  214 ++++++++++
>>> nokia_uart.c |  171 ++++++++
>>> 7 files changed, 1667 insertions(+)
> 
> Speaking about formatting, could you properly format your emails, that
> is inserting newline after ~78 columns, to make them easier to reply
> to?

or you get an email client that can handle that part.

>> so when I run this through checkpatch --strict, then I get tons of warning that we have DOS style ^M line breaks. There are also trailing whitespace that need fixing. I can use cleanpatch to do this, but so can you.
>> 
> 
> Strange, where do you see DOS style line breaks? Checkpatch here does
> not warn about that, and they really should not be there.

If that would be the only pieces, then I would have fixed it already. That is not the big deal. The rest of checkpatch is what I am not going to fix for you.

>> Even after doing that there are still obvious plain coding style violation in the patch. For example:
>> 
>> ERROR: space prohibited before that ',' (ctx:WxW)
>> #610: FILE: drivers/bluetooth/nokia_core.c:517:
>> +			__h4p_set_auto_ctsrts(info, 0 , UART_EFR_RTS);
> 
> Yeah, I should have catched that one.
> 
>> CHECK: Alignment should match open parenthesis
>> #662: FILE: drivers/bluetooth/nokia_core.c:569:
>> +		h4p_outb(info, UART_OMAP_SCR,
>> +			     h4p_inb(info, UART_OMAP_SCR) |
>> 
>> CHECK: Blank lines aren't necessary before a close brace '}'
>> #692: FILE: drivers/bluetooth/nokia_core.c:599:
>> +
>> +}
>> 
>> These are only few. They are more and all these need fixing before I
>> even consider it.
> 
> Yeah, so first patch was too good for staging, and I "would be allowed
> to clean it up in tree", and now you run checkpatch --strict,
> complaining about very serious stuff such as "blank lines before }".

The network subsystem requires the --strict option.

Please stop complaining about staging. The patch went in, it was ignored for month and multiple kernel release and it got removed. Deal with it.

> 
> Yes, checkpatch produces a lot of junk, like warnings about
> mdelay(). I'm not sure how you'd want #662 above, formatted.
> 
> pavel@amd:/data/l/linux-n900$ scripts/checkpatch.pl --strict --file
> drivers/bluetooth/*.c | wc -l 3194
> pavel@amd:/data/l/linux-n900$
> 
> ...so I really can't know which checkpatch complains you consider
> serious and which are ok... And yes, I guess I should trim down those
> FSF notices.

The FSF notices are the ones I do not care about right now. Even the over 80 characters lines can be ignored if it just makes sense to go over.

The indentations ones need to be fixed.

> 
>> Also this worries me:
>> 
>> WARNING: DT compatible string "brcm,uart,bcm2048" appears un-documented -- check ./Documentation/devicetree/bindings/
>> #1222: FILE: drivers/bluetooth/nokia_core.c:1129:
>> +	{ .compatible = "brcm,uart,bcm2048" },
> 
> Yes, that wories me, too. It is one of reasons I wanted this to be
> merged to staging. Arguing about right bindings will take some time.

Then that needs to be figured out. It is not that I have mentioned DT for the first time. I said that right from the beginning.

> I can fix the checkpatch stuff that makes sense. That does not include
> uglyfying code just for checkpatch.  Can you then take the patch, as
> you promised, and let me argue the bindings, and the other stuff that
> needs to be fixed?
> 
> If not, can we agree that the driver in staging should be reverted, as
> Greg promised would be "easy", and I can clean it up there?

I am refusing to allow this into staging. Get this into shape for drivers/bluetooth/ or keep the driver external.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux