Re: [PATCH] staging: ft1000: fix else style error
On Tue, Jan 13, 2015 at 08:01:39AM -0800, Joe Perches wrote:
> On Tue, 2015-01-13 at 12:57 +0100, Bilel DRIRA wrote:
> > ERROR: else should follow close brace '}'
> []
> > diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
> > b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
> []
> > @@ -572,8 +572,7 @@ static void ft1000_hbchk(u_long data)
> > if (tempword != ho) {
> > if (info->AsicID == ELECTRABUZZ_ID) {
> > tempword = ft1000_read_dpram(dev, FT1000_HI_HO);
> > - }
> > - else {
> > + } else {
> > tempword = ntohs(ft1000_read_dpram_mag_16(dev,
> > FT1000_MAG_HI_HO, FT1000_MAG_HI_HO_INDX));
> > }
> > }
>
> True, but you could instead remove all the braces
> around both arms from all uses of
>
> if (test) {
> ;
> } else {
> ;
> }
>
> > @@ -688,15 +687,13 @@ static void ft1000_hbchk(u_long data)
> > if (tempword != hi) {
> > if (info->AsicID == ELECTRABUZZ_ID) {
> > ft1000_write_dpram(dev, FT1000_HI_HO, hi);
> > - }
> > - else {
> > + } else {
> > ft1000_write_dpram_mag_16(dev,
> > FT1000_MAG_HI_HO, hi_mag, FT1000_MAG_HI_HO_INDX);
> > }
>
> etc...
>
>
Hi Joe,
Of course, you are right. I will do that and resend the patch.
Thanks.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: ft1000: fix braces warning
Ok,thank you, I will do that and resend the patch again.
On Tue, Feb 03, 2015 at 11:05:08AM -0800, Joe Perches wrote:
> On Tue, 2015-02-03 at 19:58 +0100, Bilel DRIRA wrote:
> > This patch fix the checkpatch.pl WARNING:
> []
> > diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
> > b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
> []
> > @@ -1963,11 +1948,10 @@ static irqreturn_t ft1000_interrupt(int irq, void
> > *dev_id)
> > ft1000_read_reg(dev,
> >
> > FT1000_REG_MAG_DFSR);
> > }
> > - if (tempword & 0x1f) {
> > + if (tempword & 0x1f)
> > ft1000_copy_up_pkt(dev);
> > - } else {
> > + else
> > break;
> > - }
> > cnt++;
> > } while (cnt < MAX_RCV_LOOP);
> >
>
> trivia: the logic here is generally better inverted:
>
> if (!(tempword & 0x1f))
> break;
> ft1000_copy_up_pkt(dev);
> cnt++;
> } while (cnt < etc...)
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Confirm your donation
Attn: Email user, We are pleased to announce that your "E address" was nominated as one of the 28 recipients under the Second category in the online DONATION SWEEPSTAKE 2020 Prospect as part of the Bill & Melinda Gates Foundation to relief Humanitarian struggle. For claims and clearance, kindly reply back with your SERIAL details: Bill/Melinda-S28/79712 OR call: +44-7443676180 on how to receive your donation cash prize of 650,000.00 Euro. Ms. JENET LAUREN SECRETARY. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Confirm your donation
Attn: Email user, We are pleased to announce that your "E address" was nominated as one of the 28 recipients under the Second category in the online DONATION SWEEPSTAKE 2020 Prospect as part of the Bill & Melinda Gates Foundation to relief Humanitarian struggle. For claims and clearance, kindly reply back with your SERIAL details: Bill/Melinda-S28/79712 OR call: +44-7443676180 on how to receive your donation cash prize of 650,000.00 Euro. Ms. JENET LAUREN SECRETARY. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on dgrp or serqt_usb2?
On 06/23/2014 04:26 PM, Kristina Martšenko wrote: Hi Bill, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving dgrp or serqt_usb2 out of staging in over a year. Are there any plans to clean these drivers up and move them out soon? Because otherwise we're going to have to delete them, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina In the case of serqt_usb2, I'm certainly not going to be working on it. If I had a multi-port version of one of those devices, I'd change the ssu100 driver to deal with them instead of fooling with the staging driver. In the case of dgrp, I no longer have access to the hardware so I'm not planning on doing any more work on it. So I've got no objections to removing both dgrp and serqt_usb2. -- Bill ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] jsm: add support for additional Neo cards
On 08/30/2014 02:59 PM, Greg KH wrote:
On Sat, Aug 30, 2014 at 02:54:36PM -0400, wf...@worldbroken.com wrote:
From: Bill Pemberton
Add device ids for additional Neo cards. The ids come from the dgnc
driver.
Signed-off-by: Bill Pemberton
---
drivers/tty/serial/jsm/jsm_driver.c | 38 +
include/linux/pci_ids.h | 8
2 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/jsm/jsm_driver.c
b/drivers/tty/serial/jsm/jsm_driver.c
index a47d882d6743..d2885a7bb090 100644
--- a/drivers/tty/serial/jsm/jsm_driver.c
+++ b/drivers/tty/serial/jsm/jsm_driver.c
@@ -93,12 +93,34 @@ static int jsm_probe_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
/* store the info for the board we've found */
brd->boardnum = adapter_count++;
brd->pci_dev = pdev;
- if (pdev->device == PCIE_DEVICE_ID_NEO_4_IBM)
+
+ switch (pdev->device) {
+
+ case PCI_DEVICE_ID_NEO_2DB9:
+ case PCI_DEVICE_ID_NEO_2DB9PRI:
+ case PCI_DEVICE_ID_NEO_2RJ45:
+ case PCI_DEVICE_ID_NEO_2RJ45PRI:
+ case PCI_DEVICE_ID_NEO_2_422_485:
+ brd->maxports = 2;
+ break;
+
+ case PCI_DEVICE_ID_NEO_4:
+ case PCIE_DEVICE_ID_NEO_4:
+ case PCIE_DEVICE_ID_NEO_4RJ45:
+ case PCIE_DEVICE_ID_NEO_4_IBM:
brd->maxports = 4;
- else if (pdev->device == PCI_DEVICE_ID_DIGI_NEO_8)
+ break;
+
+ case PCI_DEVICE_ID_DIGI_NEO_8:
+ case PCIE_DEVICE_ID_NEO_8:
+ case PCIE_DEVICE_ID_NEO_8RJ45:
brd->maxports = 8;
- else
- brd->maxports = 2;
+ break;
+
+ default:
+ brd->maxports = 1;
+ break;
+ }
spin_lock_init(&brd->bd_intr_lock);
@@ -209,6 +231,14 @@ static struct pci_device_id jsm_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI), 0, 0, 3 },
{ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4_IBM), 0, 0, 4 },
{ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_DIGI_NEO_8), 0, 0, 5 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_4), 0, 0, 6 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422), 0, 0, 7 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422_485), 0, 0, 8
},
+ { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2_422_485), 0, 0, 9
},
+ { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8), 0, 0, 10 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4), 0, 0, 11 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4RJ45), 0, 0, 12 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8RJ45), 0, 0, 13 },
{ 0, }
};
MODULE_DEVICE_TABLE(pci, jsm_pci_tbl);
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6ed0bb73a864..f0f610c94bb2 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1516,11 +1516,19 @@
#define PCI_DEVICE_ID_DIGI_DF_M_E 0x0071
#define PCI_DEVICE_ID_DIGI_DF_M_IOM2_A0x0072
#define PCI_DEVICE_ID_DIGI_DF_M_A 0x0073
+#define PCI_DEVICE_ID_NEO_4 0x00B0
#define PCI_DEVICE_ID_DIGI_NEO_8 0x00B1
#define PCI_DEVICE_ID_NEO_2DB9 0x00C8
#define PCI_DEVICE_ID_NEO_2DB9PRI 0x00C9
#define PCI_DEVICE_ID_NEO_2RJ45 0x00CA
#define PCI_DEVICE_ID_NEO_2RJ45PRI 0x00CB
+#define PCI_DEVICE_ID_NEO_1_422 0x00CC
+#define PCI_DEVICE_ID_NEO_1_422_485 0x00CD
+#define PCI_DEVICE_ID_NEO_2_422_485 0x00CE
+#define PCIE_DEVICE_ID_NEO_80x00F0
+#define PCIE_DEVICE_ID_NEO_40x00F1
+#define PCIE_DEVICE_ID_NEO_4RJ450x00F2
+#define PCIE_DEVICE_ID_NEO_8RJ450x00F3
#define PCIE_DEVICE_ID_NEO_4_IBM0x00F4
As per the information in the top of this file, we only add new ids when
they cross multiple files. Right now these values you are adding are
only for a single driver, so they don't need to be added here.
Can you redo this series without touching the pci_ids.h file?
Ah, my apologies, obviously I didn't read the top of the pci_ids.h.
I'll redo these.
--
Bill
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Patch v2 0/2] Move Digi Neo card support from dgnc to jsm
On 09/08/2014 04:17 PM, Greg KH wrote: On Sat, Aug 30, 2014 at 04:35:56PM -0400, wf...@worldbroken.com wrote: From: Bill Pemberton The jsm driver (drivers/tty/serial/jsm) already supports the Digi Neo cards that dgnc (staging) supports. In fact, it appears that jsm was based on dgnc. The dgnc driver has PCI ids for more cards than jsm, this patch moves support for all the Neo cards to jsm. The result of this will be that dgnc will only support the Classic cards since the jsm driver doesn't support those cards yet. Bill Pemberton (2): jsm: add support for additional Neo cards staging: dgnc: remove Neo card ids from device table drivers/staging/dgnc/dgnc_driver.c | 13 - drivers/tty/serial/jsm/jsm.h| 10 ++ drivers/tty/serial/jsm/jsm_driver.c | 38 + 3 files changed, 44 insertions(+), 17 deletions(-) These are now applied, thanks. Do you think we can delete the dgnc driver now, or are there still some odd cards out there that it only supports? What would it take to move that support to the jsm driver instead? The jsm driver still doesn't support the Classic cards, just the Neo cards so dgnc would still be needed to support those cards. I think the right thing would be to put the Classic support into jsm. I've started looking at that. Dgnc and jsm are obviously from the same base, so dgnc can be used as guide on what to do. However, I don't have a Classic card so I wouldn't be able to test any of the Classic support. -- Bill ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation
On Sun, 10 Aug 2014, Florian Fainelli wrote:
> Le 10/08/2014 20:23, Dexuan Cui a écrit :
> >> -Original Message-
> >> From: Greg KH [mailto:gre...@linuxfoundation.org]
> >>>>>
> >>>>> IMO the most feasible and need-the-least-change solution may be:
> >>>>> the hyperv network VSC driver passes the event
> >>>>> RNDIS_STATUS_NETWORK_CHANGE to the udev daemon?
> >>>>>
> >>>> No, don't do that, again, act like any other network device, drop the
> >>>> link and bring it up when it comes back.
> >>>>
> >>> Hi Greg,
> >>> Do you mean tearing down the net device and re-creating it (by
> >>> register_netdev() and unregister_netdev)?
> >>
> >> No, don't you have link-detect for your network device? Toggle that, I
> >> thought patches to do this were posted a while ago...
> >>
> >> But if you really want to tear the whole network device down and then
> >> back up again, sure, that would also work.
> > Hi Greg, Stephen,
> >
> > Thanks for the comments!
> >
> > I suppose you meant the below logic:
> > if (refresh) {
> > rtnl_lock();
> > netif_carrier_off(net);
> > netif_carrier_on(net);
> > rtnl_unlock();
> > }
> >
> > We have discussed this in the previous mails of this thread itself:
> > e.g., http://marc.info/?l=linux-driver-devel&m=140593811715975&w=2
> >
> > Unluckily this logic doesn't work because the user-space daemons
> > like ifplugd, usually don't renew the DHCP immediately as long as they
> > receive a link-down message: they usually wait for some seconds and if
> > they find the link becomes up soon, they won't trigger renew operations.
> > (I guess this behavior can be somewhat reasonable: maybe the daemons
> > try to not trigger DHCP renew on temporary link instability)
>
> Is that such a big deal? If you know you spend much of your time in
> ifplugd, why not use something different that triggers a DHCP renewal
> faster, or fix ifplugd?
In the case of ifplugd, it has parameters -u | --delay-up= which
defaults to 0 seconds, and -d | --delay-down= which defaults to
5 seconds. Maybe for hyperv you could specify --delay-down=0.
I don't know if other daemons such as systemd have similar options.
It might still be good to have some modest delay between the
netif_carrier_off(net) and netif_carrier_on(net).
-Bill
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Adds Digi driver to staging.
Greg KH writes: > > On Thu, Jul 18, 2013 at 02:25:11PM -0400, Mark Hounschell wrote: > > On 07/18/2013 01:40 PM, Greg KH wrote: > > > On Thu, Jul 18, 2013 at 08:26:55AM -0400, Mark Hounschell wrote: > > >> On 07/17/2013 05:49 PM, Greg KH wrote: > > >>> On Wed, Jul 17, 2013 at 04:18:01PM -0400, Lidza Louina wrote: > > >>>> This patch adds the Digi driver to staging. > > >>> > > >>> Which digi driver? For what hardware? What type of driver is it? > > >>> Please provide some more details here. > > >>> > > >> > > >> From the readme: > > >> > > >>This Digi software package includes device drivers for the PCI > > >> models > > >>of the Digi Neo and ClassicBoard series of products. > > >>It is currently supported on the following hardware platforms: > > >> > > >>o Standard i386/i486 and Pentium PC (x86 32bit) > > >>o x86 64bit > > > > > > I was "hinting" that this needed to be explained in the changelog entry. > > > The part about the architectures is not needed, as, unless something > > > really strange is going on in the driver, it should work on all cpus > > > that support PCI, right? > > > > > > > That I cannot attest to. The readme also says: > > > > o Standard i386/i486 and Pentium PC (x86 32bit) > > o x86 64bit > > > > I can only personally vouch for Intel/Amd CPUs running in 32 bit mode. > > I'll look at the driver code, but odds are, unless you are assuming a > specific endian format of some data, all should be fine on other cpu > types. > If it's anything like dgrp, it will have some places that it assumes a specific endian format. -- Bill ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Dear Friend
Dear Friend You have been compensated with the sum of 4.1 million dollars in this united nation the payment will be Issue into atm visa card and send to you from the Santander bank we need your address passport and your whatsapp number. Thanks Mrs. Bill Chantal ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
ATM VISA CARD COMPENSATED
Dear Friend You have been compensated with the sum of 4.4 million dollars in this united nation the payment will be Issue into ATM visa card and send to you from the Santander bank in Spain we need your address passport and your whatsapp number Thanks Mrs. bill Chantal ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Dear Friend
Attention You have Been Compensated with the sum of 4.6 million dollars in this United Nation the Payment will be issue into Atm Visa Card and send to you from the Santander Bank of Spain we need your address, Passport and your Whatsapp Number. THANKS MRS Bill Chantal Lawrence ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
