* RE: [PATCH v2 2/3] mwifiex: Introduce mwifiex_probe_of() to parse common properties
From: Amitkumar Karwar @ 2016-11-14 12:48 UTC (permalink / raw)
To: Brian Norris
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, dmitry.torokhov@gmail.com
In-Reply-To: <20161111204957.GC111624@google.com>
Hi Brian,
> From: Brian Norris [mailto:briannorris@chromium.org]
> Sent: Saturday, November 12, 2016 2:20 AM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> rajatja@google.com; dmitry.torokhov@gmail.com
> Subject: Re: [PATCH v2 2/3] mwifiex: Introduce mwifiex_probe_of() to
> parse common properties
>
> On Fri, Nov 11, 2016 at 04:45:10PM +0530, Amitkumar Karwar wrote:
> > From: Rajat Jain <rajatja@google.com>
> >
> > Introduce function mwifiex_probe_of() to parse common properties.
> > Since the interface drivers get to decide whether or not the device
> > tree node was a valid one (depending on the compatible property), let
> > the interface drivers pass a flag to indicate whether the device tree
> > node was a valid one.
>
> Wait, what? I don't understand why this is needed. The current of_node
> user (SDIO) always checks dev->of_node (if !NULL), and if it's not
> matching, it rejects the device and doesn't even try to register the
> card at all. That's a common pattern for DT-based drivers, and I don't
> see why we need to do differently for any other driver (e.g., PCIe).
>
> So...isn't 'dev->of_node != NULL' an equivalent test to
> 'of_node_valid'?
> Or put another way, mwifiex_add_card() should never see a 'struct
> device' whose of_node is not compatible. Do you agree?
I agree. 'of_node_valid' seems to be redundant here. I will remove it and post updated version.
Regards,
Amitkumar
^ permalink raw reply
* Re: [PATCH 1/5] megaraid_sas: switch to pci_alloc_irq_vectors
From: Christoph Hellwig @ 2016-11-14 12:48 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Martin K. Petersen, Christoph Hellwig, James Bottomley,
Sumit Saxena, linux-scsi, Hannes Reinecke
In-Reply-To: <1478857492-4581-2-git-send-email-hare@suse.de>
> if (instance->msix_vectors)
> for (i = 0; i < instance->msix_vectors; i++) {
> + free_irq(pci_irq_vector(instance->pdev, i),
> &instance->irq_context[i]);
> }
> else
> + free_irq(pci_irq_vector(instance->pdev, 0),
> + &instance->irq_context[0]);
> }
Don't forget to replace the call to pci_disable_msix with one to pci_free_irq_vectors.
>
> /**
> @@ -5018,6 +5004,7 @@ static int megasas_init_fw(struct megasas_instance *instance)
> int i, loop, fw_msix_count = 0;
> struct IOV_111 *iovPtr;
> struct fusion_context *fusion;
> + int irq_flags = PCI_IRQ_MSIX;
>
> fusion = instance->ctrl_context;
>
> @@ -5134,15 +5121,18 @@ static int megasas_init_fw(struct megasas_instance *instance)
> /* Don't bother allocating more MSI-X vectors than cpus */
> instance->msix_vectors = min(instance->msix_vectors,
> (unsigned int)num_online_cpus());
> - for (i = 0; i < instance->msix_vectors; i++)
> - instance->msixentry[i].entry = i;
> - i = pci_enable_msix_range(instance->pdev, instance->msixentry,
> - 1, instance->msix_vectors);
> + if (smp_affinity_enable)
> + irq_flags |= PCI_IRQ_AFFINITY;
> + i = pci_alloc_irq_vectors(instance->pdev, 1,
> + instance->msix_vectors, irq_flags);
> if (i > 0)
> instance->msix_vectors = i;
> else
> instance->msix_vectors = 0;
> }
> + i = pci_alloc_irq_vectors(instance->pdev, 1, 1, PCI_IRQ_LEGACY);
> + if (i < 0)
> + goto fail_setup_irqs;
This looks wrong - you have to call to pci_alloc_irq_vectors right next
to each other here, so for the MSI-X case you'll still end up calling
the second one as well, which will then fail. I think the better way
to structure the driver would be to do the following here.
- Rename the msix_vectors field to irq_vectors, and make sure it's
initialized to 1 for non-MSI-X capable adapters.
- Have a single call to pci_alloc_irq_vectors here.
- Have all the request_irq/free_irq code iterate over ->irq_vectors
instead of duplicating it
- use pdev->msix_enabled for the few cases that need to check for
MSI-X mode specificly.
> /* Now re-enable MSI-X */
> - if (instance->msix_vectors &&
> - pci_enable_msix_exact(instance->pdev, instance->msixentry,
> - instance->msix_vectors))
> + if (instance->msix_vectors)
> + irq_flags = PCI_IRQ_MSIX;
> + if (smp_affinity_enable)
> + irq_flags |= PCI_IRQ_AFFINITY;
> + rval = pci_alloc_irq_vectors(instance->pdev, 1,
> + instance->msix_vectors ?
> + instance->msix_vectors : 1, irq_flags);
> + if (rval < 0)
The old code is doing a pci_enable_msix_exact so you also need to pass
the number of vectors as the first argument here.
^ permalink raw reply
* [xen-unstable test] 102201: tolerable FAIL
From: osstest service owner @ 2016-11-14 12:49 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 102201 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102201/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail like 102160
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 102187
test-armhf-armhf-libvirt 13 saverestore-support-check fail like 102187
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102187
test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 102187
test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 102187
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 102187
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102187
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 102187
test-amd64-amd64-xl-rtds 9 debian-install fail like 102187
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass
version targeted for testing:
xen 67b5b302f5319f70288587dc98ab505c4deada1e
baseline version:
xen 67b5b302f5319f70288587dc98ab505c4deada1e
Last test of basis 102201 2016-11-14 01:57:12 Z 0 days
Testing same since 0 1970-01-01 00:00:00 Z 17119 days 0 attempts
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Published tested tree is already up to date.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH v3 1/3] mwifiex: Allow mwifiex early access to device structure
From: Amitkumar Karwar @ 2016-11-14 12:49 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Amitkumar Karwar
From: Rajat Jain <rajatja@google.com>
Today all the interface drivers (usb/pcie/sdio) assign the
adapter->dev in the register_dev() callback, although they
have this piece of info well before hand.
This patch makes the device structure available for mwifiex
right at the beginning, so that it can be used for early
initialization if needed.
This is needed for subsequent patches in this patchset that
intend to unify and consolidate some of the code that would
otherwise have to be duplicated among the interface drivers
(sdio, pcie, usb).
Signed-off-by: Rajat Jain <rajatja@google.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Same as v1
v3: Fixed checkpatch warnings
WARNING: function definition argument 'void *' should also have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,
WARNING: function definition argument 'struct semaphore *' should also have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,
WARNING: function definition argument 'struct mwifiex_if_ops *' should also have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,
WARNING: function definition argument 'u8' should also have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,
WARNING: function definition argument 'struct device *' should also have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,
---
drivers/net/wireless/marvell/mwifiex/main.c | 4 +++-
drivers/net/wireless/marvell/mwifiex/main.h | 4 +++-
drivers/net/wireless/marvell/mwifiex/pcie.c | 4 +---
drivers/net/wireless/marvell/mwifiex/sdio.c | 5 +----
drivers/net/wireless/marvell/mwifiex/usb.c | 3 +--
5 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 2478ccd..dcceab2 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1567,7 +1567,8 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
*/
int
mwifiex_add_card(void *card, struct semaphore *sem,
- struct mwifiex_if_ops *if_ops, u8 iface_type)
+ struct mwifiex_if_ops *if_ops, u8 iface_type,
+ struct device *dev)
{
struct mwifiex_adapter *adapter;
@@ -1579,6 +1580,7 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
goto err_init_sw;
}
+ adapter->dev = dev;
adapter->iface_type = iface_type;
adapter->card_sem = sem;
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index d61fe3a..549e1ba 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1412,7 +1412,9 @@ static inline u8 mwifiex_is_tdls_link_setup(u8 status)
int mwifiex_init_shutdown_fw(struct mwifiex_private *priv,
u32 func_init_shutdown);
-int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8);
+int mwifiex_add_card(void *card, struct semaphore *sem,
+ struct mwifiex_if_ops *if_ops, u8 iface_type,
+ struct device *dev);
int mwifiex_remove_card(struct mwifiex_adapter *, struct semaphore *);
void mwifiex_get_version(struct mwifiex_adapter *adapter, char *version,
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index fed6a1d..de6939c 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -231,7 +231,7 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
}
ret = mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
- MWIFIEX_PCIE);
+ MWIFIEX_PCIE, &pdev->dev);
if (ret) {
pr_err("%s failed\n", __func__);
goto err_free;
@@ -2999,11 +2999,9 @@ static void mwifiex_pcie_get_fw_name(struct mwifiex_adapter *adapter)
static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
- struct pci_dev *pdev = card->dev;
/* save adapter pointer in card */
card->adapter = adapter;
- adapter->dev = &pdev->dev;
if (mwifiex_pcie_request_irq(adapter))
return -1;
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 807af13..c95f41f 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -206,7 +206,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
}
ret = mwifiex_add_card(card, &add_remove_card_sem, &sdio_ops,
- MWIFIEX_SDIO);
+ MWIFIEX_SDIO, &func->dev);
if (ret) {
dev_err(&func->dev, "add card failed\n");
goto err_disable;
@@ -2106,9 +2106,6 @@ static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
return ret;
}
-
- adapter->dev = &func->dev;
-
strcpy(adapter->fw_name, card->firmware);
if (card->fw_dump_enh) {
adapter->mem_type_mapping_tbl = generic_mem_type_map;
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c
index 73eb084..f847fff 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -476,7 +476,7 @@ static int mwifiex_usb_probe(struct usb_interface *intf,
usb_set_intfdata(intf, card);
ret = mwifiex_add_card(card, &add_remove_card_sem, &usb_ops,
- MWIFIEX_USB);
+ MWIFIEX_USB, &card->udev->dev);
if (ret) {
pr_err("%s: mwifiex_add_card failed: %d\n", __func__, ret);
usb_reset_device(udev);
@@ -932,7 +932,6 @@ static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
struct usb_card_rec *card = (struct usb_card_rec *)adapter->card;
card->adapter = adapter;
- adapter->dev = &card->udev->dev;
switch (le16_to_cpu(card->udev->descriptor.idProduct)) {
case USB8997_PID_1:
--
1.9.1
^ permalink raw reply related
* [PATCH v3 2/3] mwifiex: Introduce mwifiex_probe_of() to parse common properties
From: Amitkumar Karwar @ 2016-11-14 12:49 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Amitkumar Karwar
In-Reply-To: <1479127752-23745-1-git-send-email-akarwar@marvell.com>
From: Rajat Jain <rajatja@google.com>
Introduce function mwifiex_probe_of() to parse common properties.
Interface drivers get to decide whether or not the device tree node
was a valid one (depending on the compatible property),
Lets fill "adapter->dt_node" in mwifiex_add_card().
The function mwifiex_probe_of() is currently only a place holder with
the next patch adding content to it.
Signed-off-by: Rajat Jain <rajatja@google.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Same as v1
v3: Redundant flag "of_node_valid" is removed (Brian)
---
drivers/net/wireless/marvell/mwifiex/main.c | 12 ++++++++++++
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 5 +----
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index dcceab2..835d330 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1552,6 +1552,16 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
}
EXPORT_SYMBOL_GPL(mwifiex_do_flr);
+static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
+{
+ struct device *dev = adapter->dev;
+
+ if (!dev->of_node)
+ return;
+
+ adapter->dt_node = dev->of_node;
+}
+
/*
* This function adds the card.
*
@@ -1581,6 +1591,8 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
}
adapter->dev = dev;
+ mwifiex_probe_of(adapter);
+
adapter->iface_type = iface_type;
adapter->card_sem = sem;
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index b697b61..bcd6408 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2235,10 +2235,7 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
* The cal-data can be read from device tree and/or
* a configuration file and downloaded to firmware.
*/
- if ((priv->adapter->iface_type == MWIFIEX_SDIO ||
- priv->adapter->iface_type == MWIFIEX_PCIE) &&
- adapter->dev->of_node) {
- adapter->dt_node = adapter->dev->of_node;
+ if (adapter->dt_node) {
if (of_property_read_u32(adapter->dt_node,
"marvell,wakeup-pin",
&data) == 0) {
--
1.9.1
^ permalink raw reply related
* [PATCH v3 3/3] mwifiex: Enable WoWLAN for both sdio and pcie
From: Amitkumar Karwar @ 2016-11-14 12:49 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov
In-Reply-To: <1479127752-23745-1-git-send-email-akarwar@marvell.com>
From: Rajat Jain <rajatja@google.com>
Commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt
support") added WoWLAN feature only for sdio. This patch moves that
code to the common module so that all the interface drivers can use
it for free. It enables pcie and sdio for its use currently.
Signed-off-by: Rajat Jain <rajatja@google.com>
---
v2: v1 doesn't apply smoothly on latest code due to recently merged
patch "mwifiex: report error to PCIe for suspend failure". Minor
conflict is resolved in v2
v3: Same as v2
---
drivers/net/wireless/marvell/mwifiex/main.c | 41 ++++++++++++++++
drivers/net/wireless/marvell/mwifiex/main.h | 25 ++++++++++
drivers/net/wireless/marvell/mwifiex/pcie.c | 2 +
drivers/net/wireless/marvell/mwifiex/sdio.c | 72 ++---------------------------
drivers/net/wireless/marvell/mwifiex/sdio.h | 8 ----
5 files changed, 73 insertions(+), 75 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 835d330..948f5c2 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1552,14 +1552,55 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
}
EXPORT_SYMBOL_GPL(mwifiex_do_flr);
+static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
+{
+ struct mwifiex_adapter *adapter = priv;
+
+ if (adapter->irq_wakeup >= 0) {
+ dev_dbg(adapter->dev, "%s: wake by wifi", __func__);
+ adapter->wake_by_wifi = true;
+ disable_irq_nosync(irq);
+ }
+
+ /* Notify PM core we are wakeup source */
+ pm_wakeup_event(adapter->dev, 0);
+
+ return IRQ_HANDLED;
+}
+
static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
{
+ int ret;
struct device *dev = adapter->dev;
if (!dev->of_node)
return;
adapter->dt_node = dev->of_node;
+ adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
+ if (!adapter->irq_wakeup) {
+ dev_info(dev, "fail to parse irq_wakeup from device tree\n");
+ return;
+ }
+
+ ret = devm_request_irq(dev, adapter->irq_wakeup,
+ mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
+ "wifi_wake", adapter);
+ if (ret) {
+ dev_err(dev, "Failed to request irq_wakeup %d (%d)\n",
+ adapter->irq_wakeup, ret);
+ goto err_exit;
+ }
+
+ disable_irq(adapter->irq_wakeup);
+ if (device_init_wakeup(dev, true)) {
+ dev_err(dev, "fail to init wakeup for mwifiex\n");
+ goto err_exit;
+ }
+ return;
+
+err_exit:
+ adapter->irq_wakeup = 0;
}
/*
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 549e1ba..ae5afe5 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1011,6 +1011,10 @@ struct mwifiex_adapter {
bool usb_mc_setup;
struct cfg80211_wowlan_nd_info *nd_info;
struct ieee80211_regdomain *regd;
+
+ /* Wake-on-WLAN (WoWLAN) */
+ int irq_wakeup;
+ bool wake_by_wifi;
};
void mwifiex_process_tx_queue(struct mwifiex_adapter *adapter);
@@ -1410,6 +1414,27 @@ static inline u8 mwifiex_is_tdls_link_setup(u8 status)
return false;
}
+/* Disable platform specific wakeup interrupt */
+static inline void mwifiex_disable_wake(struct mwifiex_adapter *adapter)
+{
+ if (adapter->irq_wakeup >= 0) {
+ disable_irq_wake(adapter->irq_wakeup);
+ if (!adapter->wake_by_wifi)
+ disable_irq(adapter->irq_wakeup);
+ }
+}
+
+/* Enable platform specific wakeup interrupt */
+static inline void mwifiex_enable_wake(struct mwifiex_adapter *adapter)
+{
+ /* Enable platform specific wakeup interrupt */
+ if (adapter->irq_wakeup >= 0) {
+ adapter->wake_by_wifi = false;
+ enable_irq(adapter->irq_wakeup);
+ enable_irq_wake(adapter->irq_wakeup);
+ }
+}
+
int mwifiex_init_shutdown_fw(struct mwifiex_private *priv,
u32 func_init_shutdown);
int mwifiex_add_card(void *card, struct semaphore *sem,
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index de6939c..7942b28 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -131,6 +131,7 @@ static int mwifiex_pcie_suspend(struct device *dev)
}
adapter = card->adapter;
+ mwifiex_enable_wake(adapter);
/* Enable the Host Sleep */
if (!mwifiex_enable_hs(adapter)) {
@@ -186,6 +187,7 @@ static int mwifiex_pcie_resume(struct device *dev)
mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
MWIFIEX_ASYNC_CMD);
+ mwifiex_disable_wake(adapter);
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index c95f41f..7055282 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -79,67 +79,18 @@
{ }
};
-static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
-{
- struct mwifiex_plt_wake_cfg *cfg = priv;
-
- if (cfg->irq_wifi >= 0) {
- pr_info("%s: wake by wifi", __func__);
- cfg->wake_by_wifi = true;
- disable_irq_nosync(irq);
- }
-
- /* Notify PM core we are wakeup source */
- pm_wakeup_event(cfg->dev, 0);
-
- return IRQ_HANDLED;
-}
-
/* This function parse device tree node using mmc subnode devicetree API.
* The device node is saved in card->plt_of_node.
* if the device tree node exist and include interrupts attributes, this
* function will also request platform specific wakeup interrupt.
*/
-static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
+static int mwifiex_sdio_probe_of(struct device *dev)
{
- struct mwifiex_plt_wake_cfg *cfg;
- int ret;
-
if (!of_match_node(mwifiex_sdio_of_match_table, dev->of_node)) {
dev_err(dev, "required compatible string missing\n");
return -EINVAL;
}
- card->plt_of_node = dev->of_node;
- card->plt_wake_cfg = devm_kzalloc(dev, sizeof(*card->plt_wake_cfg),
- GFP_KERNEL);
- cfg = card->plt_wake_cfg;
- if (cfg && card->plt_of_node) {
- cfg->dev = dev;
- cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
- if (!cfg->irq_wifi) {
- dev_dbg(dev,
- "fail to parse irq_wifi from device tree\n");
- } else {
- ret = devm_request_irq(dev, cfg->irq_wifi,
- mwifiex_wake_irq_wifi,
- IRQF_TRIGGER_LOW,
- "wifi_wake", cfg);
- if (ret) {
- dev_dbg(dev,
- "Failed to request irq_wifi %d (%d)\n",
- cfg->irq_wifi, ret);
- card->plt_wake_cfg = NULL;
- return 0;
- }
- disable_irq(cfg->irq_wifi);
- }
- }
-
- ret = device_init_wakeup(dev, true);
- if (ret)
- dev_err(dev, "fail to init wakeup for mwifiex");
-
return 0;
}
@@ -198,11 +149,9 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
/* device tree node parsing and platform specific configuration*/
if (func->dev.of_node) {
- ret = mwifiex_sdio_probe_of(&func->dev, card);
- if (ret) {
- dev_err(&func->dev, "SDIO dt node parse failed\n");
+ ret = mwifiex_sdio_probe_of(&func->dev);
+ if (ret)
goto err_disable;
- }
}
ret = mwifiex_add_card(card, &add_remove_card_sem, &sdio_ops,
@@ -267,12 +216,7 @@ static int mwifiex_sdio_resume(struct device *dev)
mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
MWIFIEX_SYNC_CMD);
- /* Disable platform specific wakeup interrupt */
- if (card->plt_wake_cfg && card->plt_wake_cfg->irq_wifi >= 0) {
- disable_irq_wake(card->plt_wake_cfg->irq_wifi);
- if (!card->plt_wake_cfg->wake_by_wifi)
- disable_irq(card->plt_wake_cfg->irq_wifi);
- }
+ mwifiex_disable_wake(adapter);
return 0;
}
@@ -352,13 +296,7 @@ static int mwifiex_sdio_suspend(struct device *dev)
}
adapter = card->adapter;
-
- /* Enable platform specific wakeup interrupt */
- if (card->plt_wake_cfg && card->plt_wake_cfg->irq_wifi >= 0) {
- card->plt_wake_cfg->wake_by_wifi = false;
- enable_irq(card->plt_wake_cfg->irq_wifi);
- enable_irq_wake(card->plt_wake_cfg->irq_wifi);
- }
+ mwifiex_enable_wake(adapter);
/* Enable the Host Sleep */
if (!mwifiex_enable_hs(adapter)) {
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index 07cdd23..b9fbc5c 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -154,12 +154,6 @@
a->mpa_rx.start_port = 0; \
} while (0)
-struct mwifiex_plt_wake_cfg {
- struct device *dev;
- int irq_wifi;
- bool wake_by_wifi;
-};
-
/* data structure for SDIO MPA TX */
struct mwifiex_sdio_mpa_tx {
/* multiport tx aggregation buffer pointer */
@@ -243,8 +237,6 @@ struct mwifiex_sdio_card_reg {
struct sdio_mmc_card {
struct sdio_func *func;
struct mwifiex_adapter *adapter;
- struct device_node *plt_of_node;
- struct mwifiex_plt_wake_cfg *plt_wake_cfg;
const char *firmware;
const struct mwifiex_sdio_card_reg *reg;
--
1.9.1
^ permalink raw reply related
* [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption
From: Stam, Michel @ 2016-11-14 12:50 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <1477580802.4534.20.camel@sipsolutions.net>
Dear List,
After 2 weeks of Ferry Huberts and me trying to resolve this issue, this is the result:
The problem can be mitigated by resetting the chip and immediately replumbing the encryption keys. I wrote a patch for this, which unfortunately this seems to suffer from some locking issues, rtnl_lock and sc->mutex being the chief culprits.
Code snippet:
static void ath9k_plumb_key(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta,
struct ieee80211_key_conf *keyconf, void *data)
{
struct ath_common *common = (struct ath_common *)data;
int ret;
/* delete and re-install keys which were programmed into the hardware */
if (vif && test_bit(keyconf->hw_key_idx, common->keymap)) {
ath_key_delete(common, keyconf);
keyconf->hw_key_idx = 0;
ret = ath_key_config(common, vif, sta, keyconf);
if (ret >= 0)
keyconf->hw_key_idx = ret;
}
}
To reset and replumb, taken from ath_reset_internal():
ath9k_hw_kill_interrupts(sc->sc_ah);
set_bit(ATH_OP_HW_RESET, &common->op_flags);
ath9k_ps_wakeup(sc);
ath_reset_internal(sc, NULL);
rtnl_lock();
ieee80211_iter_keys(sc->hw, NULL, ath9k_plumb_key, common);
rtnl_unlock();
ath9k_ps_restore(sc);
In any case, the problem is only mitigated. It is not solved, as I see the error appearing still (less frequently though).
Looking at the OpenHAL has not yielded anything working either (there is a reference to KEY_PLUMB_WAR, but it is not a full implementation).
What I understand from previous attempts to tackle this issue is that Qualcomm is aware of the problem, and a workaround exists in at least the proprietary driver. I have tried to contact Qualcomm support about this, since it is not radio card specific, but I have not received any response so far.
I hope a Qualcomm employee reads this and is able to help obtain the information that is necessary to resolve this issue. Until then, I recommend using software encryption (nohwcrypt), or setting a very long rekeying time.
Kind regards,
Michel Stam
-----Original Message-----
From: ath9k-devel-bounces@lists.ath9k.org [mailto:ath9k-devel-bounces at lists.ath9k.org] On Behalf Of Johannes Berg
Sent: Thursday, October 27, 2016 17:07 PM
To: Sebastian Gottschall; Kalle Valo; Antonio Quartulli
Cc: ath9k-devel at lists.ath9k.org; linux-wireless at vger.kernel.org; Antonio Quartulli
Subject: Re: [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption
On Thu, 2016-10-27 at 09:54 +0200, Sebastian Gottschall wrote:
> all patches have a unclear license since most patches are not comming
> with any licence declaration ;-)
You should read the DCO some time. Maybe you shouldn't be sending
patches if you think so.
johannes
_______________________________________________
ath9k-devel mailing list
ath9k-devel at lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
^ permalink raw reply
* RE: [bug report] iwlwifi: mvm: use dev_coredumpsg()
From: Erenfeld, Aviya @ 2016-11-14 12:51 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-wireless@vger.kernel.org, Berg, Johannes
In-Reply-To: <20161114112039.GA21931@mwanda>
Thanks,
Right, we already have a pending fix for that one.
Aviya
-----Original Message-----
From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
Sent: Monday, November 14, 2016 13:21
To: Erenfeld, Aviya <aviya.erenfeld@intel.com>
Cc: linux-wireless@vger.kernel.org
Subject: [bug report] iwlwifi: mvm: use dev_coredumpsg()
Hello Aviya Erenfeld,
The patch 7e62a699aafb: "iwlwifi: mvm: use dev_coredumpsg()" from Sep 20, 2016, leads to the following static checker warning:
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c:821 iwl_mvm_fw_error_dump()
error: we previously assumed 'fw_error_dump->trans_ptr' could be null (see line 809)
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
805 dump_trans_data:
806 fw_error_dump->trans_ptr = iwl_trans_dump_data(mvm->trans,
807 mvm->fw_dump_trig);
808 fw_error_dump->op_mode_len = file_len;
809 if (fw_error_dump->trans_ptr)
810 file_len += fw_error_dump->trans_ptr->len;
We assume ->trans_ptr can be NULL.
811 dump_file->file_len = cpu_to_le32(file_len);
812
813 sg_dump_data = alloc_sgtable(file_len);
That probably means file_len is zero? (didn't look). That means sg_dump_data is ZERO_SIZE_PTR (16).
814 if (sg_dump_data) {
815 sg_pcopy_from_buffer(sg_dump_data,
816 sg_nents(sg_dump_data),
817 fw_error_dump->op_mode_ptr,
818 fw_error_dump->op_mode_len, 0);
819 sg_pcopy_from_buffer(sg_dump_data,
820 sg_nents(sg_dump_data),
821 fw_error_dump->trans_ptr->data,
Leading to an oops.
822 fw_error_dump->trans_ptr->len,
823 fw_error_dump->op_mode_len);
824 dev_coredumpsg(mvm->trans->dev, sg_dump_data, file_len,
825 GFP_KERNEL);
826 }
827 vfree(fw_error_dump->op_mode_ptr);
828 vfree(fw_error_dump->trans_ptr);
829 kfree(fw_error_dump);
830
831 out:
832 iwl_mvm_free_fw_dump_desc(mvm);
833 mvm->fw_dump_trig = NULL;
834 clear_bit(IWL_MVM_STATUS_DUMPING_FW_LOG, &mvm->status);
835 }
regards,
dan carpenter
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* Re: PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-14 12:51 UTC (permalink / raw)
To: Jacek Anaszewski, Jacek Anaszewski, Pavel Machek
Cc: Tony Lindgren, linux-leds, linux-omap, linux-arm-kernel,
linux-kernel, Darren Hart
In-Reply-To: <127cdd42-6fd8-c671-60b7-3826b351577f@samsung.com>
Hi,
On 14-11-16 10:12, Jacek Anaszewski wrote:
> Hi,
>
> On 11/13/2016 02:52 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 13-11-16 12:44, Jacek Anaszewski wrote:
>>> Hi,
>>>
>>> On 11/12/2016 10:14 PM, Hans de Goede wrote:
>>
>> <snip>
>>
>>>>>> So I would like to propose creating a new read-write
>>>>>> user_brightness file.
>>>>>>
>>>>>> The write behavior would be 100% identical to the brightness
>>>>>> file (in code terms it will call the same store function).
>>>>>>
>>>>>> The the read behavior otoh will be different: it will shows
>>>>>> the last brightness as set by the user, this would show the
>>>>>> read behavior we really want of brightness: show the real
>>>>>> brightness when not blinking / triggers are active and show
>>>>>> the brightness used when on when blinking / triggers are active.
>>>>>>
>>>>>> We could then add poll support on this new user_brightness
>>>>>> file, thus avoiding the problem with the extra cpu-load on
>>>>>> notifications on blinking / triggers.
>>>>>
>>>>> I agree that user_brightness allows to solve the issues you raised
>>>>> about inconsistent write and read brightness' semantics
>>>>> (which is not that painful IMHO).
>>>>>
>>>>> Reporting non-user brightness changes on user_brightness file
>>>>> doesn't sound reasonable though.
>>>>
>>>> The changes I'm interested in are user brightness changes they
>>>> are just not done through sysfs, but through a hardwired hotkey,
>>>> they are however very much done by the user.
>>>
>>> Ah, so this file name would be misleading especially taking into account
>>> the context in which "user" is used in kernel, which predominantly
>>> means "userspace", e.g. copy_to_user(), copy_from_user().
>>>
>>>>> Also, how would we read the
>>>>> brightness set by the firmware? We'd have to read brightness
>>>>> file, so still two files would have to be opened which is
>>>>> a second drawback of this approach.
>>>>
>>>> No, look carefully at the definition of the read behavior
>>>> I plan to put in the ABI doc:
>>>
>>> OK, "user" was what confused me. So in this case changes made
>>> by the firmware even if in a result of user activity
>>> (pressing hardware key) obviously cannot be treated similarly
>>> to the changes made from the userspace context.
>>
>> In the end both result on the brightness of the device
>> changing, so any userspace process interested in monitoring
>> the brightness will want to know about both type of changes.
>>
>>> Unless you're able to give references to the kernel code which
>>> contradict my judgement.
>>
>> AFAIK the audio code will signal volume changes done by
>> hardwired buttons the same way as audio changes done
>> by userspace calling into the kernel. This also makes
>> sense because in the end, what is interesting for a
>> mixer app, is that the volume changed, and what the
>> new volume is.
>
> OK, so it is indeed similar to your LED use case. Nonetheless
> in case of LED controllers it is also possible that hardware
> adjusts LED brightness in case of low battery voltage.
>
> If a device is able e.g. to generate an interrupt to notify this
> kind of event, then we would like also to be able to notify the client
> about that. It wouldn't be user generated brightness change though.
>
>>>> "Reading this file will return the actual led brightness
>>>> when not blinking and no triggers are active; reading this
>>>> file will return the brightness used when the led is on
>>>> when blinking or triggers are active."
>>>
>>> This is unnecessarily entangled. Blinking means timer trigger
>>> is active.
>>
>> Ok.
>>
>>>> So for e.g. the backlit keyboard case reading this single
>>>> file will return the actual brightness of the backlight,
>>>> since this does not involve blinking or triggers.
>>>>
>>>> Basically the idea is that the user_brightness file
>>>> will have the semantics which IMHO the brightness file
>>>> itself should have had from the beginning, but which
>>>> we can't change now due to ABI reasons.
>>>
>>> And in fact introducing user_brightness file would indeed
>>> fix that shortcoming. However without providing notifications
>>> of hw brightness changes on it.
>>
>> See above, I believe such a file should report any
>> changes in brightness, except those caused by triggers,
>> so it would report hw brightness changes.
>>
>> Anyways if you're not interested in fixing the
>> shortcomings of the current read behavior on the
>> brightness file (I'm fine with that, I can live
>> with the shortcomings) I suggest that we simply go
>> with v2 of my poll() patch.
>
> v2 entails power consumption related issues.
>
> Generally I think that we could add the file you proposed,
> however it would be good to devise a name which will cover
> also the cases when brightness is changed by firmware without
> user interaction.
>
>>>>> Having no difference in this area between the two approaches
>>>>> I'm still in favour of the read-only file for notifying
>>>>> brightness changes procured by hardware.
>>>>
>>>> That brings back the needing 2 fds problem; and does
>>>> not solve userspace not being able to reliably read
>>>> the led on brightness when blinking or using triggers.
>>>>
>>>> And this also has the issue that one is doing poll() on
>>>> one fd to detect changes on another fd,
>>>
>>> It is not necessarily true. We can treat the polling on
>>> hw_brightness_change file as a means to detect brightness
>>> changes procured by hardware and we can read that brightness
>>> by executing read on this same fd. It could return -ENODATA
>>> if no such an event has occurred so far.
>>
>> That would still require 2 fds as userspace also wants to
>> be able to set the keyboard backlight, but allowing read()
>> on the hw_brightness_change file at least fixes the weirdness
>> where userspace gets woken from poll() without being able to
>> read. So if you insist on going the hw_brightness_change file
>> route, then I can live with that (and upower will simply
>> need to open 2 fds, that is doable).
>>
>> But, BUT, I would greatly prefer to just go for v4 of my
>> patch, which fixes the only real problem we've seen with
>> my patch as original merged without adding a new, somewhat
>> convoluted sysfs attribute.
>
> Hmm, v4 still calls led_notify_brightness_change(led_cdev)
> from both __led_set_brightness() and __led_set_brightness_blocking().
Ugh, I see I accidentally send a v4 twice, instead of
calling the version which dropped those called v5 as
I should have, sorry.
The v4 which I would like to see merged, the one with
those calls dropped, is here:
https://patchwork.kernel.org/patch/9423093/
Regards,
Hans
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-14 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <127cdd42-6fd8-c671-60b7-3826b351577f@samsung.com>
Hi,
On 14-11-16 10:12, Jacek Anaszewski wrote:
> Hi,
>
> On 11/13/2016 02:52 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 13-11-16 12:44, Jacek Anaszewski wrote:
>>> Hi,
>>>
>>> On 11/12/2016 10:14 PM, Hans de Goede wrote:
>>
>> <snip>
>>
>>>>>> So I would like to propose creating a new read-write
>>>>>> user_brightness file.
>>>>>>
>>>>>> The write behavior would be 100% identical to the brightness
>>>>>> file (in code terms it will call the same store function).
>>>>>>
>>>>>> The the read behavior otoh will be different: it will shows
>>>>>> the last brightness as set by the user, this would show the
>>>>>> read behavior we really want of brightness: show the real
>>>>>> brightness when not blinking / triggers are active and show
>>>>>> the brightness used when on when blinking / triggers are active.
>>>>>>
>>>>>> We could then add poll support on this new user_brightness
>>>>>> file, thus avoiding the problem with the extra cpu-load on
>>>>>> notifications on blinking / triggers.
>>>>>
>>>>> I agree that user_brightness allows to solve the issues you raised
>>>>> about inconsistent write and read brightness' semantics
>>>>> (which is not that painful IMHO).
>>>>>
>>>>> Reporting non-user brightness changes on user_brightness file
>>>>> doesn't sound reasonable though.
>>>>
>>>> The changes I'm interested in are user brightness changes they
>>>> are just not done through sysfs, but through a hardwired hotkey,
>>>> they are however very much done by the user.
>>>
>>> Ah, so this file name would be misleading especially taking into account
>>> the context in which "user" is used in kernel, which predominantly
>>> means "userspace", e.g. copy_to_user(), copy_from_user().
>>>
>>>>> Also, how would we read the
>>>>> brightness set by the firmware? We'd have to read brightness
>>>>> file, so still two files would have to be opened which is
>>>>> a second drawback of this approach.
>>>>
>>>> No, look carefully at the definition of the read behavior
>>>> I plan to put in the ABI doc:
>>>
>>> OK, "user" was what confused me. So in this case changes made
>>> by the firmware even if in a result of user activity
>>> (pressing hardware key) obviously cannot be treated similarly
>>> to the changes made from the userspace context.
>>
>> In the end both result on the brightness of the device
>> changing, so any userspace process interested in monitoring
>> the brightness will want to know about both type of changes.
>>
>>> Unless you're able to give references to the kernel code which
>>> contradict my judgement.
>>
>> AFAIK the audio code will signal volume changes done by
>> hardwired buttons the same way as audio changes done
>> by userspace calling into the kernel. This also makes
>> sense because in the end, what is interesting for a
>> mixer app, is that the volume changed, and what the
>> new volume is.
>
> OK, so it is indeed similar to your LED use case. Nonetheless
> in case of LED controllers it is also possible that hardware
> adjusts LED brightness in case of low battery voltage.
>
> If a device is able e.g. to generate an interrupt to notify this
> kind of event, then we would like also to be able to notify the client
> about that. It wouldn't be user generated brightness change though.
>
>>>> "Reading this file will return the actual led brightness
>>>> when not blinking and no triggers are active; reading this
>>>> file will return the brightness used when the led is on
>>>> when blinking or triggers are active."
>>>
>>> This is unnecessarily entangled. Blinking means timer trigger
>>> is active.
>>
>> Ok.
>>
>>>> So for e.g. the backlit keyboard case reading this single
>>>> file will return the actual brightness of the backlight,
>>>> since this does not involve blinking or triggers.
>>>>
>>>> Basically the idea is that the user_brightness file
>>>> will have the semantics which IMHO the brightness file
>>>> itself should have had from the beginning, but which
>>>> we can't change now due to ABI reasons.
>>>
>>> And in fact introducing user_brightness file would indeed
>>> fix that shortcoming. However without providing notifications
>>> of hw brightness changes on it.
>>
>> See above, I believe such a file should report any
>> changes in brightness, except those caused by triggers,
>> so it would report hw brightness changes.
>>
>> Anyways if you're not interested in fixing the
>> shortcomings of the current read behavior on the
>> brightness file (I'm fine with that, I can live
>> with the shortcomings) I suggest that we simply go
>> with v2 of my poll() patch.
>
> v2 entails power consumption related issues.
>
> Generally I think that we could add the file you proposed,
> however it would be good to devise a name which will cover
> also the cases when brightness is changed by firmware without
> user interaction.
>
>>>>> Having no difference in this area between the two approaches
>>>>> I'm still in favour of the read-only file for notifying
>>>>> brightness changes procured by hardware.
>>>>
>>>> That brings back the needing 2 fds problem; and does
>>>> not solve userspace not being able to reliably read
>>>> the led on brightness when blinking or using triggers.
>>>>
>>>> And this also has the issue that one is doing poll() on
>>>> one fd to detect changes on another fd,
>>>
>>> It is not necessarily true. We can treat the polling on
>>> hw_brightness_change file as a means to detect brightness
>>> changes procured by hardware and we can read that brightness
>>> by executing read on this same fd. It could return -ENODATA
>>> if no such an event has occurred so far.
>>
>> That would still require 2 fds as userspace also wants to
>> be able to set the keyboard backlight, but allowing read()
>> on the hw_brightness_change file at least fixes the weirdness
>> where userspace gets woken from poll() without being able to
>> read. So if you insist on going the hw_brightness_change file
>> route, then I can live with that (and upower will simply
>> need to open 2 fds, that is doable).
>>
>> But, BUT, I would greatly prefer to just go for v4 of my
>> patch, which fixes the only real problem we've seen with
>> my patch as original merged without adding a new, somewhat
>> convoluted sysfs attribute.
>
> Hmm, v4 still calls led_notify_brightness_change(led_cdev)
> from both __led_set_brightness() and __led_set_brightness_blocking().
Ugh, I see I accidentally send a v4 twice, instead of
calling the version which dropped those called v5 as
I should have, sorry.
The v4 which I would like to see merged, the one with
those calls dropped, is here:
https://patchwork.kernel.org/patch/9423093/
Regards,
Hans
^ permalink raw reply
* [PATCH] drm/amdgpu:impl vgt_flush for VI(V3)
From: Monk Liu @ 2016-11-14 12:52 UTC (permalink / raw)
To: amd-gfx-CC+yJ3UmIYqDUpFQwHEjaQ; +Cc: Monk Liu
when shadowing enabled, tesselation app will trigger
vm fault because below three tesselation registers:
VGT_TF_RING_SIZE__CI__VI,
VGT_HS_OFFCHIP_PARAM__CI__VI,
VGT_TF_MEMORY_BASE__CI__VI,
need to be programed after vgt-flush.
Tesselation picture vm fault disappeared after vgt-flush
introduced.
v2:implement vgt-flush for CI & SI.
v3:move vgt flush inside of cntx_cntrl
Change-Id: I77d87d93ce6580e559e734fb41d97ee8c59d245b
Signed-off-by: Monk Liu <Monk.Liu@amd.com>
---
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 9 +++++++++
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 13 +++++++++++++
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 13 +++++++++++++
3 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
index 9423501..0aacd36 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
@@ -1463,6 +1463,13 @@ static void gfx_v6_0_ring_emit_hdp_flush(struct amdgpu_ring *ring)
amdgpu_ring_write(ring, 0x1);
}
+static void gfx_v6_0_ring_emit_vgt_flush(struct amdgpu_ring *ring)
+{
+ amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
+ amdgpu_ring_write(ring, EVENT_TYPE(VGT_FLUSH) |
+ EVENT_INDEX(0));
+}
+
/**
* gfx_v6_0_ring_emit_hdp_invalidate - emit an hdp invalidate on the cp
*
@@ -2802,6 +2809,8 @@ static uint64_t gfx_v6_0_get_gpu_clock_counter(struct amdgpu_device *adev)
static void gfx_v6_ring_emit_cntxcntl(struct amdgpu_ring *ring, uint32_t flags)
{
+ if (flags & AMDGPU_HAVE_CTX_SWITCH) {
+ gfx_v6_0_ring_emit_vgt_flush(ring);
amdgpu_ring_write(ring, PACKET3(PACKET3_CONTEXT_CONTROL, 1));
amdgpu_ring_write(ring, 0x80000000);
amdgpu_ring_write(ring, 0);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index bd9a6c8..493d889 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -2105,6 +2105,18 @@ static void gfx_v7_0_ring_emit_hdp_flush(struct amdgpu_ring *ring)
amdgpu_ring_write(ring, 0x20); /* poll interval */
}
+static void gfx_v7_0_ring_emit_vgt_flush(struct amdgpu_ring *ring)
+{
+ amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
+ amdgpu_ring_write(ring, EVENT_TYPE(VS_PARTIAL_FLUSH) |
+ EVENT_INDEX(4));
+
+ amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
+ amdgpu_ring_write(ring, EVENT_TYPE(VGT_FLUSH) |
+ EVENT_INDEX(0));
+}
+
+
/**
* gfx_v7_0_ring_emit_hdp_invalidate - emit an hdp invalidate on the cp
*
@@ -2260,6 +2272,7 @@ static void gfx_v7_ring_emit_cntxcntl(struct amdgpu_ring *ring, uint32_t flags)
dw2 |= 0x80000000; /* set load_enable otherwise this package is just NOPs */
if (flags & AMDGPU_HAVE_CTX_SWITCH) {
+ gfx_v7_0_ring_emit_vgt_flush(ring);
/* set load_global_config & load_global_uconfig */
dw2 |= 0x8001;
/* set load_cs_sh_regs */
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 9017803..d52f458 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -6187,6 +6187,18 @@ static void gfx_v8_0_ring_emit_hdp_flush(struct amdgpu_ring *ring)
amdgpu_ring_write(ring, 0x20); /* poll interval */
}
+static void gfx_v8_0_ring_emit_vgt_flush(struct amdgpu_ring *ring)
+{
+ amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
+ amdgpu_ring_write(ring, EVENT_TYPE(VS_PARTIAL_FLUSH) |
+ EVENT_INDEX(4));
+
+ amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
+ amdgpu_ring_write(ring, EVENT_TYPE(VGT_FLUSH) |
+ EVENT_INDEX(0));
+}
+
+
static void gfx_v8_0_ring_emit_hdp_invalidate(struct amdgpu_ring *ring)
{
amdgpu_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
@@ -6372,6 +6384,7 @@ static void gfx_v8_ring_emit_cntxcntl(struct amdgpu_ring *ring, uint32_t flags)
dw2 |= 0x80000000; /* set load_enable otherwise this package is just NOPs */
if (flags & AMDGPU_HAVE_CTX_SWITCH) {
+ gfx_v8_0_ring_emit_vgt_flush(ring);
/* set load_global_config & load_global_uconfig */
dw2 |= 0x8001;
/* set load_cs_sh_regs */
--
1.9.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* [PATCH] gpio: intel-mid: use builtin_pci_driver
From: Geliang Tang @ 2016-11-14 12:52 UTC (permalink / raw)
To: David Cohen, Linus Walleij, Alexandre Courbot
Cc: Geliang Tang, linux-gpio, linux-kernel
Use builtin_pci_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
drivers/gpio/gpio-intel-mid.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-intel-mid.c b/drivers/gpio/gpio-intel-mid.c
index 164de64..a1e44c2 100644
--- a/drivers/gpio/gpio-intel-mid.c
+++ b/drivers/gpio/gpio-intel-mid.c
@@ -421,9 +421,4 @@ static struct pci_driver intel_gpio_driver = {
},
};
-static int __init intel_gpio_init(void)
-{
- return pci_register_driver(&intel_gpio_driver);
-}
-
-device_initcall(intel_gpio_init);
+builtin_pci_driver(intel_gpio_driver);
--
2.9.3
^ permalink raw reply related
* [PATCH] xen-platform: use builtin_pci_driver
From: Geliang Tang @ 2016-11-14 12:52 UTC (permalink / raw)
To: Boris Ostrovsky, David Vrabel, Juergen Gross
Cc: Geliang Tang, linux-kernel, xen-devel
In-Reply-To: <1f356ef29486a21e77e00997bcc82b300d0512d6.1479127743.git.geliangtang@gmail.com>
Use builtin_pci_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
drivers/xen/platform-pci.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index b59c9455..112ce42 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -125,8 +125,4 @@ static struct pci_driver platform_driver = {
.id_table = platform_pci_tbl,
};
-static int __init platform_pci_init(void)
-{
- return pci_register_driver(&platform_driver);
-}
-device_initcall(platform_pci_init);
+builtin_pci_driver(platform_driver);
--
2.9.3
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH] xen-platform: use builtin_pci_driver
From: Geliang Tang @ 2016-11-14 12:52 UTC (permalink / raw)
To: Boris Ostrovsky, David Vrabel, Juergen Gross
Cc: Geliang Tang, xen-devel, linux-kernel
In-Reply-To: <1f356ef29486a21e77e00997bcc82b300d0512d6.1479127743.git.geliangtang@gmail.com>
Use builtin_pci_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
drivers/xen/platform-pci.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index b59c9455..112ce42 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -125,8 +125,4 @@ static struct pci_driver platform_driver = {
.id_table = platform_pci_tbl,
};
-static int __init platform_pci_init(void)
-{
- return pci_register_driver(&platform_driver);
-}
-device_initcall(platform_pci_init);
+builtin_pci_driver(platform_driver);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v7 2/2] media: Add a driver for the ov5645 camera sensor.
From: Todor Tomov @ 2016-11-14 12:53 UTC (permalink / raw)
To: Laurent Pinchart
Cc: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, mchehab,
hverkuil, geert, matrandg, sakari.ailus, linux-media
In-Reply-To: <5871917.9Xm98D97nL@avalon>
Hi Laurent,
Thank you once again for the review.
On 11/14/2016 02:38 PM, Laurent Pinchart wrote:
> Hi Todor,
>
> Thank you for the patch.
>
> On Monday 14 Nov 2016 12:24:36 Todor Tomov wrote:
>> The ov5645 sensor from Omnivision supports up to 2592x1944
>> and CSI2 interface.
>>
>> The driver adds support for the following modes:
>> - 1280x960
>> - 1920x1080
>> - 2592x1944
>>
>> Output format is packed 8bit UYVY.
>>
>> Signed-off-by: Todor Tomov <todor.tomov@linaro.org>
>> ---
>> drivers/media/i2c/Kconfig | 12 +
>> drivers/media/i2c/Makefile | 1 +
>> drivers/media/i2c/ov5645.c | 1352 +++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 1365 insertions(+)
>> create mode 100644 drivers/media/i2c/ov5645.c
>
> [snip]
>
>> diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
>> new file mode 100644
>> index 0000000..2b33bc6
>> --- /dev/null
>> +++ b/drivers/media/i2c/ov5645.c
>
> [snip]
>
>> +static const struct ov5645_mode_info *
>> +ov5645_find_nearest_mode(unsigned int width, unsigned int height)
>> +{
>> + unsigned int i;
>> +
>> + for (i = ARRAY_SIZE(ov5645_mode_info_data) - 1; i >= 0; i--) {
>> + if (ov5645_mode_info_data[i].width <= width &&
>> + ov5645_mode_info_data[i].height <= height)
>> + break;
>> + }
>> +
>> + if (i < 0)
>
> i needs to be int for this condition to be true.
Oops, I'll fix this for the next version. Let's wait for other feedback too until then.
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
>> + i = 0;
>> +
>> + return &ov5645_mode_info_data[i];
>> +}
>
--
Best regards,
Todor Tomov
^ permalink raw reply
* Re: [PATCH] x86/memshr: properly check grant references
From: Jan Beulich @ 2016-11-14 12:56 UTC (permalink / raw)
To: Andrew Cooper
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Tim Deegan,
Ian Jackson, tamas, xen-devel
In-Reply-To: <06064a69-7cf4-366c-889c-22f0226eb51a@citrix.com>
>>> On 14.11.16 at 12:56, <andrew.cooper3@citrix.com> wrote:
> On 14/11/16 10:34, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -3438,6 +3438,53 @@ void grant_table_init_vcpu(struct vcpu *
>> v->maptrack_tail = MAPTRACK_TAIL;
>> }
>>
>> +#ifdef CONFIG_HAS_MEM_SHARING
>> +int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
>> + gfn_t *gfn, uint16_t *status)
>> +{
>> + int rc = 0;
>> + uint16_t flags = 0;
>> +
>> + grant_read_lock(gt);
>> +
>> + if ( gt->gt_version < 1 )
>> + rc = -EINVAL;
>> + else if ( ref >= nr_grant_entries(gt) )
>> + rc = -ENOENT;
>> + else if ( gt->gt_version == 1 )
>> + {
>> + const grant_entry_v1_t *sha1 = &shared_entry_v1(gt, ref);
>> +
>> + flags = sha1->flags;
>> + *gfn = _gfn(sha1->frame);
>> + }
>> + else
>> + {
>> + const grant_entry_v2_t *sha2 = &shared_entry_v2(gt, ref);
>> +
>> + flags = sha2->hdr.flags;
>> + if ( flags & GTF_sub_page )
>> + *gfn = _gfn(sha2->sub_page.frame);
>> + else
>> + *gfn = _gfn(sha2->full_page.frame);
>> + }
>> +
>> + if ( (flags & GTF_type_mask) != GTF_permit_access )
>> + rc = -ENXIO;
>
> This will clobber the EINVAL/ENOENT cases. It wants to be pared with an
> !rc &&.
Oh, indeed - thanks for noticing.
> With this fixed, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Thanks, Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: XFS_WANT_CORRUPTED_GOTO
From: Brian Foster @ 2016-11-14 12:56 UTC (permalink / raw)
To: Chris; +Cc: linux-xfs
In-Reply-To: <004eca882d70d671bce9dff6f25633cc.squirrel@mail2.postbox.xyz>
On Sat, Nov 12, 2016 at 11:52:02AM +0100, Chris wrote:
> All,
>
> I've already restored this partition from backup. Nevertheless, out of
> curiosity: maybe someone has an idea why this happened in the first place.
>
> It's an Ubuntu 14.04.4 LTS Trusty Tahr machine (3.19.0-58-generic x86_64).
> The 33 TB partition is shared by Samba, not NFS. It was created on an
> older server. I don't know the exact XFS (tools) versions used then. I
> couldn't find any issues in RAID controller or FC switch logs. Samba logs
> aren't available.
>
> The first occurence of the issue is:
>
> Nov 8 23:58:30 fs1 kernel: [17576062.991425] XFS: Internal error
> XFS_WANT_CORRUPTED_GOTO at line 3141 of file
> /build/linux-lts-vivid-GISjUd/linux-lts-vivid-3.19.0/fs/xfs/libxfs/xfs_btree.c.
This is a distro kernel and the reported line number doesn't exactly
match up with a generic v3.19 kernel. From the stack, I'm guessing that
you have free space btree corruption and thus failure to insert a freed
extent into one of the btrees. E.g., we've seen reports of such attempts
to free already freed space in older kernels.
We don't currently know what the issue is and it is a challenge because
this kind of corruption can sit latent in the filesystem for quite some
time, going undetected until you happen to remove the file that contains
the offending extent.
> Caller xfs_free_ag_extent+0x3ff/0x750 [xfs]
> Nov 8 23:58:30 fs1 kernel: [17576063.010347] CPU: 14 PID: 38238 Comm:
> smbd Not tainted 3.19.0-58-generic #64~14.04.1-Ubuntu
> Nov 8 23:58:30 fs1 kernel: [17576063.010350] Hardware name: Dell Inc.
> PowerEdge R430/0HFG24, BIOS 1.5.4 10/05/2015
> Nov 8 23:58:30 fs1 kernel: [17576063.010352] 0000000000000000
> ffff8802bc9bbad8 ffffffff817b6c3d ffff880216d1f450
> Nov 8 23:58:30 fs1 kernel: [17576063.010357] ffff880216d1f450
> ffff8802bc9bbaf8 ffffffffc06c5f2e ffffffffc0684b9f
> Nov 8 23:58:30 fs1 kernel: [17576063.010361] ffff8802bc9bbbec
> ffff8802bc9bbb78 ffffffffc069ffbb 0000000000015140
> Nov 8 23:58:30 fs1 kernel: [17576063.010365] Call Trace:
> Nov 8 23:58:30 fs1 kernel: [17576063.010375] [<ffffffff817b6c3d>]
> dump_stack+0x63/0x81
> Nov 8 23:58:30 fs1 kernel: [17576063.010409] [<ffffffffc06c5f2e>]
> xfs_error_report+0x3e/0x40 [xfs]
> Nov 8 23:58:30 fs1 kernel: [17576063.010431] [<ffffffffc0684b9f>] ?
> xfs_free_ag_extent+0x3ff/0x750 [xfs]
> Nov 8 23:58:30 fs1 kernel: [17576063.010456] [<ffffffffc069ffbb>]
> xfs_btree_insert+0x17b/0x190 [xfs]
> Nov 8 23:58:30 fs1 kernel: [17576063.010477] [<ffffffffc0684b9f>]
> xfs_free_ag_extent+0x3ff/0x750 [xfs]
> Nov 8 23:58:30 fs1 kernel: [17576063.010498] [<ffffffffc0686071>]
> xfs_free_extent+0xe1/0x110 [xfs]
> Nov 8 23:58:30 fs1 kernel: [17576063.010528] [<ffffffffc06bf19f>]
> xfs_bmap_finish+0x13f/0x190 [xfs]
> Nov 8 23:58:30 fs1 kernel: [17576063.010560] [<ffffffffc06d5a4d>]
> xfs_itruncate_extents+0x16d/0x2e0 [xfs]
> Nov 8 23:58:30 fs1 kernel: [17576063.010588] [<ffffffffc06c0134>]
> xfs_free_eofblocks+0x1d4/0x250 [xfs]
> Nov 8 23:58:30 fs1 kernel: [17576063.010617] [<ffffffffc06d5d7e>]
> xfs_release+0x9e/0x170 [xfs]
> Nov 8 23:58:30 fs1 kernel: [17576063.010645] [<ffffffffc06c7425>]
> xfs_file_release+0x15/0x20 [xfs]
> Nov 8 23:58:30 fs1 kernel: [17576063.010651] [<ffffffff811f0947>]
> __fput+0xe7/0x220
> Nov 8 23:58:30 fs1 kernel: [17576063.010656] [<ffffffff811f0ace>]
> ____fput+0xe/0x10
> Nov 8 23:58:30 fs1 kernel: [17576063.010660] [<ffffffff8109338c>]
> task_work_run+0xac/0xd0
> Nov 8 23:58:30 fs1 kernel: [17576063.010666] [<ffffffff81016007>]
> do_notify_resume+0x97/0xb0
> Nov 8 23:58:30 fs1 kernel: [17576063.010671] [<ffffffff817bea2f>]
> int_signal+0x12/0x17
> Nov 8 23:58:30 fs1 kernel: [17576063.010676] XFS (sde1):
> xfs_do_force_shutdown(0x8) called from line 135 o
> f file
> /build/linux-lts-vivid-GISjUd/linux-lts-vivid-3.19.0/fs/xfs/xfs_bmap_util.c.
> Return address = 0xfffffff
> fc06bf1d8
> Nov 8 23:58:30 fs1 kernel: [17576063.011070] XFS (sde1): Corruption of
> in-memory data detected. Shutting
> down filesystem
> Nov 8 23:58:30 fs1 kernel: [17576063.023605] XFS (sde1): Please umount
> the filesystem and rectify the prob
> lem(s)
>
> Now, the kernel thread seems to hang-up. Unmounting isn't possible. The
> following line was repeating until reboot:
>
> Nov 8 23:58:52 fs1 kernel: [17576084.848420] XFS (sde1): xfs_log_force:
> error -5 returned.
>
The hang problem is likely the EFI/EFD reference counting problem
discussed in the similarly reported issue here:
http://www.spinics.net/lists/linux-xfs/msg01937.html
In a nutshell, upgrade to a v4.3 kernel or newer to address that
problem.
> xfs_db -c "sb 0" -c "p blocksize" -c "p agblocks" -c "p agcount"
> /dev/disk/by-uuid/7f28333d-8d2e-4c13-afe0-4cf16b34a676 showed the
> following:
>
> blocksize = 4096
> agblocks = 268435455
> agcount = 33
> cache_node_purge: refcount was 1, not zero (node=0x1ceb5e0)
>
> and a warning, that v1 dirs being used. "Realtime-Bitmap-Inode and
> root-Inode (117) couldn't be read". (Machine isn't set to English. Don't
> ask.)
>
> I tried XFS-repair, but it couldn't find the first or second super block
> after four hours.
>
That sounds like something more significant is going on either with the
fs, the storage or xfs_repair has been pointed in the wrong place. The
above issue should at worst require zeroing the log, dealing with the
resulting inconsistency and rebuilding the fs btrees accurately.
I suspect it's too late to inspect what's going on there if you have
already restored from backup. In the future, you can use xfs_metadump to
capture a metadata only image of a broken fs to share with us and help
us diagnose what might have gone wrong.
> I could restore everything from backup, so it's not that important, but
> I've some similar XFS partitions on the same machine and have to avoid
> that this happens again.
>
I'd suggest to run "xfs_repair -n" on those as soon as possible to see
if they are affected by the same problem. It might also be a good idea
to run it against the fs you've restored from backup to see if it
returns and possibly get an idea on what might have caused the problem.
Brian
>
> Thank you in advance.
>
> - Chris
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] drm/amdgpu: cleanup unused iterator members for sdma v3
From: Christian König @ 2016-11-14 12:56 UTC (permalink / raw)
To: Huang Rui, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Alex Deucher
In-Reply-To: <1479127619-23643-1-git-send-email-ray.huang-5C7GfCeVMHo@public.gmane.org>
Am 14.11.2016 um 13:46 schrieb Huang Rui:
> Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com> for both.
> ---
> drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> index c5719a1..373ae70 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> @@ -987,7 +987,7 @@ static void sdma_v3_0_vm_write_pte(struct amdgpu_ib *ib, uint64_t pe,
> ib->ptr[ib->length_dw++] = lower_32_bits(pe);
> ib->ptr[ib->length_dw++] = upper_32_bits(pe);
> ib->ptr[ib->length_dw++] = ndw;
> - for (; ndw > 0; ndw -= 2, --count, pe += 8) {
> + for (; ndw > 0; ndw -= 2) {
> ib->ptr[ib->length_dw++] = lower_32_bits(value);
> ib->ptr[ib->length_dw++] = upper_32_bits(value);
> value += incr;
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* [PATCH 1/2] ARM: always store CPU ID early into percpu data
From: Russell King @ 2016-11-14 12:57 UTC (permalink / raw)
To: linux-arm-kernel
Always store the CPU ID into the percpu data so that it is available
early on. This allows us to eliminate various is_smp() tests that
select between reading the hardware CPU ID directly and reading from
the percpu data.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/smp_plat.h | 5 +----
arch/arm/kernel/setup.c | 5 ++++-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index f9080717fc88..43f246b73ce7 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -34,10 +34,7 @@ static inline bool is_smp(void)
*/
static inline unsigned int smp_cpuid_part(int cpu)
{
- struct cpuinfo_arm *cpu_info = &per_cpu(cpu_data, cpu);
-
- return is_smp() ? cpu_info->cpuid & ARM_CPU_PART_MASK :
- read_cpuid_part();
+ return per_cpu(cpu_data, cpu).cpuid;
}
/* all SMP configurations have the extended CPUID registers */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 34e3f3c45634..80f45b01fbaa 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -724,6 +724,9 @@ static void __init setup_processor(void)
cacheid_init();
cpu_init();
+
+ /* Always setup the boot CPU ID in the per-cpu data */
+ per_cpu(cpu_data, smp_processor_id()).cpuid = read_cpuid_id();
}
void __init dump_machine_table(void)
@@ -1217,7 +1220,7 @@ static int c_show(struct seq_file *m, void *v)
* "processor". Give glibc what it expects.
*/
seq_printf(m, "processor\t: %d\n", i);
- cpuid = is_smp() ? per_cpu(cpu_data, i).cpuid : read_cpuid_id();
+ cpuid = per_cpu(cpu_data, i).cpuid;
seq_printf(m, "model name\t: %s rev %d (%s)\n",
cpu_name, cpuid & 15, elf_platform);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: rename is_smp()
From: Russell King @ 2016-11-14 12:57 UTC (permalink / raw)
To: linux-arm-kernel
is_smp() is causing some confusion - rename it to indicate that it's a
property of the CPU that we're running on, which is not the same as the
system. Document what and why it is being used at most sites.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
Some people are reporting that "is_smp()" is broken wrt Cortex-A15 CPUs
when they integrate a single Cortex-A15 SMP capable CPU into a
uniprocessor system. This is most likely because of a misunderstanding
about what is_smp() is really detected from: it's detected from the CPU
capabilities, not from the system capabilities. If the CPU says that it
is SMP capable (and it's not a broken Cortex-A9 core) we will make use
of various instructions which appear on SMP cores, and we set is_smp()
to follow that. So, is_smp() is more of a CPU capability rather than a
system capability.
Trying to use it as a system capability will lead to problems.
Arguably, the use of it in arch_irq_work_has_interrupt() is wrong,
because we don't know whether the GIC is SMP capable or not, but it's
currently the best we can do.
I felt the other two sites I left undocumented (which read the MPIDR)
were rather obvious - a uniprocessor only capable CPU doesn't have a
MPIDR.
Really, !cpu_smp() is an indication that the CPU is UP-only, not that
it is _S_MP capable, so even this is lightly misleading. I suppose
we could replace it with cpu_up_only() but I think that makes the code
harder to understand (due to double-negatives appearing in places.)
arch/arm/include/asm/cputype.h | 2 +-
arch/arm/include/asm/irq_work.h | 2 +-
arch/arm/include/asm/smp_plat.h | 11 +++++++----
arch/arm/kernel/devtree.c | 2 +-
arch/arm/kernel/module.c | 10 +++++++++-
arch/arm/kernel/setup.c | 7 ++++---
arch/arm/mach-mvebu/coherency.c | 4 ++--
arch/arm/mm/mmu.c | 13 ++++++++++++-
8 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 522b5feb4eaa..8c82e6b4961d 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -109,7 +109,7 @@ extern unsigned int processor_id;
/*
* The memory clobber prevents gcc 4.5 from reordering the mrc before
- * any is_smp() tests, which can cause undefined instruction aborts on
+ * any cpu_smp() tests, which can cause undefined instruction aborts on
* ARM1136 r0 due to the missing extended CP15 registers.
*/
#define read_cpuid_ext(ext_reg) \
diff --git a/arch/arm/include/asm/irq_work.h b/arch/arm/include/asm/irq_work.h
index 712d03e5973a..2dc8d7995b48 100644
--- a/arch/arm/include/asm/irq_work.h
+++ b/arch/arm/include/asm/irq_work.h
@@ -5,7 +5,7 @@
static inline bool arch_irq_work_has_interrupt(void)
{
- return is_smp();
+ return cpu_smp();
}
#endif /* _ASM_ARM_IRQ_WORK_H */
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 43f246b73ce7..bdba301d01e4 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -12,9 +12,10 @@
#include <asm/cputype.h>
/*
- * Return true if we are running on a SMP platform
+ * Return true if we are running on a CPU which supports SMP, and the
+ * kernel supports SMP.
*/
-static inline bool is_smp(void)
+static inline bool cpu_smp(void)
{
#ifndef CONFIG_SMP
return false;
@@ -43,7 +44,8 @@ static inline unsigned int smp_cpuid_part(int cpu)
#else
static inline int tlb_ops_need_broadcast(void)
{
- if (!is_smp())
+ /* Non-SMP CPUs don't need to check for broadcast */
+ if (!cpu_smp())
return 0;
return ((read_cpuid_ext(CPUID_EXT_MMFR3) >> 12) & 0xf) < 2;
@@ -55,7 +57,8 @@ static inline int tlb_ops_need_broadcast(void)
#else
static inline int cache_ops_need_broadcast(void)
{
- if (!is_smp())
+ /* Non-SMP CPUs don't need to check for broadcast */
+ if (!cpu_smp())
return 0;
return ((read_cpuid_ext(CPUID_EXT_MMFR3) >> 12) & 0xf) < 1;
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f676febbb270..19a9653df6d2 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -78,7 +78,7 @@ void __init arm_dt_init_cpu_maps(void)
struct device_node *cpu, *cpus;
int found_method = 0;
u32 i, j, cpuidx = 1;
- u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
+ u32 mpidr = cpu_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
bool bootcpu_valid = false;
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 4f14b5ce6535..0b49aa426180 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -374,12 +374,20 @@ int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
fixup_pv_table((void *)s->sh_addr, s->sh_size);
#endif
s = find_mod_section(hdr, sechdrs, ".alt.smp.init");
- if (s && !is_smp())
+ if (s && !cpu_smp()) {
+ /*
+ * Modules running on non-SMP capable CPUs must not use SMP
+ * instructions, as they may cause undefined instruction
+ * exceptions. This means we have to fix up the SMP
+ * alternatives on SMP-on-UP modules, and are unable to load
+ * modules built for SMP-only configurations.
+ */
#ifdef CONFIG_SMP_ON_UP
fixup_smp((void *)s->sh_addr, s->sh_size);
#else
return -EINVAL;
#endif
+ }
return 0;
}
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 80f45b01fbaa..cdf71941c129 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -584,7 +584,7 @@ u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
void __init smp_setup_processor_id(void)
{
int i;
- u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
+ u32 mpidr = cpu_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
u32 cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
cpu_logical_map(0) = cpu;
@@ -1112,7 +1112,8 @@ void __init setup_arch(char **cmdline_p)
arm_dt_init_cpu_maps();
psci_dt_init();
#ifdef CONFIG_SMP
- if (is_smp()) {
+ if (cpu_smp()) {
+ /* Ignore SMP on non-SMP capable CPUs */
if (!mdesc->smp_init || !mdesc->smp_init()) {
if (psci_smp_available())
smp_set_ops(&psci_smp_ops);
@@ -1124,7 +1125,7 @@ void __init setup_arch(char **cmdline_p)
}
#endif
- if (!is_smp())
+ if (!cpu_smp())
hyp_mode_check();
reserve_crashkernel();
diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index ae2a018b9305..fe4b1e15ebb8 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -216,7 +216,7 @@ static int coherency_type(void)
*
* Note that this means that on Armada 370, there is currently
* no way to use hardware I/O coherency, because even when
- * CONFIG_SMP is enabled, is_smp() returns false due to the
+ * CONFIG_SMP is enabled, cpu_smp() returns false due to the
* Armada 370 being a single-core processor. To lift this
* limitation, we would have to find a way to make the cache
* policy set to write-allocate (on all Armada SoCs), and to
@@ -226,7 +226,7 @@ static int coherency_type(void)
* where we don't know yet on which SoC we are running.
*/
- if (!is_smp())
+ if (!cpu_smp())
return COHERENCY_FABRIC_TYPE_NONE;
np = of_find_matching_node_and_match(NULL, of_coherency_table, &match);
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4001dd15818d..d3dc758d5391 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -449,11 +449,22 @@ static void __init build_mem_type_table(void)
ecc_mask = 0;
}
- if (is_smp()) {
+ if (cpu_smp()) {
+ /*
+ * SMP requires a write-allocate cache policy for proper
+ * functioning of the coherency protocol. If the CPU supports
+ * MP extensions, assume we are part of a SMP system.
+ */
if (cachepolicy != CPOLICY_WRITEALLOC) {
pr_warn("Forcing write-allocate cache policy for SMP\n");
cachepolicy = CPOLICY_WRITEALLOC;
}
+
+ /*
+ * SMP systems depend on the S bit being shared for coherency
+ * between the CPUs. However, setting this for non-SMP CPUs
+ * may result in the mappings being treated as uncached.
+ */
if (!(initial_pmd_value & PMD_SECT_S)) {
pr_warn("Forcing shared mappings for SMP\n");
initial_pmd_value |= PMD_SECT_S;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/3] [media] dvb-usb: move data_mutex to struct dvb_usb_device
From: Michael Ira Krufky @ 2016-11-14 12:57 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linus Torvalds, Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, Patrick Boettcher,
Sean Young, Jonathan McDowell
In-Reply-To: <960e3f4189b6f3011151374ea4109897ba8ebc3b.1478960480.git.mchehab@osg.samsung.com>
On Sat, Nov 12, 2016 at 9:46 AM, Mauro Carvalho Chehab
<mchehab@osg.samsung.com> wrote:
> From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>
> The data_mutex is initialized too late, as it is needed for
> each device driver's power control, causing an OOPS:
>
> dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm state.
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<ffffffff846617af>] __mutex_lock_slowpath+0x6f/0x100 PGD 0
> Oops: 0002 [#1] SMP
> Modules linked in: dvb_usb_cinergyT2(+) dvb_usb
> CPU: 0 PID: 2029 Comm: modprobe Not tainted 4.9.0-rc4-dvbmod #24
> Hardware name: FUJITSU LIFEBOOK A544/FJNBB35 , BIOS Version 1.17 05/09/2014
> task: ffff88020e943840 task.stack: ffff8801f36ec000
> RIP: 0010:[<ffffffff846617af>] [<ffffffff846617af>] __mutex_lock_slowpath+0x6f/0x100
> RSP: 0018:ffff8801f36efb10 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: ffff88021509bdc8 RCX: 00000000c0000100
> RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff88021509bdcc
> RBP: ffff8801f36efb58 R08: ffff88021f216320 R09: 0000000000100000
> R10: ffff88021f216320 R11: 00000023fee6c5a1 R12: ffff88020e943840
> R13: ffff88021509bdcc R14: 00000000ffffffff R15: ffff88021509bdd0
> FS: 00007f21adb86740(0000) GS:ffff88021f200000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 0000000215bce000 CR4: 00000000001406f0
> Stack:
> ffff88021509bdd0 0000000000000000 0000000000000000 ffffffffc0137c80
> ffff88021509bdc8 ffff8801f5944000 0000000000000001 ffffffffc0136b00
> ffff880213e52000 ffff88021509bdc8 ffffffff84661856 ffff88021509bd80
> Call Trace:
> [<ffffffff84661856>] ? mutex_lock+0x16/0x25
> [<ffffffffc013616f>] ? cinergyt2_power_ctrl+0x1f/0x60 [dvb_usb_cinergyT2]
> [<ffffffffc012e67e>] ? dvb_usb_device_init+0x21e/0x5d0 [dvb_usb]
> [<ffffffffc0136021>] ? cinergyt2_usb_probe+0x21/0x50 [dvb_usb_cinergyT2]
> [<ffffffff844326f3>] ? usb_probe_interface+0xf3/0x2a0
> [<ffffffff8438e348>] ? driver_probe_device+0x208/0x2b0
> [<ffffffff8438e477>] ? __driver_attach+0x87/0x90
> [<ffffffff8438e3f0>] ? driver_probe_device+0x2b0/0x2b0
> [<ffffffff8438c612>] ? bus_for_each_dev+0x52/0x80
> [<ffffffff8438d983>] ? bus_add_driver+0x1a3/0x220
> [<ffffffff8438ec06>] ? driver_register+0x56/0xd0
> [<ffffffff84431527>] ? usb_register_driver+0x77/0x130
> [<ffffffffc013a000>] ? 0xffffffffc013a000
> [<ffffffff84000426>] ? do_one_initcall+0x46/0x180
> [<ffffffff840eb2c8>] ? free_vmap_area_noflush+0x38/0x70
> [<ffffffff840f3844>] ? kmem_cache_alloc+0x84/0xc0
> [<ffffffff840b802c>] ? do_init_module+0x50/0x1be
> [<ffffffff84095adb>] ? load_module+0x1d8b/0x2100
> [<ffffffff84093020>] ? find_symbol_in_section+0xa0/0xa0
> [<ffffffff84095fe9>] ? SyS_finit_module+0x89/0x90
> [<ffffffff846637a0>] ? entry_SYSCALL_64_fastpath+0x13/0x94
> Code: e8 a7 1d 00 00 8b 03 83 f8 01 0f 84 97 00 00 00 48 8b 43 10 4c 8d 7b 08 48 89 63 10 4c 89 3c 24 41 be ff ff ff ff 48 89 44 24 08 <48> 89 20 4c 89 64 24 10 eb 1a 49 c7 44 24 08 02 00 00 00 c6 43 RIP [<ffffffff846617af>] __mutex_lock_slowpath+0x6f/0x100 RSP <ffff8801f36efb10>
> CR2: 0000000000000000
>
> So, move it to the struct dvb_usb_device and initialize it
> before calling the driver's callbacks.
>
> Reported-by: Jörg Otte <jrg.otte@gmail.com>
> Tested-by: Jörg Otte <jrg.otte@gmail.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Reviewed-by: Michael Ira Krufky <mkrufky@linuxtv.org>
> ---
> drivers/media/usb/dvb-usb/af9005.c | 33 ++++++++----------------
> drivers/media/usb/dvb-usb/cinergyT2-core.c | 33 ++++++++----------------
> drivers/media/usb/dvb-usb/cxusb.c | 39 ++++++++++++-----------------
> drivers/media/usb/dvb-usb/cxusb.h | 1 -
> drivers/media/usb/dvb-usb/dtt200u.c | 40 +++++++++++++-----------------
> drivers/media/usb/dvb-usb/dvb-usb-init.c | 1 +
> drivers/media/usb/dvb-usb/dvb-usb.h | 9 +++++--
> 7 files changed, 61 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb/af9005.c b/drivers/media/usb/dvb-usb/af9005.c
> index b257780fb380..7853261906b1 100644
> --- a/drivers/media/usb/dvb-usb/af9005.c
> +++ b/drivers/media/usb/dvb-usb/af9005.c
> @@ -53,7 +53,6 @@ struct af9005_device_state {
> u8 sequence;
> int led_state;
> unsigned char data[256];
> - struct mutex data_mutex;
> };
>
> static int af9005_generic_read_write(struct dvb_usb_device *d, u16 reg,
> @@ -72,7 +71,7 @@ static int af9005_generic_read_write(struct dvb_usb_device *d, u16 reg,
> return -EINVAL;
> }
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
> st->data[0] = 14; /* rest of buffer length low */
> st->data[1] = 0; /* rest of buffer length high */
>
> @@ -140,7 +139,7 @@ static int af9005_generic_read_write(struct dvb_usb_device *d, u16 reg,
> values[i] = st->data[8 + i];
>
> ret:
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
> return ret;
>
> }
> @@ -481,7 +480,7 @@ int af9005_send_command(struct dvb_usb_device *d, u8 command, u8 * wbuf,
> }
> packet_len = wlen + 5;
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
>
> st->data[0] = (u8) (packet_len & 0xff);
> st->data[1] = (u8) ((packet_len & 0xff00) >> 8);
> @@ -512,7 +511,7 @@ int af9005_send_command(struct dvb_usb_device *d, u8 command, u8 * wbuf,
> rbuf[i] = st->data[i + 7];
> }
>
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
> return ret;
> }
>
> @@ -523,7 +522,7 @@ int af9005_read_eeprom(struct dvb_usb_device *d, u8 address, u8 * values,
> u8 seq;
> int ret, i;
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
>
> memset(st->data, 0, sizeof(st->data));
>
> @@ -559,7 +558,7 @@ int af9005_read_eeprom(struct dvb_usb_device *d, u8 address, u8 * values,
> for (i = 0; i < len; i++)
> values[i] = st->data[6 + i];
> }
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
>
> return ret;
> }
> @@ -847,7 +846,7 @@ static int af9005_rc_query(struct dvb_usb_device *d, u32 * event, int *state)
> return 0;
> }
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
>
> /* deb_info("rc_query\n"); */
> st->data[0] = 3; /* rest of packet length low */
> @@ -890,7 +889,7 @@ static int af9005_rc_query(struct dvb_usb_device *d, u32 * event, int *state)
> }
>
> ret:
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
> return ret;
> }
>
> @@ -1004,20 +1003,8 @@ static struct dvb_usb_device_properties af9005_properties;
> static int af9005_usb_probe(struct usb_interface *intf,
> const struct usb_device_id *id)
> {
> - struct dvb_usb_device *d;
> - struct af9005_device_state *st;
> - int ret;
> -
> - ret = dvb_usb_device_init(intf, &af9005_properties,
> - THIS_MODULE, &d, adapter_nr);
> -
> - if (ret < 0)
> - return ret;
> -
> - st = d->priv;
> - mutex_init(&st->data_mutex);
> -
> - return 0;
> + return dvb_usb_device_init(intf, &af9005_properties,
> + THIS_MODULE, NULL, adapter_nr);
> }
>
> enum af9005_usb_table_entry {
> diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> index 8ac825413d5a..290275bc7fde 100644
> --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> @@ -42,7 +42,6 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
> struct cinergyt2_state {
> u8 rc_counter;
> unsigned char data[64];
> - struct mutex data_mutex;
> };
>
> /* We are missing a release hook with usb_device data */
> @@ -56,12 +55,12 @@ static int cinergyt2_streaming_ctrl(struct dvb_usb_adapter *adap, int enable)
> struct cinergyt2_state *st = d->priv;
> int ret;
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
> st->data[0] = CINERGYT2_EP1_CONTROL_STREAM_TRANSFER;
> st->data[1] = enable ? 1 : 0;
>
> ret = dvb_usb_generic_rw(d, st->data, 2, st->data, 64, 0);
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
>
> return ret;
> }
> @@ -71,12 +70,12 @@ static int cinergyt2_power_ctrl(struct dvb_usb_device *d, int enable)
> struct cinergyt2_state *st = d->priv;
> int ret;
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
> st->data[0] = CINERGYT2_EP1_SLEEP_MODE;
> st->data[1] = enable ? 0 : 1;
>
> ret = dvb_usb_generic_rw(d, st->data, 2, st->data, 3, 0);
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
>
> return ret;
> }
> @@ -89,7 +88,7 @@ static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
>
> adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
> st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;
>
> ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
> @@ -97,7 +96,7 @@ static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
> deb_rc("cinergyt2_power_ctrl() Failed to retrieve sleep "
> "state info\n");
> }
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
>
> /* Copy this pointer as we are gonna need it in the release phase */
> cinergyt2_usb_device = adap->dev;
> @@ -166,7 +165,7 @@ static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
>
> *state = REMOTE_NO_KEY_PRESSED;
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
> st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;
>
> ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
> @@ -202,29 +201,17 @@ static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
> }
>
> ret:
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
> return ret;
> }
>
> static int cinergyt2_usb_probe(struct usb_interface *intf,
> const struct usb_device_id *id)
> {
> - struct dvb_usb_device *d;
> - struct cinergyt2_state *st;
> - int ret;
> -
> - ret = dvb_usb_device_init(intf, &cinergyt2_properties,
> - THIS_MODULE, &d, adapter_nr);
> - if (ret < 0)
> - return ret;
> -
> - st = d->priv;
> - mutex_init(&st->data_mutex);
> -
> - return 0;
> + return dvb_usb_device_init(intf, &cinergyt2_properties,
> + THIS_MODULE, NULL, adapter_nr);
> }
>
> -
> static struct usb_device_id cinergyt2_usb_table[] = {
> { USB_DEVICE(USB_VID_TERRATEC, 0x0038) },
> { 0 }
> diff --git a/drivers/media/usb/dvb-usb/cxusb.c b/drivers/media/usb/dvb-usb/cxusb.c
> index 39772812269d..243403081fa5 100644
> --- a/drivers/media/usb/dvb-usb/cxusb.c
> +++ b/drivers/media/usb/dvb-usb/cxusb.c
> @@ -68,7 +68,7 @@ static int cxusb_ctrl_msg(struct dvb_usb_device *d,
>
> wo = (rbuf == NULL || rlen == 0); /* write-only */
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
> st->data[0] = cmd;
> memcpy(&st->data[1], wbuf, wlen);
> if (wo)
> @@ -77,7 +77,7 @@ static int cxusb_ctrl_msg(struct dvb_usb_device *d,
> ret = dvb_usb_generic_rw(d, st->data, 1 + wlen,
> rbuf, rlen, 0);
>
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
> return ret;
> }
>
> @@ -1461,43 +1461,36 @@ static struct dvb_usb_device_properties cxusb_mygica_t230_properties;
> static int cxusb_probe(struct usb_interface *intf,
> const struct usb_device_id *id)
> {
> - struct dvb_usb_device *d;
> - struct cxusb_state *st;
> -
> if (0 == dvb_usb_device_init(intf, &cxusb_medion_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &cxusb_bluebird_lgh064f_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &cxusb_bluebird_dee1601_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &cxusb_bluebird_lgz201_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &cxusb_bluebird_dtt7579_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &cxusb_bluebird_dualdig4_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &cxusb_bluebird_nano2_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf,
> &cxusb_bluebird_nano2_needsfirmware_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &cxusb_aver_a868r_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf,
> &cxusb_bluebird_dualdig4_rev2_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &cxusb_d680_dmb_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &cxusb_mygica_d689_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &cxusb_mygica_t230_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> - 0) {
> - st = d->priv;
> - mutex_init(&st->data_mutex);
> -
> + THIS_MODULE, NULL, adapter_nr) ||
> + 0)
> return 0;
> - }
>
> return -EINVAL;
> }
> diff --git a/drivers/media/usb/dvb-usb/cxusb.h b/drivers/media/usb/dvb-usb/cxusb.h
> index 9f3ee0e47d5c..18acda19527a 100644
> --- a/drivers/media/usb/dvb-usb/cxusb.h
> +++ b/drivers/media/usb/dvb-usb/cxusb.h
> @@ -37,7 +37,6 @@ struct cxusb_state {
> struct i2c_client *i2c_client_tuner;
>
> unsigned char data[MAX_XFER_SIZE];
> - struct mutex data_mutex;
> };
>
> #endif
> diff --git a/drivers/media/usb/dvb-usb/dtt200u.c b/drivers/media/usb/dvb-usb/dtt200u.c
> index f88572c7ae7c..fcbff7fb0c4e 100644
> --- a/drivers/media/usb/dvb-usb/dtt200u.c
> +++ b/drivers/media/usb/dvb-usb/dtt200u.c
> @@ -22,7 +22,6 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>
> struct dtt200u_state {
> unsigned char data[80];
> - struct mutex data_mutex;
> };
>
> static int dtt200u_power_ctrl(struct dvb_usb_device *d, int onoff)
> @@ -30,23 +29,24 @@ static int dtt200u_power_ctrl(struct dvb_usb_device *d, int onoff)
> struct dtt200u_state *st = d->priv;
> int ret = 0;
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
>
> st->data[0] = SET_INIT;
>
> if (onoff)
> ret = dvb_usb_generic_write(d, st->data, 2);
>
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
> return ret;
> }
>
> static int dtt200u_streaming_ctrl(struct dvb_usb_adapter *adap, int onoff)
> {
> - struct dtt200u_state *st = adap->dev->priv;
> + struct dvb_usb_device *d = adap->dev;
> + struct dtt200u_state *st = d->priv;
> int ret;
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
> st->data[0] = SET_STREAMING;
> st->data[1] = onoff;
>
> @@ -61,26 +61,27 @@ static int dtt200u_streaming_ctrl(struct dvb_usb_adapter *adap, int onoff)
> ret = dvb_usb_generic_write(adap->dev, st->data, 1);
>
> ret:
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
>
> return ret;
> }
>
> static int dtt200u_pid_filter(struct dvb_usb_adapter *adap, int index, u16 pid, int onoff)
> {
> - struct dtt200u_state *st = adap->dev->priv;
> + struct dvb_usb_device *d = adap->dev;
> + struct dtt200u_state *st = d->priv;
> int ret;
>
> pid = onoff ? pid : 0;
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
> st->data[0] = SET_PID_FILTER;
> st->data[1] = index;
> st->data[2] = pid & 0xff;
> st->data[3] = (pid >> 8) & 0x1f;
>
> ret = dvb_usb_generic_write(adap->dev, st->data, 4);
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
>
> return ret;
> }
> @@ -91,7 +92,7 @@ static int dtt200u_rc_query(struct dvb_usb_device *d)
> u32 scancode;
> int ret;
>
> - mutex_lock(&st->data_mutex);
> + mutex_lock(&d->data_mutex);
> st->data[0] = GET_RC_CODE;
>
> ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
> @@ -126,7 +127,7 @@ static int dtt200u_rc_query(struct dvb_usb_device *d)
> deb_info("st->data: %*ph\n", 5, st->data);
>
> ret:
> - mutex_unlock(&st->data_mutex);
> + mutex_unlock(&d->data_mutex);
> return ret;
> }
>
> @@ -145,24 +146,17 @@ static struct dvb_usb_device_properties wt220u_miglia_properties;
> static int dtt200u_usb_probe(struct usb_interface *intf,
> const struct usb_device_id *id)
> {
> - struct dvb_usb_device *d;
> - struct dtt200u_state *st;
> -
> if (0 == dvb_usb_device_init(intf, &dtt200u_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &wt220u_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &wt220u_fc_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &wt220u_zl0353_properties,
> - THIS_MODULE, &d, adapter_nr) ||
> + THIS_MODULE, NULL, adapter_nr) ||
> 0 == dvb_usb_device_init(intf, &wt220u_miglia_properties,
> - THIS_MODULE, &d, adapter_nr)) {
> - st = d->priv;
> - mutex_init(&st->data_mutex);
> -
> + THIS_MODULE, NULL, adapter_nr))
> return 0;
> - }
>
> return -ENODEV;
> }
> diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c b/drivers/media/usb/dvb-usb/dvb-usb-init.c
> index 3896ba9a4179..84308569e7dc 100644
> --- a/drivers/media/usb/dvb-usb/dvb-usb-init.c
> +++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c
> @@ -142,6 +142,7 @@ static int dvb_usb_init(struct dvb_usb_device *d, short *adapter_nums)
> {
> int ret = 0;
>
> + mutex_init(&d->data_mutex);
> mutex_init(&d->usb_mutex);
> mutex_init(&d->i2c_mutex);
>
> diff --git a/drivers/media/usb/dvb-usb/dvb-usb.h b/drivers/media/usb/dvb-usb/dvb-usb.h
> index 639c4678c65b..107255b08b2b 100644
> --- a/drivers/media/usb/dvb-usb/dvb-usb.h
> +++ b/drivers/media/usb/dvb-usb/dvb-usb.h
> @@ -404,8 +404,12 @@ struct dvb_usb_adapter {
> * Powered is in/decremented for each call to modify the state.
> * @udev: pointer to the device's struct usb_device.
> *
> - * @usb_mutex: semaphore of USB control messages (reading needs two messages)
> - * @i2c_mutex: semaphore for i2c-transfers
> + * @data_mutex: mutex to protect the data structure used to store URB data
> + * @usb_mutex: mutex of USB control messages (reading needs two messages).
> + * Please notice that this mutex is used internally at the generic
> + * URB control functions. So, drivers using dvb_usb_generic_rw() and
> + * derivated functions should not lock it internally.
> + * @i2c_mutex: mutex for i2c-transfers
> *
> * @i2c_adap: device's i2c_adapter if it uses I2CoverUSB
> *
> @@ -433,6 +437,7 @@ struct dvb_usb_device {
> int powered;
>
> /* locking */
> + struct mutex data_mutex;
> struct mutex usb_mutex;
>
> /* i2c */
> --
> 2.9.3
>
^ permalink raw reply
* [GIT PULL] DaVinci additional driver support for v4.10
From: Sekhar Nori @ 2016-11-14 12:58 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/drivers
for you to fetch changes up to 8e7223fc8626db7c302136747bb68213100d290c:
bus: davinci: add support for da8xx bus master priority control (2016-11-14 17:20:29 +0530)
----------------------------------------------------------------
This pull request adds two new drivers for better
support for LCD found on DaVinci DA8xx devices.
They allow configuration of memory interface and
bus priorities on the SoC to allow sufficient
bandwidth for the LCD and prevent underruns.
The DT bindings have been reviewed by Rob and
patches have been reviewed by Kevin.
----------------------------------------------------------------
Bartosz Golaszewski (2):
memory: davinci: add support for da8xx DDR2/mDDR controller
bus: davinci: add support for da8xx bus master priority control
.../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
.../memory-controllers/ti-da8xx-ddrctl.txt | 20 ++
drivers/bus/Kconfig | 9 +
drivers/bus/Makefile | 2 +
drivers/bus/da8xx-mstpri.c | 269 +++++++++++++++++++++
drivers/memory/Kconfig | 8 +
drivers/memory/Makefile | 1 +
drivers/memory/da8xx-ddrctl.c | 175 ++++++++++++++
8 files changed, 504 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
create mode 100644 drivers/bus/da8xx-mstpri.c
create mode 100644 drivers/memory/da8xx-ddrctl.c
^ permalink raw reply
* [Qemu-devel] qemu 2.6.2: e1000 network card hanging after live migration
From: Peter Lieven @ 2016-11-14 12:58 UTC (permalink / raw)
To: qemu-devel@nongnu.org
Hi,
I have observed a virtual server with an e1000 network card loosing network connectivity
after live migration (not reproducible so far). In the log of the vServer I found several messages like:
kernel: [13833656.832108] e1000 0000:00:05.0 eth2: Reset adapter
When I restarted the vServer to try to restore connectivity I triggered the following assertion:
qemu-2.6.2: hw/pci/pci.c:280: pcibus_reset: Assertion `bus->irq_count[i] == 0' failed.
Is this something that has anyone observed before?
Thanks,
Peter
^ permalink raw reply
* [PATCH] scsi: hpsa: free irq on q indexed by h->intr_mode and not i
From: Colin King @ 2016-11-14 12:59 UTC (permalink / raw)
To: Christoph Hellwig, Don Brace, James E . J . Bottomley,
Martin K . Petersen, esc.storagedev, linux-scsi
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Use correct index on q, use h->intr_mode instead of i. Issue
detected using static analysis with cppcheck
Fixes: bc2bb1543e62a5d0 ("scsi: hpsa: use pci_alloc_irq_vectors and automatic irq affinity")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/scsi/hpsa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 9459925..0d4f21c 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -8220,7 +8220,7 @@ static void hpsa_free_irqs(struct ctlr_info *h)
if (!h->msix_vectors || h->intr_mode != PERF_MODE_INT) {
/* Single reply queue, only one irq to free */
- free_irq(pci_irq_vector(h->pdev, 0), &h->q[i]);
+ free_irq(pci_irq_vector(h->pdev, 0), &h->q[h->intr_mode]);
h->q[h->intr_mode] = 0;
return;
}
--
2.10.2
^ permalink raw reply related
* Recent changes (master)
From: Jens Axboe @ 2016-11-14 13:00 UTC (permalink / raw)
To: fio
The following changes since commit 206c546d6015fe3809b8e52ea95f56114b8e9f25:
rbd: fix crash with zero sized image (2016-11-12 08:36:23 -0700)
are available in the git repository at:
git://git.kernel.dk/fio.git master
for you to fetch changes up to 471bb52b2e75413d18e8def5bb7d301aab7541e9:
Fix memory leak on tmp_buf (2016-11-14 00:05:37 +0000)
----------------------------------------------------------------
Colin Ian King (1):
Fix memory leak on tmp_buf
oslib/libmtd.c | 1 +
1 file changed, 1 insertion(+)
---
Diff of recent changes:
diff --git a/oslib/libmtd.c b/oslib/libmtd.c
index 5b22d6a..24e9db9 100644
--- a/oslib/libmtd.c
+++ b/oslib/libmtd.c
@@ -1116,6 +1116,7 @@ static int legacy_auto_oob_layout(const struct mtd_dev_info *mtd, int fd,
len = mtd->oob_size - start;
memcpy(oob + start, tmp_buf + start, len);
}
+ free(tmp_buf);
return 0;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.