Re: [PATCH 1/1] staging: cleanup: Fix incompatible type comparison in wilc1000/host_interface.c
On 2015년 12월 03일 00:12, Mario J. Rugiero wrote: OK. Since the maintainers are CC'd, I guess I should wait for a clarification about this? Hi Mario, The purpose of that is to check if tail is null or not. if it is not null, there is tail to send, so copy to buff. regards, glen lee. El 02/12/15 a las 10:29, Dan Carpenter escribió: Put v2 in the subject. Also the subsystem prefix is: [PATCH v3] staging: wilc1000: ... On Mon, Nov 30, 2015 at 09:09:04PM -0300, Mario J. Rugiero wrote: This patch replaces an "if (ptr > 0)" comparison that seems to be a confusing way to check for null by a simpler "if (ptr)" check. Signed-off-by: Mario J. Rugiero --- v2: Remove the != NULL because checkpatch complains. drivers/staging/wilc1000/host_interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c index d5b7725..0c87f6c 100644 --- a/drivers/staging/wilc1000/host_interface.c +++ b/drivers/staging/wilc1000/host_interface.c @@ -2270,7 +2270,7 @@ static void Handle_AddBeacon(struct host_if_drv *hif_drv, *pu8CurrByte++ = ((pstrSetBeaconParam->tail_len >> 16) & 0xFF); *pu8CurrByte++ = ((pstrSetBeaconParam->tail_len >> 24) & 0xFF); -if (pstrSetBeaconParam->tail > 0) +if (pstrSetBeaconParam->tail) Probably the intention was to check if "pstrSetBeaconParam->tail_len > 0" but I'm not sure. The wilc1000 maintainers are very responsive though so maybe they will know for sure. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192e: remove unnecessary multiple blank lines
remove multiple blank lines to fix some checkpatch checks
Signed-off-by: Christian Colic
---
drivers/staging/rtl8192e/rtllib_module.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_module.c
b/drivers/staging/rtl8192e/rtllib_module.c
index 113fbf7..f4f318a 100644
--- a/drivers/staging/rtl8192e/rtllib_module.c
+++ b/drivers/staging/rtl8192e/rtllib_module.c
@@ -45,15 +45,11 @@
#include
#include
#include
-
#include "rtllib.h"
-
u32 rt_global_debug_component = COMP_ERR;
EXPORT_SYMBOL(rt_global_debug_component);
-
-
static inline int rtllib_networks_allocate(struct rtllib_device *ieee)
{
if (ieee->networks)
@@ -110,7 +106,6 @@ struct net_device *alloc_rtllib(int sizeof_priv)
}
rtllib_networks_initialize(ieee);
-
/* Default fragmentation threshold is maximum payload size */
ieee->fts = DEFAULT_FTS;
ieee->scan_age = DEFAULT_MAX_SCAN_AGE;
--
2.5.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 14/15] staging: unisys: fix alignment in visornic_main.c
On 12/2/15 8:22 AM, Dan Carpenter wrote:
> On Mon, Nov 30, 2015 at 02:46:14PM -0500, Benjamin Romer wrote:
>> @@ -1651,7 +1651,7 @@ service_resp_queue(struct uiscmdrsp *cmdrsp, struct
>> visornic_devdata *devdata,
>> * netif_wake_queue()
>> */
>> if (vnic_hit_low_watermark(devdata,
>> -devdata->lower_threshold_net_xmits)) {
>> +devdata->lower_threshold_net_xmits)) {
> The original was best. It is suggesting:
>
> if (vnic_hit_low_watermark(devdata,
>
> devdata->lower_threshold_net_xmits)) {
>
> But that is over 80 chars.
>
> regards,
> dan carpenter
>
>
Thanks,
Must have missed it.
Cheers,
Erik A
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: cleanup: Fix incompatible type comparison in wilc1000/host_interface.c
Thank you. Then the patch itself should see no changes as of now, am I right? Should I submit a new one anyway to fix the subject line? Regards, Mario. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: cleanup: Fix incompatible type comparison in wilc1000/host_interface.c
On Thu, Dec 03, 2015 at 12:13:59PM -0300, Mario J. Rugiero wrote: > Thank you. Then the patch itself should see no changes as of now, am > I right? > Should I submit a new one anyway to fix the subject line? Yes, please. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: cleanup: Fix incompatible type comparison in wilc1000/host_interface.c
Would be v3, or remains v2 because of the lack of further changes afterwards? Regards, Mario. El 03/12/15 a las 12:17, Dan Carpenter escribió: On Thu, Dec 03, 2015 at 12:13:59PM -0300, Mario J. Rugiero wrote: Thank you. Then the patch itself should see no changes as of now, am I right? Should I submit a new one anyway to fix the subject line? Yes, please. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: cleanup: Fix incompatible type comparison in wilc1000/host_interface.c
On Thu, Dec 03, 2015 at 12:18:34PM -0300, Mario J. Rugiero wrote: > Would be v3, or remains v2 because of the lack of further changes > afterwards? Bump the version number. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: skein: cleans up macros
Sanidhya, Sorry I haven't been very responsive, but I'm glad to see your progress here. Once you make the recommended changes, try using 'git format-patch' and 'git send-email' to pick and send the patch to the mailinglists. On Tue, Dec 01, 2015 at 08:42:28AM +, Sanidhya Solanki wrote: > Patch moves the headers found in the "skein_block.c" to "skein_block.h". Please reword: The original code defined macros in the source code, making it harder to read. Move them to the header file. > Compiled & checked: no errors found. If you want to let us know this, you can put these kinds of comments below the '---' ... > Signed-off-by: Sanidhya Solanki > --- Which is here. That will prevent them from becoming a part of the commit log. > drivers/staging/skein/skein_block.c | 321 > --- > drivers/staging/skein/skein_block.h | 323 > > 2 files changed, 323 insertions(+), 321 deletions(-) using the git tools mentioned above will prevent these kinds of wrapping problems, which also affect the content of the patch. Also, if this completes the TODO item, please include the change removing the item from TODO. Since this is your first submission, I'll toss this out there: Don't go redo the work to make the recommended changes. git is designed to help with this. Say you were developing on the git branch 'my_changes', $ git checkout -b my_changes_v2 my_changes $ $EDITOR drivers/staging/skein/TODO $ git add drivers/staging/skein/TODO $ git commit -m "fixup: add TODO changes" $ git rebase -i HEAD^^ change 'pick' to 'fixup' for the last commit save and exit $ git show confirm one commit has everything $ git format-patch ... $ $EDITOR 0001-*.patch $ git send-email ... If it gets all fouled up, don't panic. you can checkout 'my_changes' and it's in it's original state. :-) hth, Jason. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: wilc1000: replace 'ptr > 0' check by 'ptr' check.
This silences a sparse warning about incompatible comparisons, while making the intent of the check a bit clearer. Signed-off-by: Mario J. Rugiero --- drivers/staging/wilc1000/host_interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c index d5b7725..0c87f6c 100644 --- a/drivers/staging/wilc1000/host_interface.c +++ b/drivers/staging/wilc1000/host_interface.c @@ -2270,7 +2270,7 @@ static void Handle_AddBeacon(struct host_if_drv *hif_drv, *pu8CurrByte++ = ((pstrSetBeaconParam->tail_len >> 16) & 0xFF); *pu8CurrByte++ = ((pstrSetBeaconParam->tail_len >> 24) & 0xFF); - if (pstrSetBeaconParam->tail > 0) + if (pstrSetBeaconParam->tail) memcpy(pu8CurrByte, pstrSetBeaconParam->tail, pstrSetBeaconParam->tail_len); pu8CurrByte += pstrSetBeaconParam->tail_len; -- 2.6.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v6 4/7] PCI: Add fwnode_handle to pci_sysdata
> -Original Message-
> From: Jiang Liu [mailto:jiang@linux.intel.com]
> Sent: Wednesday, December 2, 2015 10:53 PM
> To: Jake Oshins ; gre...@linuxfoundation.org; KY
> Srinivasan ; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> vkuzn...@redhat.com; t...@redhat.com; Haiyang Zhang
> ; marc.zyng...@arm.com;
> bhelg...@google.com; linux-...@vger.kernel.org
> Subject: Re: [PATCH v6 4/7] PCI: Add fwnode_handle to pci_sysdata
>
> On 2015/11/3 5:33, ja...@microsoft.com wrote:
> > From: Jake Oshins
> >
> > +#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
> > +static inline void *_pci_root_bus_fwnode(struct pci_bus *bus)
> > +{
> > + struct pci_sysdata *sd = bus->sysdata;
> > + return sd->fwnode;
> > +}
> > +
> > +#define pci_root_bus_fwnode_pci_root_bus_fwnode
> > +#endif
> > +
> > /* Can be used to override the logic in pci_scan_bus for skipping
> > already-configured bus numbers - to be used for buggy BIOSes
> > or architectures with incomplete PCI setup by the loader */
> > diff --git a/include/asm-generic/pci.h b/include/asm-generic/pci.h
> > index f24bc51..3fde985 100644
> > --- a/include/asm-generic/pci.h
> > +++ b/include/asm-generic/pci.h
> > @@ -21,4 +21,8 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev
> *dev, int channel)
> > #define PCI_DMA_BUS_IS_PHYS(1)
> > #endif
> >
> > +#ifndef pci_root_bus_fwnode
> > +#define pci_root_bus_fwnode(bus) ((void)(bus),NULL)
> > +#endif
> Hi Jakeo,
> For x86, all PCI devices share the same MSI controller. But I'm
> not sure whether it may have per-bus/per-device MSI controllers on other
> archs. If there may be multiple MSI controllers serving PCI devices
> under the same PCI root, it would be better to use some thing like
> pci_get_msi_fwnode(bus) or similar.
> Thanks,
> Gerry
>
Certainly other architectures have per-bus MSI controllers, though usually it's
per root complex. In case you're not familiar with PCI Express terms (and I
apologize for this if you are) a root complex is one instance of PCI Express,
where traffic is defined between every part of it. If your traffic leaves PCI
Express and goes onto some processor-specific bus, it has left the root
complex. The root complex is usually modeled as a root PCI bus, a set of root
port, and a set of legacy and/or embedded endpoints, which amounts to saying
that some PCI/E devices are built into the root complex and not connected with
links.
I don't have a use case at the moment for anything other than an MSI controller
for a root complex. If you'd like me to change this so that it more naturally
extends to a situation where you'd want to use it for a specific bus, I can do
that. Please let me know.
And thanks again for your review.
-- Jake Oshins
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v6 7/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs
> -Original Message-
> From: Jiang Liu [mailto:jiang@linux.intel.com]
> Sent: Wednesday, December 2, 2015 7:12 PM
> To: Jake Oshins ; gre...@linuxfoundation.org; KY
> Srinivasan ; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> vkuzn...@redhat.com; t...@redhat.com; Haiyang Zhang
> ; marc.zyng...@arm.com;
> bhelg...@google.com; linux-...@vger.kernel.org
> Subject: Re: [PATCH v6 7/7] PCI: hv: New paravirtual PCI front-end for Hyper-
> V VMs
>
> On 2015/11/3 5:33, ja...@microsoft.com wrote:
> > From: Jake Oshins
> >
[...]
> > +
> > +/**
> > + * hv_irq_unmask() - "Unmask" the IRQ by setting its current
> > + * affinity.
> > + * @data: Describes the IRQ
> > + *
> > + * Build new a destination for the MSI and make a hypercall to
> > + * update the Interrupt Redirection Table. "Device Logical ID"
> > + * is built out of this PCI bus's instance GUID and the function
> > + * number of the device.
> > + */
> > +void hv_irq_unmask(struct irq_data *data)
> > +{
> > + struct msi_desc *msi_desc = irq_data_get_msi_desc(data);
> > + struct irq_cfg *cfg = irqd_cfg(data);
> > + struct retarget_msi_interrupt params;
> > + struct hv_pcibus_device *hbus;
> > + struct cpumask *dest;
> > + struct pci_bus *pbus;
> > + struct pci_dev *pdev;
> > + int cpu;
> > +
> > + dest = irq_data_get_affinity_mask(data);
> > + pdev = msi_desc_to_pci_dev(msi_desc);
> > + pbus = pdev->bus;
> > + hbus = container_of(pbus->sysdata, struct hv_pcibus_device,
> sysdata);
> > +
> > + memset(¶ms, 0, sizeof(params));
> > + params.partition_id = HV_PARTITION_ID_SELF;
> > + params.source = 1; /* MSI(-X) */
> > + params.address = msi_desc->msg.address_lo;
> > + params.data = msi_desc->msg.data;
> > + params.device_id = (hbus->hdev->dev_instance.b[5] << 24) |
> > + (hbus->hdev->dev_instance.b[4] << 16) |
> > + (hbus->hdev->dev_instance.b[7] << 8) |
> > + (hbus->hdev->dev_instance.b[6] & 0xf8) |
> > + PCI_FUNC(pdev->devfn);
> > + params.vector = cfg->vector;
> > +
> > + for_each_cpu_and(cpu, dest, cpu_online_mask)
> > + params.vp_mask |= (1 <<
> vmbus_cpu_number_to_vp_number(cpu));
> No knowledge about the HV implementation details, but feel some chances
> of race here between hv_irq_unmask(), hv_set_affinity() and
> cpu_up()/cpu_down() when accessing 'dest' and cpu_online_mask.
>
Thanks. Is there any architectural contract here? I tried implementing this
by doing this work in the set_affinity() callback, but the vector was often
wrong when that callback was invoked. (It seems to get changed just after
set_affinity().) Can you suggest a durable strategy?
I'll respond to all the other comments you sent (and this one, once I
understand the right response) and resend.
Thanks for your review,
Jake Oshins
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
END OF YEAR PACKAGE
Telekom Malaysia Berhad G.03B, Ground Floor, Kompleks Antarabangsa, Jln Sultan Ismail, Off Jalan Ampang 50088 50250 Kuala Lumpur. NOTIS RASMI HADIAH TELEKOM MALAYSIA Pihak Telekom Malaysia @Program Kemenangan yang telah diadakan pada 1 Dec 2015 di mana alamat email anda yang disertakan beraama Tiket Kemenangan nombor 2 - 4 - 16 - 37 - 89 - 40 -85 dengan siri nombor 2268/02 telah memenangi loteri kategori hadiah kedua khas keluarga Telekom Malaysia. Untuk menuntut hadiah kemenangan ini anda dikehendaki menghubungi melalui e mail Bahagian Tuntutan untuk tujuan pemerosesan dan pembayaran hadiah wang tunai kepada anda. Di sepanjang program Khas Keluarga Telekom yang telah diadakan di Ibupejabat di Kuala Lumpur sejumlah RM270,000.00 (Ringgit Malaysia : Dua Ratus Tujoh Puloh Ribu) telah dianugerahkan kepada anda oleh Telekom Malaysia Berhad kepada anda dan keluarga anda sempena sambutsn 2015 ini. Program ini turut dibiayai bersama oleh Toyota Malaysia dan Tenaga Nasional sebagai pakej istimewa Telekom 2015 dan anda perlu memahami bahawa e mail ini adalah 100% sah dan diiktiraf kerana program ini kebiasaannya diadakan sekali dalam masa lima tahun. Sila hubungi agen kami untuk menuntut hadiah ini : EN SHAFIE BIN HASSAN Pengarah Bahagian Tuntutan E-mail : telek...@outlook.my Untuk tujuan pemerosesan sila hubungi agen kami dengan maklumat-maklumat berikut : 1) Nama Penuh: 2). Umur: 3). Pekerjaan: 4). Telefon: 5). Negeri/Bandar: Perlu diingatkan bahawa hadiah akhir tahun Telekom Malaysia Berhad 2015 ini adalah diberikan khas kepada anda dan keluarga anda dan anda hendaklah membuat tunttan ini sebelum Dec 30, 2015. Terima kasih. Mrs Nadia binti Rafik Pengurus Eksekutif Anugerah Telekom Malaysia Ibupejabat telekom Malaysia. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging/rdma/hfi1: fix pio progress routine race with allocator
The allocation code assumes that the shadow ring cannot
be overrun because the credits will limit the allocation.
Unfortuately, the progress mechanism in sc_release_update() updates
the free count prior to processing the shadow ring, allowing the
shadow ring to be overrun by an allocation.
Reviewed-by: Mark Debbage
Signed-off-by: Mike Marciniszyn
---
drivers/staging/rdma/hfi1/pio.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rdma/hfi1/pio.c b/drivers/staging/rdma/hfi1/pio.c
index eab58c1..8e10857 100644
--- a/drivers/staging/rdma/hfi1/pio.c
+++ b/drivers/staging/rdma/hfi1/pio.c
@@ -1565,6 +1565,7 @@ void sc_release_update(struct send_context *sc)
u64 hw_free;
u32 head, tail;
unsigned long old_free;
+ unsigned long free;
unsigned long extra;
unsigned long flags;
int code;
@@ -1579,7 +1580,7 @@ void sc_release_update(struct send_context *sc)
extra = (((hw_free & CR_COUNTER_SMASK) >> CR_COUNTER_SHIFT)
- (old_free & CR_COUNTER_MASK))
& CR_COUNTER_MASK;
- sc->free = old_free + extra;
+ free = old_free + extra;
trace_hfi1_piofree(sc, extra);
/* call sent buffer callbacks */
@@ -1589,7 +1590,7 @@ void sc_release_update(struct send_context *sc)
while (head != tail) {
pbuf = &sc->sr[tail].pbuf;
- if (sent_before(sc->free, pbuf->sent_at)) {
+ if (sent_before(free, pbuf->sent_at)) {
/* not sent yet */
break;
}
@@ -1603,8 +1604,10 @@ void sc_release_update(struct send_context *sc)
if (tail >= sc->sr_size)
tail = 0;
}
- /* update tail, in case we moved it */
sc->sr_tail = tail;
+ /* make sure tail is updated before free */
+ smp_wmb();
+ sc->free = free;
spin_unlock_irqrestore(&sc->release_lock, flags);
sc_piobufavail(sc);
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging/rdma/hfi1: fix sdma build failures to always clean up
There are holes in the sdma build support routines that do
not clean any partially built sdma descriptors after mapping or
allocate failures.
This patch corrects these issues.
Reviewed-by: Dennis Dalessandro
Signed-off-by: Mike Marciniszyn
---
drivers/staging/rdma/hfi1/sdma.c | 10 ++
drivers/staging/rdma/hfi1/sdma.h |7 +--
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rdma/hfi1/sdma.c b/drivers/staging/rdma/hfi1/sdma.c
index 90b7072..8023eeb 100644
--- a/drivers/staging/rdma/hfi1/sdma.c
+++ b/drivers/staging/rdma/hfi1/sdma.c
@@ -2724,22 +2724,21 @@ static int _extend_sdma_tx_descs(struct hfi1_devdata
*dd, struct sdma_txreq *tx)
tx->coalesce_buf = kmalloc(tx->tlen + sizeof(u32),
GFP_ATOMIC);
if (!tx->coalesce_buf)
- return -ENOMEM;
-
+ goto enomem;
tx->coalesce_idx = 0;
}
return 0;
}
if (unlikely(tx->num_desc == MAX_DESC))
- return -ENOMEM;
+ goto enomem;
tx->descp = kmalloc_array(
MAX_DESC,
sizeof(struct sdma_desc),
GFP_ATOMIC);
if (!tx->descp)
- return -ENOMEM;
+ goto enomem;
/* reserve last descriptor for coalescing */
tx->desc_limit = MAX_DESC - 1;
@@ -2747,6 +2746,9 @@ static int _extend_sdma_tx_descs(struct hfi1_devdata *dd,
struct sdma_txreq *tx)
for (i = 0; i < tx->num_desc; i++)
tx->descp[i] = tx->descs[i];
return 0;
+enomem:
+ sdma_txclean(dd, tx);
+ return -ENOMEM;
}
/*
diff --git a/drivers/staging/rdma/hfi1/sdma.h b/drivers/staging/rdma/hfi1/sdma.h
index 85701ee..da89e64 100644
--- a/drivers/staging/rdma/hfi1/sdma.h
+++ b/drivers/staging/rdma/hfi1/sdma.h
@@ -774,10 +774,13 @@ static inline int _sdma_txadd_daddr(
tx->tlen -= len;
/* special cases for last */
if (!tx->tlen) {
- if (tx->packet_len & (sizeof(u32) - 1))
+ if (tx->packet_len & (sizeof(u32) - 1)) {
rval = _pad_sdma_tx_descs(dd, tx);
- else
+ if (rval)
+ return rval;
+ } else {
_sdma_close_tx(dd, tx);
+ }
}
tx->num_desc++;
return rval;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8712: Improve suspend/resume functionality.
Cancel pending URBs during suspend operation to avoid receiving ESHUTDOWN
in read/write completion callbacks while the device is suspended.
Receiving ESHUTDOWN in read/write completion callbacks will cause the
driver to enter a non-functioning "stopped" state from which the driver is
unable to recover without reloading the module.
Signed-off-by: Hemmo Nieminen
---
Notes:
Tested on x86_64 with RTL8191SU 802.11n WLAN Adapter.
drivers/staging/rtl8712/drv_types.h | 1 +
drivers/staging/rtl8712/usb_intf.c | 12
drivers/staging/rtl8712/usb_ops_linux.c | 5 -
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index 3d64fee..29e47e1 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -159,6 +159,7 @@ struct _adapter {
struct mp_priv mppriv;
s32 bDriverStopped;
s32 bSurpriseRemoved;
+ s32 bSuspended;
u32 IsrContent;
u32 ImrContent;
u8 EepromAddressSize;
diff --git a/drivers/staging/rtl8712/usb_intf.c
b/drivers/staging/rtl8712/usb_intf.c
index c71333f..b64f10b 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -205,12 +205,15 @@ struct drv_priv {
static int r871x_suspend(struct usb_interface *pusb_intf, pm_message_t state)
{
struct net_device *pnetdev = usb_get_intfdata(pusb_intf);
+ struct _adapter *padapter = netdev_priv(pnetdev);
netdev_info(pnetdev, "Suspending...\n");
if (!pnetdev || !netif_running(pnetdev)) {
netdev_info(pnetdev, "Unable to suspend\n");
return 0;
}
+ padapter->bSuspended = true;
+ rtl871x_intf_stop(padapter);
if (pnetdev->netdev_ops->ndo_stop)
pnetdev->netdev_ops->ndo_stop(pnetdev);
mdelay(10);
@@ -218,9 +221,16 @@ static int r871x_suspend(struct usb_interface *pusb_intf,
pm_message_t state)
return 0;
}
+void rtl871x_intf_resume(struct _adapter *padapter)
+{
+ if (padapter->dvobjpriv.inirp_init)
+ padapter->dvobjpriv.inirp_init(padapter);
+}
+
static int r871x_resume(struct usb_interface *pusb_intf)
{
struct net_device *pnetdev = usb_get_intfdata(pusb_intf);
+ struct _adapter *padapter = netdev_priv(pnetdev);
netdev_info(pnetdev, "Resuming...\n");
if (!pnetdev || !netif_running(pnetdev)) {
@@ -230,6 +240,8 @@ static int r871x_resume(struct usb_interface *pusb_intf)
netif_device_attach(pnetdev);
if (pnetdev->netdev_ops->ndo_open)
pnetdev->netdev_ops->ndo_open(pnetdev);
+ padapter->bSuspended = false;
+ rtl871x_intf_resume(padapter);
return 0;
}
diff --git a/drivers/staging/rtl8712/usb_ops_linux.c
b/drivers/staging/rtl8712/usb_ops_linux.c
index 489a9e6..e77be2a 100644
--- a/drivers/staging/rtl8712/usb_ops_linux.c
+++ b/drivers/staging/rtl8712/usb_ops_linux.c
@@ -228,11 +228,14 @@ static void r8712_usb_read_port_complete(struct urb *purb)
}
} else {
switch (purb->status) {
+ case -ENOENT:
+ if (padapter->bSuspended)
+ break;
+ /* Fall through. */
case -EINVAL:
case -EPIPE:
case -ENODEV:
case -ESHUTDOWN:
- case -ENOENT:
padapter->bDriverStopped = true;
break;
case -EPROTO:
--
2.6.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] storvsc: add more logging for error and warning messages
Introduce a logging level for storvsc to log certain error/warning messages.
Those messages are helpful in some environments, e.g. Microsoft Azure, for
customer support and troubleshooting purposes.
Signed-off-by: Long Li
---
drivers/scsi/storvsc_drv.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 40c43ae..afa1647 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -164,6 +164,21 @@ static int sense_buffer_size =
PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
*/
static int vmstor_proto_version;
+#define STORVSC_LOGGING_NONE 0
+#define STORVSC_LOGGING_ERROR 1
+#define STORVSC_LOGGING_WARN 2
+
+static int logging_level = STORVSC_LOGGING_ERROR;
+module_param(logging_level, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(logging_level,
+ "Logging level, 0 - None, 1 - Error (default), 2 - Warning.");
+
+static inline bool do_logging(int level)
+{
+ return (logging_level >= level) ? true : false;
+}
+
+
struct vmscsi_win8_extension {
/*
* The following were added in Windows 8
@@ -1183,7 +1198,7 @@ static void storvsc_command_completion(struct
storvsc_cmd_request *cmd_request)
scmnd->result = vm_srb->scsi_status;
- if (scmnd->result) {
+ if (scmnd->result && do_logging(STORVSC_LOGGING_ERROR)) {
if (scsi_normalize_sense(scmnd->sense_buffer,
SCSI_SENSE_BUFFERSIZE, &sense_hdr))
scsi_print_sense_hdr(scmnd->device, "storvsc",
@@ -1239,12 +1254,25 @@ static void storvsc_on_io_completion(struct hv_device
*device,
stor_pkt->vm_srb.sense_info_length =
vstor_packet->vm_srb.sense_info_length;
+ if (vstor_packet->vm_srb.scsi_status != 0 ||
+ vstor_packet->vm_srb.srb_status != SRB_STATUS_SUCCESS)
+ if (do_logging(STORVSC_LOGGING_WARN))
+ dev_warn(&device->device,
+ "cmd 0x%x scsi status 0x%x srb status 0x%x\n",
+ stor_pkt->vm_srb.cdb[0],
+ vstor_packet->vm_srb.scsi_status,
+ vstor_packet->vm_srb.srb_status);
if ((vstor_packet->vm_srb.scsi_status & 0xFF) == 0x02) {
/* CHECK_CONDITION */
if (vstor_packet->vm_srb.srb_status &
SRB_STATUS_AUTOSENSE_VALID) {
/* autosense data available */
+ if (do_logging(STORVSC_LOGGING_WARN))
+ dev_warn(&device->device,
+ "stor pkt %p autosense data valid - len
%d\n",
+ request,
+ vstor_packet->vm_srb.sense_info_length);
memcpy(request->cmd->sense_buffer,
vstor_packet->vm_srb.sense_data,
--
1.8.5.6
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] storvsc: add more logging for error and warning messages
Thanks Joe.
I'll send out another patch.
> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Thursday, December 3, 2015 6:28 PM
> To: Long Li ; KY Srinivasan ;
> Haiyang Zhang ; James E.J. Bottomley
>
> Cc: de...@linuxdriverproject.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] storvsc: add more logging for error and warning
> messages
>
> On Thu, 2015-12-03 at 19:47 -0800, Long Li wrote:
> > Introduce a logging level for storvsc to log certain error/warning
> > messages. Those messages are helpful in some environments, e.g.
> > Microsoft Azure, for customer support and troubleshooting purposes.
> []
> > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> []
> > +static inline bool do_logging(int level) {
> > + return (logging_level >= level) ? true : false;
>
> The ternary is not necessary
>
> return logging_level >= level;
>
> is enough
>
> > +}
> > +
> > +
> > struct vmscsi_win8_extension {
> > /*
> > * The following were added in Windows 8 @@ -1183,7 +1198,7 @@
> > static void storvsc_command_completion(struct storvsc_cmd_request
> > *cmd_request)
> >
> > scmnd->result = vm_srb->scsi_status;
> >
> > - if (scmnd->result) {
> > + if (scmnd->result && do_logging(STORVSC_LOGGING_ERROR)) {
> > if (scsi_normalize_sense(scmnd->sense_buffer,
> > SCSI_SENSE_BUFFERSIZE, &sense_hdr))
> > scsi_print_sense_hdr(scmnd->device, "storvsc",
>
> Is it appropriate to make this scsi_normalize_sense call conditional on
> do_logging here?
>
> > @@ -1239,12 +1254,25 @@ static void storvsc_on_io_completion(struct
> hv_device *device,
> > stor_pkt->vm_srb.sense_info_length =
> > vstor_packet->vm_srb.sense_info_length;
> >
> > + if (vstor_packet->vm_srb.scsi_status != 0 ||
> > + vstor_packet->vm_srb.srb_status != SRB_STATUS_SUCCESS)
> > + if (do_logging(STORVSC_LOGGING_WARN))
> > + dev_warn(&device->device,
> > + "cmd 0x%x scsi status 0x%x srb status
> 0x%x\n",
> > + stor_pkt->vm_srb.cdb[0],
> > + vstor_packet->vm_srb.scsi_status,
> > + vstor_packet->vm_srb.srb_status);
>
> It might make some sense to use another macro indirection like
>
> #define svc_log_warn(dev, level, fmt, ...)\
> do { \
> if (do_logging(STORSVC_LOGGING_##level) \
> dev_warn(&(dev)->device, fmt, ##__VA_ARGS__); \
> } while (0)
>
> So a use could be:
>
> if (vstore_packet...)
> svc_log_warn(device, WARN, ...);
>
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] storvsc: add logging for error/warning messages
Introduce a logging level for storvsc to log certain error/warning messages.
Those messages are helpful in some environments, e.g. Microsoft Azure, for
customer support and troubleshooting purposes.
Signed-off-by: Long Li
---
drivers/scsi/storvsc_drv.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 40c43ae..f46ed2c 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -164,6 +164,26 @@ static int sense_buffer_size =
PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
*/
static int vmstor_proto_version;
+#define STORVSC_LOGGING_NONE 0
+#define STORVSC_LOGGING_ERROR 1
+#define STORVSC_LOGGING_WARN 2
+
+static int logging_level = STORVSC_LOGGING_ERROR;
+module_param(logging_level, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(logging_level,
+ "Logging level, 0 - None, 1 - Error (default), 2 - Warning.");
+
+static inline bool do_logging(int level)
+{
+ return logging_level >= level;
+}
+
+#define storvsc_log(dev, level, fmt, ...) \
+do { \
+ if (do_logging(level)) \
+ dev_warn(&(dev)->device, fmt, ##__VA_ARGS__); \
+} while (0)
+
struct vmscsi_win8_extension {
/*
* The following were added in Windows 8
@@ -1185,7 +1205,8 @@ static void storvsc_command_completion(struct
storvsc_cmd_request *cmd_request)
if (scmnd->result) {
if (scsi_normalize_sense(scmnd->sense_buffer,
- SCSI_SENSE_BUFFERSIZE, &sense_hdr))
+ SCSI_SENSE_BUFFERSIZE, &sense_hdr) &&
+ do_logging(STORVSC_LOGGING_ERROR))
scsi_print_sense_hdr(scmnd->device, "storvsc",
&sense_hdr);
}
@@ -1239,6 +1260,13 @@ static void storvsc_on_io_completion(struct hv_device
*device,
stor_pkt->vm_srb.sense_info_length =
vstor_packet->vm_srb.sense_info_length;
+ if (vstor_packet->vm_srb.scsi_status != 0 ||
+ vstor_packet->vm_srb.srb_status != SRB_STATUS_SUCCESS)
+ storvsc_log(device, STORVSC_LOGGING_WARN,
+ "cmd 0x%x scsi status 0x%x srb status 0x%x\n",
+ stor_pkt->vm_srb.cdb[0],
+ vstor_packet->vm_srb.scsi_status,
+ vstor_packet->vm_srb.srb_status);
if ((vstor_packet->vm_srb.scsi_status & 0xFF) == 0x02) {
/* CHECK_CONDITION */
@@ -1246,6 +1274,10 @@ static void storvsc_on_io_completion(struct hv_device
*device,
SRB_STATUS_AUTOSENSE_VALID) {
/* autosense data available */
+ storvsc_log(device, STORVSC_LOGGING_WARN,
+ "stor pkt %p autosense data valid - len %d\n",
+ request,
vstor_packet->vm_srb.sense_info_length);
+
memcpy(request->cmd->sense_buffer,
vstor_packet->vm_srb.sense_data,
vstor_packet->vm_srb.sense_info_length);
--
1.8.5.6
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
business leads
Hey, Do you need new customer leads? Do you need new business leads? Do you need to increase sales? Do you need to make sales faster? We can help you to generate new business leads and sales by using our mailing service. That may grow your business sales 2-4 times than what it is now. Please reply if you are interested so I can go over options for you. Thanks, Tony White Email: gerr...@sina.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
