RE: [RFC PATCH 03/11] PCI/MSI: Refactor pci_dev_msi_enabled()
> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-ow...@vger.kernel.org]
> On Behalf Of Yijing Wang
> Sent: Saturday, July 26, 2014 8:39 AM
> To: linux-kernel@vger.kernel.org
> Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-...@vger.kernel.org;
> paul.mu...@huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm-
> ker...@lists.infradead.org; Russell King; linux-a...@vger.kernel.org; Basu
> Arnab-B45036; virtualizat...@lists.linux-foundation.org; Hanjun Guo; Yijing
> Wang
> Subject: [RFC PATCH 03/11] PCI/MSI: Refactor pci_dev_msi_enabled()
>
> Pci_dev_msi_enabled() is used to check whether device MSI/MSIX enabled.
> Refactor
> this function to suuport checking only device MSI or MSIX enabled.
s/support/support
>From code it looks like you added one more parameter to pci_dev_msi_enabled()
>to check for a specific type, which earlier it was checking for both MSI and
>MSIX enable. While the description is not clear to me, Am I missing something ?
Thanks
-Bharat
>
> Signed-off-by: Yijing Wang
> ---
> arch/cris/arch-v32/drivers/pci/bios.c |2 +-
> arch/frv/mb93090-mb00/pci-vdk.c |2 +-
> arch/ia64/pci/pci.c |4 ++--
> arch/powerpc/kernel/eeh_driver.c |2 +-
> arch/x86/pci/common.c |5 +++--
> drivers/block/nvme-core.c |4 ++--
> drivers/dma/ioat/dma.c|2 +-
> drivers/firewire/ohci.c |2 +-
> drivers/gpu/drm/i915/i915_dma.c |4 ++--
> drivers/misc/mei/hw-me.c |2 +-
> drivers/misc/mei/hw-txe.c |2 +-
> drivers/misc/mei/pci-me.c |4 ++--
> drivers/misc/mei/pci-txe.c|4 ++--
> drivers/misc/mic/host/mic_debugfs.c |4 ++--
> drivers/misc/mic/host/mic_intr.c |8
> drivers/ntb/ntb_hw.c |2 +-
> drivers/pci/irq.c |4 ++--
> drivers/pci/msi.c | 15 +--
> drivers/pci/pci.c |6 +++---
> drivers/pci/pcie/portdrv_core.c |4 ++--
> drivers/scsi/esas2r/esas2r_init.c |4 ++--
> drivers/scsi/esas2r/esas2r_ioctl.c|4 ++--
> drivers/scsi/hpsa.c |4 ++--
> drivers/staging/crystalhd/crystalhd_lnx.c |2 +-
> drivers/xen/xen-pciback/pciback_ops.c | 12 ++--
> include/linux/pci.h | 12 ++--
> virt/kvm/assigned-dev.c |2 +-
> 27 files changed, 67 insertions(+), 55 deletions(-)
>
> diff --git a/arch/cris/arch-v32/drivers/pci/bios.c b/arch/cris/arch-
> v32/drivers/pci/bios.c
> index 64a5fb9..d9d8332 100644
> --- a/arch/cris/arch-v32/drivers/pci/bios.c
> +++ b/arch/cris/arch-v32/drivers/pci/bios.c
> @@ -93,7 +93,7 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
> if ((err = pcibios_enable_resources(dev, mask)) < 0)
> return err;
>
> - if (!dev->msi_enabled)
> + if (!pci_dev_msi_enabled(dev, MSI_TYPE))
> pcibios_enable_irq(dev);
> return 0;
> }
> diff --git a/arch/frv/mb93090-mb00/pci-vdk.c b/arch/frv/mb93090-mb00/pci-vdk.c
> index efa5d65..b96c128 100644
> --- a/arch/frv/mb93090-mb00/pci-vdk.c
> +++ b/arch/frv/mb93090-mb00/pci-vdk.c
> @@ -409,7 +409,7 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
>
> if ((err = pci_enable_resources(dev, mask)) < 0)
> return err;
> - if (!dev->msi_enabled)
> + if (!pci_dev_msi_enabled(dev, MSI_TYPE))
> pcibios_enable_irq(dev);
> return 0;
> }
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c index 291a582..da8ddff
> 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -568,7 +568,7 @@ pcibios_enable_device (struct pci_dev *dev, int mask)
> if (ret < 0)
> return ret;
>
> - if (!dev->msi_enabled)
> + if (!pci_dev_msi_enabled(dev, MSI_TYPE))
> return acpi_pci_irq_enable(dev);
> return 0;
> }
> @@ -577,7 +577,7 @@ void
> pcibios_disable_device (struct pci_dev *dev) {
> BUG_ON(atomic_read(>enable_cnt));
> - if (!dev->msi_enabled)
> + if (!pci_dev_msi_enabled(dev, MSI_TYPE))
> acpi_pci_irq_disable(dev);
> }
>
> diff --git a/arch/powerpc/kernel/eeh_driver.c
> b/arch/powerpc/kernel/eeh_driver.c
> index 420da61..e3f2074 100644
> --- a/arch/powerpc/kernel/eeh_driver.c
> +++ b/arch/powerpc/kernel/eeh_driver.c
> @@ -123,7 +123,7 @@ static void eeh_disable_irq(struct pci_dev *dev)
>* effectively disabled by the DMA Stopped state
>* when an EEH error occurs.
>*/
> - if (dev->msi_enabled || dev->msix_enabled)
> + if (pci_dev_msi_enabled(dev, MSI_TYPE | MSIX_TYPE))
> return;
>
> if (!irq_has_action(dev->irq))
> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
Re: [PATCH 1/2] SOUND: kill gameport bits
On Tue, Aug 19, 2014 at 10:18:15PM -0700, Dmitry Torokhov wrote: > Hi Andreas, > > On Wed, Aug 20, 2014 at 04:46:38AM +0200, Andreas Mohr wrote: > > > Hi, > > > > > Gameport support hasn't been working well ever since cpufreq became > > > mainstream and it becomes increasingly hard to find hardware and > > > software > > > that would run on such old hardware. > > > > Given that I'm puzzled why one would want to deprecate a whole subsystem > > which appears to be supported by a whole 14 different PCI sound card > > drivers (where the ones I'm owning hardware of are intended to be in > > active maintenance) > > Are you actively testing gameport interfaces with real joysticks/gamepads on > these cards? And what software is still in use that runs on these old boxes > (with mainline kernel)? Well, I did test some games with real joysticks e.g. in order to implement working Digital Enhanced Game Port support (where BTW the couple cards/driver combos which support that should also be completely unaffected by cpufreq since its delay accounting is digital). > > and only 3 ISA-based ones, I'm missing several > > details and justifications of that decision here (perhaps there was a > > prior discussion/activity that I'm missing?). > > There was a post to linux-input a few days ago when I ased if anyone woudl cry > over gameport going away. Missed that one (not subscribed), sorry. > > Also, I'm left wondering why e.g. my Athlon XP system (a very popular > > choice for longer times) would be affected by Cpufreq... > > And there are no details on how exactly cpufreq is a problem or how this > > timing issue could be fixed... > > If you take a look at gameport_measure_speed() in gameport.c you will see that > it counts cycles for timing, which obviously does not work that well when CPU > frequency changes. Yup, but at least not for the candidates above. > The bugs have been opened in bugzilla/reported on lists ages ago but nobody > stepped up to fix that. Ouch. I'm afraid I don't have any cpufreq-supporting hardware (hint, hint) which would enable me to work on it, though. > > The obvious workaround for such an ensuing dearth of hardware support > > could be USB 15-pin gameport adapters - but are they even supported on > > Linux? Haven't seen info on this... > > And even if supported, these adapters (at least the non-perfect ones, as > > can be seen from reviews on a well-known online shop site) are said to > > be hit-or-miss. > They have better chance of being supported ;) I had a couple a few years back > and they did work for me. Good to know. I took a note to buy a good adapter as well. > > If we keep removing functionality like this, then why stop short of > > removing x86 32bit as a whole? By having Linux support nicely restricted > > to hardware made within the last 5 years, we would surely be doing the > > planned-obsolescence Micro$oft "ecosystem" (what was ecological about > > this again?) a huge favour... > > I really do not care about Microsoft and favors, I just go by the fact that > this hardware is becoming naturally extinct. And not only hardware, but also > software that uses it. Do you still play a lot of games with joysticks on such > hardware? Not me (I'm a developer). But other people probably would be inclined to do so, as long as sufficient support remains in place, on an architecture which is still in very wide use. And this case here (as opposed to e.g. the NI5010 ISA BNC network card where it was arguably very likely that it was totally unused) seems like a self-fulfilling prophecy... Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/3] usb: gadget: f_fs: virtual endpoint address mapping
This patch introduces virtual endpoint address mapping. It separates
function logic form physical endpoint addresses making it more hardware
independent.
Following modifications changes user space API, so to enable them user
have to switch on the FUNCTIONFS_VIRTUAL_ADDR flag in descriptors.
Endpoints are now refered using virtual endpoint addresses chosen by
user in endpoint descpriptors. This applies to each context when endpoint
address can be used:
- when accessing endpoint files in FunctionFS filesystemi (in file name),
- in setup requests directed to specific endpoint (in wIndex field),
- in descriptors returned by FUNCTIONFS_ENDPOINT_DESC ioctl.
In endpoint file names the endpoint address number is formatted as
double-digit hexadecimal value ("ep%02x") which has few advantages -
it is easy to parse, allows to easly recognize endpoint direction basing
on its name (IN endpoint number starts with digit 8, and OUT with 0)
which can be useful for debugging purpose, and it makes easier to introduce
further features allowing to use each endpoint number in both directions
to have more endpoints available for function if hardware supports this
(for example we could have ep01 which is endpoint 1 with OUT direction,
and ep81 which is endpoint 1 with IN direction).
Physical endpoint address can be still obtained using ioctl named
FUNCTIONFS_ENDPOINT_REVMAP, but now it's not neccesary to handle
USB transactions properly.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/function/f_fs.c | 23 +--
drivers/usb/gadget/function/u_fs.h | 2 ++
include/uapi/linux/usb/functionfs.h | 1 +
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index ac7b16d..a20ac8d 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1555,7 +1555,10 @@ static int ffs_epfiles_create(struct ffs_data *ffs)
epfile->ffs = ffs;
mutex_init(>mutex);
init_waitqueue_head(>wait);
- sprintf(epfiles->name, "ep%u", i);
+ if (ffs->user_flags & FUNCTIONFS_VIRTUAL_ADDR)
+ sprintf(epfiles->name, "ep%02x", ffs->eps_addrmap[i]);
+ else
+ sprintf(epfiles->name, "ep%u", i);
if (!unlikely(ffs_sb_create_file(ffs->sb, epfiles->name, epfile,
_epfile_operations,
>dentry))) {
@@ -2105,10 +2108,12 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
break;
case FUNCTIONFS_DESCRIPTORS_MAGIC_V2:
flags = get_unaligned_le32(data + 8);
+ ffs->user_flags = flags;
if (flags & ~(FUNCTIONFS_HAS_FS_DESC |
FUNCTIONFS_HAS_HS_DESC |
FUNCTIONFS_HAS_SS_DESC |
- FUNCTIONFS_HAS_MS_OS_DESC)) {
+ FUNCTIONFS_HAS_MS_OS_DESC |
+ FUNCTIONFS_VIRTUAL_ADDR)) {
ret = -ENOSYS;
goto error;
}
@@ -2463,7 +2468,13 @@ static int __ffs_func_bind_do_descs(enum ffs_entity_type
type, u8 *valuep,
} else {
struct usb_request *req;
struct usb_ep *ep;
+ u8 bEndpointAddress;
+ /*
+* We back up bEndpointAddress because autoconfig overwrites
+* it with physical endpoint address.
+*/
+ bEndpointAddress = ds->bEndpointAddress;
pr_vdebug("autoconfig\n");
ep = usb_ep_autoconfig(func->gadget, ds);
if (unlikely(!ep))
@@ -2478,6 +2489,12 @@ static int __ffs_func_bind_do_descs(enum ffs_entity_type
type, u8 *valuep,
ffs_ep->req = req;
func->eps_revmap[ds->bEndpointAddress &
USB_ENDPOINT_NUMBER_MASK] = idx + 1;
+ /*
+* If we use virtual address mapping, we restore
+* original bEndpointAddress value.
+*/
+ if (func->ffs->user_flags & FUNCTIONFS_VIRTUAL_ADDR)
+ ds->bEndpointAddress = bEndpointAddress;
}
ffs_dump_mem(": Rewritten ep desc", ds, ds->bLength);
@@ -2922,6 +2939,8 @@ static int ffs_func_setup(struct usb_function *f,
ret = ffs_func_revmap_ep(func, le16_to_cpu(creq->wIndex));
if (unlikely(ret < 0))
return ret;
+ if (func->ffs->user_flags & FUNCTIONFS_VIRTUAL_ADDR)
+ ret = func->ffs->eps_addrmap[ret];
break;
default:
diff --git a/drivers/usb/gadget/function/u_fs.h
b/drivers/usb/gadget/function/u_fs.h
index d48897e..cd128e3 100644
---
[PATCH v4 1/3] usb: gadget: f_fs: fix the redundant ep files problem
Up to now, when endpoint addresses in descriptors were non-consecutive,
there were created redundant files, which could cause problems in kernel,
when user tryed to read/write to them. It was result of fact that maximum
endpoint address was taken as total number of endpoints in funciton.
This patch adds endpoint descriptors counting and storing their addresses
in eps_addrmap to verify their cohesion in each speed.
Endpoint address map would be also useful for further features, just like
vitual endpoint address mapping.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/function/f_fs.c | 67 +++---
drivers/usb/gadget/function/u_fs.h | 2 ++
2 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index dc30adf..8096f22 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -155,6 +155,12 @@ struct ffs_io_data {
struct usb_request *req;
};
+struct ffs_desc_helper {
+ struct ffs_data *ffs;
+ unsigned interfaces_count;
+ unsigned eps_count;
+};
+
static int __must_check ffs_epfiles_create(struct ffs_data *ffs);
static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count);
@@ -1830,7 +1836,8 @@ static int __ffs_data_do_entity(enum ffs_entity_type type,
u8 *valuep, struct usb_descriptor_header *desc,
void *priv)
{
- struct ffs_data *ffs = priv;
+ struct ffs_desc_helper *helper = priv;
+ struct usb_endpoint_descriptor *d;
ENTER();
@@ -1844,8 +1851,8 @@ static int __ffs_data_do_entity(enum ffs_entity_type type,
* encountered interface "n" then there are at least
* "n+1" interfaces.
*/
- if (*valuep >= ffs->interfaces_count)
- ffs->interfaces_count = *valuep + 1;
+ if (*valuep >= helper->interfaces_count)
+ helper->interfaces_count = *valuep + 1;
break;
case FFS_STRING:
@@ -1853,14 +1860,23 @@ static int __ffs_data_do_entity(enum ffs_entity_type
type,
* Strings are indexed from 1 (0 is magic ;) reserved
* for languages list or some such)
*/
- if (*valuep > ffs->strings_count)
- ffs->strings_count = *valuep;
+ if (*valuep > helper->ffs->strings_count)
+ helper->ffs->strings_count = *valuep;
break;
case FFS_ENDPOINT:
- /* Endpoints are indexed from 1 as well. */
- if ((*valuep & USB_ENDPOINT_NUMBER_MASK) > ffs->eps_count)
- ffs->eps_count = (*valuep & USB_ENDPOINT_NUMBER_MASK);
+ d = (void *)desc;
+ helper->eps_count++;
+ if (helper->eps_count >= 15)
+ return -EINVAL;
+ if (!helper->ffs->eps_count && !helper->ffs->interfaces_count)
+ helper->ffs->eps_addrmap[helper->eps_count] =
+ d->bEndpointAddress;
+ else if (helper->ffs->eps_count < helper->eps_count)
+ return -EINVAL;
+ else if (helper->ffs->eps_addrmap[helper->eps_count] !=
+ d->bEndpointAddress)
+ return -EINVAL;
break;
}
@@ -2053,6 +2069,7 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
char *data = _data, *raw_descs;
unsigned os_descs_count = 0, counts[3], flags;
int ret = -EINVAL, i;
+ struct ffs_desc_helper helper;
ENTER();
@@ -2101,13 +2118,29 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
/* Read descriptors */
raw_descs = data;
+ helper.ffs = ffs;
for (i = 0; i < 3; ++i) {
if (!counts[i])
continue;
+ helper.interfaces_count = 0;
+ helper.eps_count = 0;
ret = ffs_do_descs(counts[i], data, len,
- __ffs_data_do_entity, ffs);
+ __ffs_data_do_entity, );
if (ret < 0)
goto error;
+ if (!ffs->eps_count && !ffs->interfaces_count) {
+ ffs->eps_count = helper.eps_count;
+ ffs->interfaces_count = helper.interfaces_count;
+ } else {
+ if (ffs->eps_count != helper.eps_count) {
+ ret = -EINVAL;
+ goto error;
+ }
+ if (ffs->interfaces_count != helper.interfaces_count) {
+ ret = -EINVAL;
+ goto error;
+ }
+ }
[PATCH v4 2/3] usb: gadget: f_fs: add ioctl returning ep descriptor
This patch introduces ioctl named FUNCTIONFS_ENDPOINT_DESC, which
returns endpoint descriptor to userspace. It works only if function
is active.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/function/f_fs.c | 21 +
include/uapi/linux/usb/functionfs.h | 6 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 8096f22..ac7b16d 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1032,6 +1032,27 @@ static long ffs_epfile_ioctl(struct file *file, unsigned
code,
case FUNCTIONFS_ENDPOINT_REVMAP:
ret = epfile->ep->num;
break;
+ case FUNCTIONFS_ENDPOINT_DESC:
+ {
+ int desc_idx;
+ struct usb_endpoint_descriptor *desc;
+
+ switch (epfile->ffs->gadget->speed) {
+ case USB_SPEED_SUPER:
+ desc_idx = 2;
+ break;
+ case USB_SPEED_HIGH:
+ desc_idx = 1;
+ break;
+ default:
+ desc_idx = 0;
+ }
+ desc = epfile->ep->descs[desc_idx];
+ ret = copy_to_user((void *)value, desc, sizeof(*desc));
+ if (ret)
+ ret = -EFAULT;
+ break;
+ }
default:
ret = -ENOTTY;
}
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index 0154b28..900896e 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -265,6 +265,12 @@ struct usb_functionfs_event {
*/
#defineFUNCTIONFS_ENDPOINT_REVMAP _IO('g', 129)
+/*
+ * Returns endpoint descriptor. In funciton is not active returns -ENODEV.
+ */
+#defineFUNCTIONFS_ENDPOINT_DESC_IOR('g', 130, \
+struct usb_endpoint_descriptor)
+
#endif /* _UAPI__LINUX_FUNCTIONFS_H__ */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/3] usb: gadget: f_fs: userspace API fixes and improvements
This patchset contains changes in FunctionFS making it easier and safer to use. It fixes bug in endpoint files handling code, adds new ioctl allowing to obtain endpoint descriptor, and introduces virtual address mapping which allows to separate endpoint address space in function from physical endpoint addresses, and introduces new endpoint files naming convention. Changelog: v4: - change if() sequence into switch() statement v3: https://lkml.org/lkml/2014/7/30/115 - move fix for the redundant ep files problem into sepatare patch - merge user space API affecting changes into single patch - add flag switching between old and new style API v2: https://lkml.org/lkml/2014/7/25/296 - return proper endpont address in setup request handling - add patch usb: gadget: f_fs: add ioctl returning ep descriptor - add patch usb: gadget: f_fs: make numbers in ep file names the same as ep addresses v1: https://lkml.org/lkml/2014/7/18/1010 Robert Baldyga (3): usb: gadget: f_fs: fix the redundant ep files problem usb: gadget: f_fs: add ioctl returning ep descriptor usb: gadget: f_fs: virtual endpoint address mapping drivers/usb/gadget/function/f_fs.c | 111 +++- drivers/usb/gadget/function/u_fs.h | 4 ++ include/uapi/linux/usb/functionfs.h | 7 +++ 3 files changed, 109 insertions(+), 13 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device
Hi Yijing > -Original Message- > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-ow...@vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Monday, August 04, 2014 8:34 AM > To: Basu Arnab-B45036 > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-...@vger.kernel.org; > paul.mu...@huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > ker...@lists.infradead.org; Russell King; linux-a...@vger.kernel.org; > virtualizat...@lists.linux-foundation.org; Hanjun Guo; linux- > ker...@vger.kernel.org > Subject: Re: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device > > >> MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver > >> codes are bonding with PCI device. Because MSI has a lot advantages in > design. > >> More and more non-PCI devices want to use MSI as their default interrupt. > >> The existing MSI device include HPET. HPET driver provide its own MSI > >> code to initialize and process MSI interrupts. In the latest GIC v3 > >> spec, legacy device can deliver MSI by the help of a relay device > >> named consolidator. > >> Consolidator can translate the legacy interrupts connected to it to > >> MSI/MSI-X. And new non-PCI device will be designed to support MSI in > >> future. So make the MSI driver code be generic will help the non-PCI > >> device use MSI more simply. > > > > As per my understanding the GICv3 provides a service that will convert > > writes > to a specified address to IRQs delivered to the core and as you mention above > MSIs are part of the PCI spec. So I can see a strong case for non-PCI devices > to > want MSI like functionality without being fully compliant with the > requirements > of the MSI spec. > > In GICv3, MBI is named for the service, but there is no more detailed > information about it, only we can know is MBI is analogous to MSI, MBI devices > must have address/data registers, but other registers like enable/mask/ctrl > are > not mandatory requirement. > I don't know whether the MBI spec will be release, but anyway I think MSI > refactoring is make sense, there are some existing Non-PCI MSI device like > hpet, > dmar. > For simplicity, let name MSI and MBI to MSI temporarily. > > > > My question is do we necessarily want to rework so much of the PCI-MSI layer > to support non PCI devices? Or will it be sufficient to create a framework to > allow non PCI devices to hook up with a device that can convert their writes > to > an IRQ to the core. > > > > As I understand it, the msi_chip is (almost) such a framework. The only > problem being that it makes some PCI specific assumptions (such as PCI > specific > writes from within msi_chip functions). Won't it be sufficient to make the > msi_chip framework generic enough to be used by non-PCI devices and let each > bus/device manage any additional requirements (such as configuration flow, bit > definitions etc) that it places on message based interrupts? > > msi_chip framework is important to support that, but I think maybe it's not > enough, msi_chip is only responsible for IRQ allocation, teardown, etc.. > > The key difference between PCI device and Non-PCI MSI is the interfaces to > access hardware MSI registers. > for instance, currently, msi_chip->setup_irq() to setup MSI irq and configure > the MSI address/data registers, so we need to provide device specific > write_msi_msg() interface, then when we call msi_chip->setup_irq(), the device > MSI registers can be configured appropriately. What if we can register/override the setup_irq() from bus-driver (not sure, but may be device-driver itself). Example PCI bus-driver will provide setup_irq() (or the part of setup_irq which set address and data in h/w) by PCI bus, which configure address/data in h/w as per PCI standard. We in Freescale will be using MSI for the devices behind a new-bus (which is not PCI based), We have a separate bus driver for same. And this new bus driver register/provide its own address/data write function which is based on that specific bus protocol. Thanks -Bharat > > My patchset is just a RFC draft, I will update it later, all we want to do is > make kernel support Non-PCI MSI devices. > > Thanks! > Yijing. > > > > > > Thanks > > Arnab > > -- > > To unsubscribe from this list: send the line "unsubscribe > > linux-kernel" in the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > . > > > > > -- > Thanks! > Yijing > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in the > body > of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] sgi-xp: Do not use BUG_ON(!spin_is_locked())
Opps ! Thanks for review comment. Just sent V2 updated patch.
Sanjeev Sharma
-Original Message-
From: Ryan Mallon [mailto:rmal...@gmail.com]
Sent: Wednesday, August 20, 2014 4:34 AM
To: Sharma, Sanjeev; c...@sgi.com; robinmh...@gmail.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sgi-xp: Do not use BUG_ON(!spin_is_locked())
On 12/08/14 17:35, Sanjeev Sharma wrote:
> on some architecture spin_is_locked() always return false in
> uniprocessor configuration and can therefore not be used with
> BUG_ON.it would be advise to replace with lockdep_assert_held().
>
> Signed-off-by: Sanjeev Sharma
> ---
> drivers/misc/sgi-xp/xpc_channel.c | 6 +++---
> drivers/misc/sgi-xp/xpc_sn2.c | 2 +-
> drivers/misc/sgi-xp/xpc_uv.c | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/misc/sgi-xp/xpc_channel.c
> b/drivers/misc/sgi-xp/xpc_channel.c
> index 128d561..240fe5a 100644
> --- a/drivers/misc/sgi-xp/xpc_channel.c
> +++ b/drivers/misc/sgi-xp/xpc_channel.c
> @@ -28,7 +28,7 @@ xpc_process_connect(struct xpc_channel *ch, unsigned
> long *irq_flags) {
> enum xp_retval ret;
>
> - DBUG_ON(!spin_is_locked(>lock));
> + lockdep_assert_held(!spin_is_locked(>lock));
This is incorrect, and will break the build with CONFIG_LOCKDEP enabled.
You actually want:
lockdep_assert_held(>lock);
Same for the other instances.
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] sgi-xp: Do not use BUG_ON(!spin_is_locked())
on some architecture spin_is_locked() always return false in
uniprocessor configuration and can therefore not be used
with BUG_ON.it would be advise to replace with
lockdep_assert_held().
Signed-off-by: Sanjeev Sharma
---
Changes in v2:
- corrected the typo
drivers/misc/sgi-xp/xpc_channel.c | 6 +++---
drivers/misc/sgi-xp/xpc_sn2.c | 2 +-
drivers/misc/sgi-xp/xpc_uv.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/sgi-xp/xpc_channel.c
b/drivers/misc/sgi-xp/xpc_channel.c
index 128d561..611d34f 100644
--- a/drivers/misc/sgi-xp/xpc_channel.c
+++ b/drivers/misc/sgi-xp/xpc_channel.c
@@ -28,7 +28,7 @@ xpc_process_connect(struct xpc_channel *ch, unsigned long
*irq_flags)
{
enum xp_retval ret;
- DBUG_ON(!spin_is_locked(>lock));
+ lockdep_assert_held(>lock);
if (!(ch->flags & XPC_C_OPENREQUEST) ||
!(ch->flags & XPC_C_ROPENREQUEST)) {
@@ -82,7 +82,7 @@ xpc_process_disconnect(struct xpc_channel *ch, unsigned long
*irq_flags)
struct xpc_partition *part = _partitions[ch->partid];
u32 channel_was_connected = (ch->flags & XPC_C_WASCONNECTED);
- DBUG_ON(!spin_is_locked(>lock));
+ lockdep_assert_held(>lock);
if (!(ch->flags & XPC_C_DISCONNECTING))
return;
@@ -758,7 +758,7 @@ xpc_disconnect_channel(const int line, struct xpc_channel
*ch,
{
u32 channel_was_connected = (ch->flags & XPC_C_CONNECTED);
- DBUG_ON(!spin_is_locked(>lock));
+ lockdep_assert_held(>lock);
if (ch->flags & (XPC_C_DISCONNECTING | XPC_C_DISCONNECTED))
return;
diff --git a/drivers/misc/sgi-xp/xpc_sn2.c b/drivers/misc/sgi-xp/xpc_sn2.c
index 7d71c04..9d3b113 100644
--- a/drivers/misc/sgi-xp/xpc_sn2.c
+++ b/drivers/misc/sgi-xp/xpc_sn2.c
@@ -1674,7 +1674,7 @@ xpc_teardown_msg_structures_sn2(struct xpc_channel *ch)
{
struct xpc_channel_sn2 *ch_sn2 = >sn.sn2;
- DBUG_ON(!spin_is_locked(>lock));
+ lockdep_assert_held(>lock);
ch_sn2->remote_msgqueue_pa = 0;
diff --git a/drivers/misc/sgi-xp/xpc_uv.c b/drivers/misc/sgi-xp/xpc_uv.c
index 95c8944..828733c 100644
--- a/drivers/misc/sgi-xp/xpc_uv.c
+++ b/drivers/misc/sgi-xp/xpc_uv.c
@@ -1183,7 +1183,7 @@ xpc_teardown_msg_structures_uv(struct xpc_channel *ch)
{
struct xpc_channel_uv *ch_uv = >sn.uv;
- DBUG_ON(!spin_is_locked(>lock));
+ lockdep_assert_held(>lock);
kfree(ch_uv->cached_notify_gru_mq_desc);
ch_uv->cached_notify_gru_mq_desc = NULL;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: CPU: 6 PID: 79 at fs/proc/generic.c:521 remove_proc_entry+0x170/0x180()
On Tue, 19 Aug 2014 at 20:13, Cong Wang wrote: > On Tue, Aug 19, 2014 at 7:50 PM, Jiang Liu wrote: > > Hi Kujau, > > It seems like a different issue, something wrong with > > void nfs_fs_proc_net_exit(struct net *net) > > http://marc.info/?l=linux-nfs=140821782107427=2 Thanks, that helped! Christian. -- BOFH excuse #182: endothermal recalibration -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
Hi Andreas, On Wed, Aug 20, 2014 at 04:46:38AM +0200, Andreas Mohr wrote: > Hi, > > > Gameport support hasn't been working well ever since cpufreq became > > mainstream and it becomes increasingly hard to find hardware and > > software > > that would run on such old hardware. > > Given that I'm puzzled why one would want to deprecate a whole subsystem > which appears to be supported by a whole 14 different PCI sound card > drivers (where the ones I'm owning hardware of are intended to be in > active maintenance) Are you actively testing gameport interfaces with real joysticks/gamepads on these cards? And what software is still in use that runs on these old boxes (with mainline kernel)? > and only 3 ISA-based ones, I'm missing several > details and justifications of that decision here (perhaps there was a > prior discussion/activity that I'm missing?). There was a post to linux-input a few days ago when I ased if anyone woudl cry over gameport going away. > > Also, I'm left wondering why e.g. my Athlon XP system (a very popular > choice for longer times) would be affected by Cpufreq... > And there are no details on how exactly cpufreq is a problem or how this > timing issue could be fixed... If you take a look at gameport_measure_speed() in gameport.c you will see that it counts cycles for timing, which obviously does not work that well when CPU frequency changes. The bugs have been opened in bugzilla/reported on lists ages ago but nobody stepped up to fix that. > The obvious workaround for such an ensuing dearth of hardware support > could be USB 15-pin gameport adapters - but are they even supported on > Linux? Haven't seen info on this... > And even if supported, these adapters (at least the non-perfect ones, as > can be seen from reviews on a well-known online shop site) are said to > be hit-or-miss. > > http://www.flightsim.com/vbfs/showthread.php?238938-joystick-GamePort-to-USB-adapter-question > http://reviews.thesource.ca/9026/2600164/nexxtech-usb-gameport-adapter-reviews/reviews.htm > They have better chance of being supported ;) I had a couple a few years back and they did work for me. > If we keep removing functionality like this, then why stop short of > removing x86 32bit as a whole? By having Linux support nicely restricted > to hardware made within the last 5 years, we would surely be doing the > planned-obsolescence Micro$oft "ecosystem" (what was ecological about > this again?) a huge favour... I really do not care about Microsoft and favors, I just go by the fact that this hardware is becoming naturally extinct. And not only hardware, but also software that uses it. Do you still play a lot of games with joysticks on such hardware? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Overriding -Werror
On Wed, Aug 20, 2014 at 01:43:59AM +0200, Andi Kleen wrote: > On Tue, Aug 19, 2014 at 10:11:30PM +0200, Sam Ravnborg wrote: > > On Tue, Aug 19, 2014 at 06:15:07AM -0700, Andi Kleen wrote: > > > Brian Norris writes: > > > > > > > > 4. better ideas? > > > > > > Just send patches to remove -Werror in all architectures > > > as a tree sweep (and anywhere else where someone misguided add it) > > In arch/sparc/ we have -Werror and this has never troubled us. > > In fact more than once people had tried to provide sloppy code that > > failed due to -Werror so it got fixed up front. > > It's a major mistake to not support future gccs for released source. Until now this has not been an issue - for the sparc bits. If newer gcc's turn out to give legit warnings then if someone provides a little help (configure command-line to build gcc) the warnings will be fixed. And that should hold true for any decent maintained piece of SW. If the intent is to use bleeding edge gcc then -Werrror can be annoying and the right fix would be to make it possible to diable it on the command-line. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thermal: exynos: Remove duplicate code when reading triminfo register of Exynos5440
On Wed, Aug 20, 2014 at 9:54 AM, Chanwoo Choi wrote:
> This patch remove simply duplicate code when reading triminfo register of
> Exynos5440.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: Amit Daniel Kachhap
Reviewed-by: Amit Daniel Kachhap
Thanks,
Amit
> ---
> drivers/thermal/samsung/exynos_tmu.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index ed01606..13c2e01 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -181,15 +181,13 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> */
> switch (data->id) {
> case 0:
> + case 2:
> trim_info = readl(data->base +
> EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
> break;
> case 1:
> trim_info = readl(data->base + reg->triminfo_data);
> break;
> - case 2:
> - trim_info = readl(data->base -
> - EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
> }
> } else {
> /* On exynos5420 the triminfo register is in the shared space
> */
> --
> 1.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
Dear Amit, On 08/20/2014 01:51 PM, amit daniel kachhap wrote: > On Wed, Aug 20, 2014 at 5:22 AM, Chanwoo Choi wrote: >> This patch add support for TRIM_RELOAD feature at Exynos3250. The TMU of >> Exynos3250 has two TRIMINFO_CON register. >> >> Signed-off-by: Chanwoo Choi >> Acked-by: Kyungmin Park >> Cc: Zhang Rui >> Cc: Eduardo Valentin >> Cc: Amit Daniel Kachhap > The changes looks fine, > Reviewed-by: Amit Daniel Kachhap > Thanks for your review. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
On Wed, Aug 20, 2014 at 5:22 AM, Chanwoo Choi wrote:
> This patch add support for TRIM_RELOAD feature at Exynos3250. The TMU of
> Exynos3250 has two TRIMINFO_CON register.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: Amit Daniel Kachhap
The changes looks fine,
Reviewed-by: Amit Daniel Kachhap
Thanks,
Amit
> ---
> Changes from v2:
> - Fix build break because of missing 'or' operation.
> Changes from v1:
> - Add missing 'TMU_SUPPORT_TRIM_RELOAD' feature
>
> drivers/thermal/samsung/exynos_tmu.c | 7 +--
> drivers/thermal/samsung/exynos_tmu.h | 5 +++--
> drivers/thermal/samsung/exynos_tmu_data.c | 11 +--
> drivers/thermal/samsung/exynos_tmu_data.h | 7 +--
> 4 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index acbff14..ed01606 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -164,8 +164,11 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> }
> }
>
> - if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
> - __raw_writel(1, data->base + reg->triminfo_ctrl);
> + if (TMU_SUPPORTS(pdata, TRIM_RELOAD)) {
> + for (i = 0; i < pdata->triminfo_reload_count; i++)
> + __raw_writel(pdata->triminfo_reload[i],
> + data->base + reg->triminfo_ctrl[i]);
> + }
>
> if (pdata->cal_mode == HW_MODE)
> goto skip_calib_data;
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h
> index 1b4a644..72cb54e 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -151,8 +151,7 @@ struct exynos_tmu_registers {
> u32 triminfo_25_shift;
> u32 triminfo_85_shift;
>
> - u32 triminfo_ctrl;
> - u32 triminfo_ctrl1;
> + u32 triminfo_ctrl[2];
> u32 triminfo_reload_shift;
>
> u32 tmu_ctrl;
> @@ -295,6 +294,8 @@ struct exynos_tmu_platform_data {
> u8 second_point_trim;
> u8 default_temp_offset;
> u8 test_mux;
> + u8 triminfo_reload[2];
> + u8 triminfo_reload_count;
>
> enum calibration_type cal_type;
> enum calibration_mode cal_mode;
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index aa8e0de..8cd609c 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -95,6 +95,8 @@ static const struct exynos_tmu_registers
> exynos3250_tmu_registers = {
> .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
> .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
> + .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON1,
> + .triminfo_ctrl[1] = EXYNOS_TMU_TRIMINFO_CON2,
> .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
> .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
> .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
> @@ -160,8 +162,11 @@ static const struct exynos_tmu_registers
> exynos3250_tmu_registers = {
> .temp_level = 95, \
> }, \
> .freq_tab_count = 2, \
> + .triminfo_reload[0] = 0x1, \
> + .triminfo_reload[1] = 0x11, \
> + .triminfo_reload_count = 2, \
> .registers = _tmu_registers, \
> - .features = (TMU_SUPPORT_EMULATION | \
> + .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
> TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS |
> \
> TMU_SUPPORT_EMUL_TIME)
> #endif
> @@ -184,7 +189,7 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
> .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
> .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
> - .triminfo_ctrl = EXYNOS_TMU_TRIMINFO_CON,
> + .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON2,
> .triminfo_reload_shift = EXYNOS_TRIMINFO_RELOAD_SHIFT,
> .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
> .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
> @@ -252,6 +257,8 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
> .temp_level = 95, \
> }, \
> .freq_tab_count = 2, \
> + .triminfo_reload[0] = 0x1, \
> + .triminfo_reload_count = 1, \
> .registers = _tmu_registers, \
> .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
> TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS |
> \
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
> b/drivers/thermal/samsung/exynos_tmu_data.h
> index f0979e5..e0536c3 100644
> ---
Re: [PATCH v2 2/4] zsmalloc: change return value unit of zs_get_total_size_bytes
On Wed, Aug 20, 2014 at 08:46:21AM +0900, Minchan Kim wrote:
> Hey Seth,
>
> On Tue, Aug 19, 2014 at 09:46:28AM -0500, Seth Jennings wrote:
> > On Tue, Aug 19, 2014 at 04:54:45PM +0900, Minchan Kim wrote:
> > > zs_get_total_size_bytes returns a amount of memory zsmalloc
> > > consumed with *byte unit* but zsmalloc operates *page unit*
> > > rather than byte unit so let's change the API so benefit
> > > we could get is that reduce unnecessary overhead
> > > (ie, change page unit with byte unit) in zsmalloc.
> > >
> > > Now, zswap can rollback to zswap_pool_pages.
> > > Over to zswap guys ;-)
> >
> > I don't think that's how is it done :-/ Changing the API for a
> > component that has two users, changing one, then saying "hope you guys
> > change your newly broken stuff".
>
> I don't get it. The zsmalloc's zs_zpool_total_size returns u64 with bytes,
> not pages so what's broken stuff you mentioned?
>
> static u64 zs_zpool_total_size(void *pool)
> {
> - return zs_get_total_size_bytes(pool);
> + return zs_get_total_size(pool) << PAGE_SHIFT;
> }
Ah, that's my bad. I forgot that there is zs_get_total_size() and
zs_pool_total_size() and that the zpool driver calls
zs_pool_total_size(), not zs_get_total_size().
Nevermind!
Seth
>
> Thing I nudged to you is just you could roll back to pages count
> instead of bytes if zswap guys want it and I dont' want it myself
> for avoding unnecessary noise for this patchset's purpose.
>
> >
> > I know you would rather not move zram to the zpool API but doing so
> > would avoid situations like this.
> >
> > Anyway, this does break the zpool API and by extension zswap, and that
> > needs to be addressed in this patch or we create a point in the commit
> > history where it is broken.
> >
> > Quick glance:
> > - zpool_get_total_size() return type is u64 but this patch changes to
> > unsigned long. Now mismatches between zbud and zsmalloc.
>
> Nope. zs_zpool_total_size returns u64 with PAGE_SHIFT.
>
> > - zbud_zpool_total_size needs to return pages, not bytes
>
> It's up to you, not me.
>
> > - as you noted s/pool_total_size/pool_pages/g in zswap.c plus
> > modification to zswap_is_full()
>
> I didn't mean it. Sorry for the confusing.
> If I miss your point, let me know it.
>
> Thanks.
>
> >
> > Thanks,
> > Seth
> >
> > >
> > > Signed-off-by: Minchan Kim
> > > ---
> > > drivers/block/zram/zram_drv.c | 4 ++--
> > > include/linux/zsmalloc.h | 2 +-
> > > mm/zsmalloc.c | 10 +-
> > > 3 files changed, 8 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > > index d00831c3d731..302dd37bcea3 100644
> > > --- a/drivers/block/zram/zram_drv.c
> > > +++ b/drivers/block/zram/zram_drv.c
> > > @@ -103,10 +103,10 @@ static ssize_t mem_used_total_show(struct device
> > > *dev,
> > >
> > > down_read(>init_lock);
> > > if (init_done(zram))
> > > - val = zs_get_total_size_bytes(meta->mem_pool);
> > > + val = zs_get_total_size(meta->mem_pool);
> > > up_read(>init_lock);
> > >
> > > - return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
> > > + return scnprintf(buf, PAGE_SIZE, "%llu\n", val << PAGE_SHIFT);
> > > }
> > >
> > > static ssize_t max_comp_streams_show(struct device *dev,
> > > diff --git a/include/linux/zsmalloc.h b/include/linux/zsmalloc.h
> > > index e44d634e7fb7..105b56e45d23 100644
> > > --- a/include/linux/zsmalloc.h
> > > +++ b/include/linux/zsmalloc.h
> > > @@ -46,6 +46,6 @@ void *zs_map_object(struct zs_pool *pool, unsigned long
> > > handle,
> > > enum zs_mapmode mm);
> > > void zs_unmap_object(struct zs_pool *pool, unsigned long handle);
> > >
> > > -u64 zs_get_total_size_bytes(struct zs_pool *pool);
> > > +unsigned long zs_get_total_size(struct zs_pool *pool);
> > >
> > > #endif
> > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > > index a65924255763..80408a1da03a 100644
> > > --- a/mm/zsmalloc.c
> > > +++ b/mm/zsmalloc.c
> > > @@ -299,7 +299,7 @@ static void zs_zpool_unmap(void *pool, unsigned long
> > > handle)
> > >
> > > static u64 zs_zpool_total_size(void *pool)
> > > {
> > > - return zs_get_total_size_bytes(pool);
> > > + return zs_get_total_size(pool) << PAGE_SHIFT;
> > > }
> > >
> > > static struct zpool_driver zs_zpool_driver = {
> > > @@ -1186,16 +1186,16 @@ void zs_unmap_object(struct zs_pool *pool,
> > > unsigned long handle)
> > > }
> > > EXPORT_SYMBOL_GPL(zs_unmap_object);
> > >
> > > -u64 zs_get_total_size_bytes(struct zs_pool *pool)
> > > +unsigned long zs_get_total_size(struct zs_pool *pool)
> > > {
> > > - u64 npages;
> > > + unsigned long npages;
> > >
> > > spin_lock(>stat_lock);
> > > npages = pool->pages_allocated;
> > > spin_unlock(>stat_lock);
> > > - return npages << PAGE_SHIFT;
> > > + return npages;
> > > }
> > > -EXPORT_SYMBOL_GPL(zs_get_total_size_bytes);
> > > +EXPORT_SYMBOL_GPL(zs_get_total_size);
> > >
> > > module_init(zs_init);
>
Re: [PATCH v1 3/3] ARM: dts: Add TLMM DT node for apq8084
On Tue 19 Aug 10:22 PDT 2014, Georgi Djakov wrote:
> This patch adds the TLMM node for the apq8084 platform.
>
> Signed-off-by: Georgi Djakov
> ---
> arch/arm/boot/dts/qcom-apq8084.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
> b/arch/arm/boot/dts/qcom-apq8084.dtsi
> index b5b156e..21d01e5 100644
> --- a/arch/arm/boot/dts/qcom-apq8084.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
> @@ -185,6 +185,16 @@
> reg = <0xfc40 0x4000>;
> };
>
> + tlmm: pinctrl@fd51 {
> + compatible = "qcom,apq8084-pinctrl";
> + reg = <0xfd51 0x4000>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <0 208 0>;
> + };
> +
> serial@f995e000 {
> compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> reg = <0xf995e000 0x1000>;
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/3] pinctrl: qcom: Add APQ8084 pinctrl support
On Tue 19 Aug 10:22 PDT 2014, Georgi Djakov wrote: > This patch adds support for the TLMM (Top-Level Mode Mux) block found > in the APQ8084 platform. > [...] > + > +#define NUM_GPIO_PINGROUPS 143 > + I think this looks good overall, but in my APQ8084 documentation (80-NG550-2X Rev. B) there are 147 (0..146) gpio pins in the TLMM block. Any suggestion to why there's a discrepancy? Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Install udev rules in system-default directory
On (Tue) 19 Aug 2014 [19:20:20], Paolo Bonzini wrote: > Il 07/08/2014 15:09, Amit Shah ha scritto: > > +udevrules_DATA = 90-virtio-rng.rules > > If rng-tools is packaged with "make dist" you need this to be > > dist_udevrules_DATA= 90-virtio-rng.rules > > or alternatively > > EXTRA_DIST = 90-virtio-rng.rules > udevrules_DATA = 90-virtio-rng.rules > > > +AC_ARG_WITH([udevrulesdir], > > + AS_HELP_STRING([--with-udevrulesdir=DIR], [Directory for udev rules]), > > + [], > > + [with_udevrulesdir=$($PKG_CONFIG --variable=udevdir udev)"/rules.d"]) > > +AC_SUBST([udevrulesdir], [$with_udevrulesdir]) > > You can use AM_CONDITIONAL to skip the installation if > $with_udevrulesdir is "no" (aka --without-udevrulesdir). Then you'd have > > EXTRA_DIST = 90-virtio-rng.rules > if INSTALL_UDEV_RULES > udevrules_DATA = 90-virtio-rng.rules > endif > > I don't know offhand if this works: > > if INSTALL_UDEV_RULES > dist_udevrules_DATA= 90-virtio-rng.rules > endif > > but I think so; you can check with "./configure --without-udevrulesdir > && make && make dist". Thanks! Will give this a shot for curiosity's sake. The khwrngd-based patch has already been merged upstream, so this is now obsolete. Amit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] usbip: move usbip kernel code out of staging
At this point, USB/IP kernel code is fully functional
and can be moved out of staging.
Signed-off-by: Valentina Manea
---
drivers/staging/Kconfig| 2 --
drivers/staging/Makefile | 1 -
drivers/usb/Kconfig| 2 ++
drivers/usb/Makefile | 2 ++
drivers/{staging => usb}/usbip/Kconfig | 0
drivers/{staging => usb}/usbip/Makefile| 0
drivers/{staging => usb}/usbip/README | 0
drivers/{staging => usb}/usbip/stub.h | 0
drivers/{staging => usb}/usbip/stub_dev.c | 0
drivers/{staging => usb}/usbip/stub_main.c | 0
drivers/{staging => usb}/usbip/stub_rx.c | 0
drivers/{staging => usb}/usbip/stub_tx.c | 0
drivers/{staging => usb}/usbip/usbip_common.c | 0
drivers/{staging => usb}/usbip/usbip_common.h | 2 +-
drivers/{staging => usb}/usbip/usbip_event.c | 0
drivers/{staging => usb}/usbip/usbip_protocol.txt | 0
drivers/{staging => usb}/usbip/vhci.h | 0
drivers/{staging => usb}/usbip/vhci_hcd.c | 0
drivers/{staging => usb}/usbip/vhci_rx.c | 0
drivers/{staging => usb}/usbip/vhci_sysfs.c| 0
drivers/{staging => usb}/usbip/vhci_tx.c | 0
{drivers/staging/usbip/uapi => include/uapi/linux}/usbip.h | 0
22 files changed, 5 insertions(+), 4 deletions(-)
rename drivers/{staging => usb}/usbip/Kconfig (100%)
rename drivers/{staging => usb}/usbip/Makefile (100%)
rename drivers/{staging => usb}/usbip/README (100%)
rename drivers/{staging => usb}/usbip/stub.h (100%)
rename drivers/{staging => usb}/usbip/stub_dev.c (100%)
rename drivers/{staging => usb}/usbip/stub_main.c (100%)
rename drivers/{staging => usb}/usbip/stub_rx.c (100%)
rename drivers/{staging => usb}/usbip/stub_tx.c (100%)
rename drivers/{staging => usb}/usbip/usbip_common.c (100%)
rename drivers/{staging => usb}/usbip/usbip_common.h (99%)
rename drivers/{staging => usb}/usbip/usbip_event.c (100%)
rename drivers/{staging => usb}/usbip/usbip_protocol.txt (100%)
rename drivers/{staging => usb}/usbip/vhci.h (100%)
rename drivers/{staging => usb}/usbip/vhci_hcd.c (100%)
rename drivers/{staging => usb}/usbip/vhci_rx.c (100%)
rename drivers/{staging => usb}/usbip/vhci_sysfs.c (100%)
rename drivers/{staging => usb}/usbip/vhci_tx.c (100%)
rename {drivers/staging/usbip/uapi => include/uapi/linux}/usbip.h (100%)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 2c486ea..35b494f 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -28,8 +28,6 @@ source "drivers/staging/et131x/Kconfig"
source "drivers/staging/slicoss/Kconfig"
-source "drivers/staging/usbip/Kconfig"
-
source "drivers/staging/wlan-ng/Kconfig"
source "drivers/staging/comedi/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 1e1a3a1..e66a5db 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -6,7 +6,6 @@ obj-$(CONFIG_STAGING) += staging.o
obj-y += media/
obj-$(CONFIG_ET131X) += et131x/
obj-$(CONFIG_SLICOSS) += slicoss/
-obj-$(CONFIG_USBIP_CORE) += usbip/
obj-$(CONFIG_PRISM2_USB) += wlan-ng/
obj-$(CONFIG_COMEDI) += comedi/
obj-$(CONFIG_FB_OLPC_DCON) += olpc_dcon/
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index e0cad44..cf1b19b 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -92,6 +92,8 @@ source "drivers/usb/storage/Kconfig"
source "drivers/usb/image/Kconfig"
+source "drivers/usb/usbip/Kconfig"
+
endif
source "drivers/usb/musb/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 3cba892..d7be717 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -60,3 +60,5 @@ obj-$(CONFIG_USB_RENESAS_USBHS) += renesas_usbhs/
obj-$(CONFIG_USB_GADGET) += gadget/
obj-$(CONFIG_USB_COMMON) += common/
+
+obj-$(CONFIG_USBIP_CORE) += usbip/
diff --git a/drivers/staging/usbip/Kconfig b/drivers/usb/usbip/Kconfig
similarity index 100%
rename from drivers/staging/usbip/Kconfig
rename to drivers/usb/usbip/Kconfig
diff --git a/drivers/staging/usbip/Makefile b/drivers/usb/usbip/Makefile
similarity index 100%
rename from drivers/staging/usbip/Makefile
rename to drivers/usb/usbip/Makefile
diff --git a/drivers/staging/usbip/README b/drivers/usb/usbip/README
similarity index 100%
rename from drivers/staging/usbip/README
rename to drivers/usb/usbip/README
diff --git a/drivers/staging/usbip/stub.h b/drivers/usb/usbip/stub.h
similarity index 100%
rename from drivers/staging/usbip/stub.h
rename to drivers/usb/usbip/stub.h
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
similarity index 100%
rename from
[PATCH 3/4] usbip: remove struct usb_device_id table
This was used back when usbip-host was an interface device driver;
after the conversion to device driver, the table remained unused.
Remove it in order to stop receiving a warning about it.
Signed-off-by: Valentina Manea
---
drivers/usb/usbip/stub_dev.c | 27 ---
1 file changed, 27 deletions(-)
diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
index 51d0c71..fac20e0 100644
--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -26,33 +26,6 @@
#include "stub.h"
/*
- * Define device IDs here if you want to explicitly limit exportable devices.
- * In most cases, wildcard matching will be okay because driver binding can be
- * changed dynamically by a userland program.
- */
-static struct usb_device_id stub_table[] = {
-#if 0
- /* just an example */
- { USB_DEVICE(0x05ac, 0x0301) }, /* Mac 1 button mouse */
- { USB_DEVICE(0x0430, 0x0009) }, /* Plat Home Keyboard */
- { USB_DEVICE(0x059b, 0x0001) }, /* Iomega USB Zip 100 */
- { USB_DEVICE(0x04b3, 0x4427) }, /* IBM USB CD-ROM */
- { USB_DEVICE(0x05a9, 0xa511) }, /* LifeView USB cam */
- { USB_DEVICE(0x55aa, 0x0201) }, /* Imation card reader */
- { USB_DEVICE(0x046d, 0x0870) }, /* Qcam Express(QV-30) */
- { USB_DEVICE(0x04bb, 0x0101) }, /* IO-DATA HD 120GB */
- { USB_DEVICE(0x04bb, 0x0904) }, /* IO-DATA USB-ET/TX */
- { USB_DEVICE(0x04bb, 0x0201) }, /* IO-DATA USB-ET/TX */
- { USB_DEVICE(0x08bb, 0x2702) }, /* ONKYO USB Speaker */
- { USB_DEVICE(0x046d, 0x08b2) }, /* Logicool Qcam 4000 Pro */
-#endif
- /* magic for wild card */
- { .driver_info = 1 },
- { 0, } /* Terminating entry */
-};
-MODULE_DEVICE_TABLE(usb, stub_table);
-
-/*
* usbip_status shows the status of usbip-host as long as this driver is bound
* to the target device.
*/
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] MAINTAINERS: Add an entry for USB/IP driver
This patch adds an entry in MAINTAINERS file for USB/IP driver. Signed-off-by: Valentina Manea --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index aefa948..76ac03d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9515,6 +9515,14 @@ S: Maintained F: Documentation/usb/ohci.txt F: drivers/usb/host/ohci* +USB OVER IP DRIVER +M: Valentina Manea +M: Shuah Khan +L: linux-...@vger.kernel.org +S: Maintained +F: drivers/usb/usbip/ +F: tools/usb/usbip/ + USB PEGASUS DRIVER M: Petko Manolov L: linux-...@vger.kernel.org -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] usbip: move usbip userspace code out of staging
At this point, USB/IP userspace code is fully functional
and can be moved out of staging.
Signed-off-by: Valentina Manea
---
{drivers/staging/usbip/userspace => tools/usb/usbip}/.gitignore | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/AUTHORS | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/COPYING | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/INSTALL | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/Makefile.am | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/README | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/autogen.sh | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/cleanup.sh | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/configure.ac | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbip.8 | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbipd.8 | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/Makefile.am | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/list.h| 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.h | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/sysfs_utils.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/sysfs_utils.h | 0
.../staging/usbip/userspace => tools/usb/usbip}/libsrc/usbip_common.c | 0
.../staging/usbip/userspace => tools/usb/usbip}/libsrc/usbip_common.h | 0
.../usbip/userspace => tools/usb/usbip}/libsrc/usbip_host_driver.c| 0
.../usbip/userspace => tools/usb/usbip}/libsrc/usbip_host_driver.h| 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/vhci_driver.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/vhci_driver.h | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/Makefile.am | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip.h | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_attach.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_bind.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_detach.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_list.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_network.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_network.h | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_port.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_unbind.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbipd.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/utils.c | 0
{drivers/staging/usbip/userspace => tools/usb/usbip}/src/utils.h | 0
37 files changed, 0 insertions(+), 0 deletions(-)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/.gitignore (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/AUTHORS (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/COPYING (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/INSTALL (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/Makefile.am (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/README (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/autogen.sh (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/cleanup.sh (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/configure.ac (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbip.8 (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbipd.8 (100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/Makefile.am
(100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/list.h
(100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.c
(100%)
rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.h
(100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/sysfs_utils.c (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/sysfs_utils.h (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/usbip_common.c (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/usbip_common.h (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/usbip_host_driver.c (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/usbip_host_driver.h (100%)
rename {drivers/staging/usbip/userspace =>
tools/usb/usbip}/libsrc/vhci_driver.c (100%)
rename {drivers/staging/usbip/userspace =>
[PATCH 0/4] *** SUBJECT HERE ***
After migrating userspace code to libudev, converting usbip-host
to a device driver and various bug fixes and enhancements, USB/IP
is fully functional and can be moved out of staging.
This patch series moves it as following:
* userspace code to tools/usb/usbip
* kernel code to drivers/usb/usbip
A warning generated in the kernel code is also solved and an entry
in MAINTAINERS file is created for this driver.
Valentina Manea (4):
usbip: move usbip userspace code out of staging
usbip: move usbip kernel code out of staging
usbip: remove struct usb_device_id table
MAINTAINERS: Add an entry for USB/IP driver
MAINTAINERS| 8 +++
drivers/staging/Kconfig| 2 --
drivers/staging/Makefile | 1 -
drivers/usb/Kconfig| 2 ++
drivers/usb/Makefile | 2 ++
drivers/{staging => usb}/usbip/Kconfig | 0
drivers/{staging => usb}/usbip/Makefile| 0
drivers/{staging => usb}/usbip/README | 0
drivers/{staging => usb}/usbip/stub.h | 0
drivers/{staging => usb}/usbip/stub_dev.c | 27 --
drivers/{staging => usb}/usbip/stub_main.c | 0
drivers/{staging => usb}/usbip/stub_rx.c | 0
drivers/{staging => usb}/usbip/stub_tx.c | 0
drivers/{staging => usb}/usbip/usbip_common.c | 0
drivers/{staging => usb}/usbip/usbip_common.h | 2 +-
drivers/{staging => usb}/usbip/usbip_event.c | 0
drivers/{staging => usb}/usbip/usbip_protocol.txt | 0
drivers/{staging => usb}/usbip/vhci.h | 0
drivers/{staging => usb}/usbip/vhci_hcd.c | 0
drivers/{staging => usb}/usbip/vhci_rx.c | 0
drivers/{staging => usb}/usbip/vhci_sysfs.c| 0
drivers/{staging => usb}/usbip/vhci_tx.c | 0
.../usbip/uapi => include/uapi/linux}/usbip.h | 0
.../usbip/userspace => tools/usb/usbip}/.gitignore | 0
.../usbip/userspace => tools/usb/usbip}/AUTHORS| 0
.../usbip/userspace => tools/usb/usbip}/COPYING| 0
.../usbip/userspace => tools/usb/usbip}/INSTALL| 0
.../userspace => tools/usb/usbip}/Makefile.am | 0
.../usbip/userspace => tools/usb/usbip}/README | 0
.../usbip/userspace => tools/usb/usbip}/autogen.sh | 0
.../usbip/userspace => tools/usb/usbip}/cleanup.sh | 0
.../userspace => tools/usb/usbip}/configure.ac | 0
.../userspace => tools/usb/usbip}/doc/usbip.8 | 0
.../userspace => tools/usb/usbip}/doc/usbipd.8 | 0
.../usb/usbip}/libsrc/Makefile.am | 0
.../userspace => tools/usb/usbip}/libsrc/list.h| 0
.../userspace => tools/usb/usbip}/libsrc/names.c | 0
.../userspace => tools/usb/usbip}/libsrc/names.h | 0
.../usb/usbip}/libsrc/sysfs_utils.c| 0
.../usb/usbip}/libsrc/sysfs_utils.h| 0
.../usb/usbip}/libsrc/usbip_common.c | 0
.../usb/usbip}/libsrc/usbip_common.h | 0
.../usb/usbip}/libsrc/usbip_host_driver.c | 0
.../usb/usbip}/libsrc/usbip_host_driver.h | 0
.../usb/usbip}/libsrc/vhci_driver.c| 0
.../usb/usbip}/libsrc/vhci_driver.h| 0
.../userspace => tools/usb/usbip}/src/Makefile.am | 0
.../userspace => tools/usb/usbip}/src/usbip.c | 0
.../userspace => tools/usb/usbip}/src/usbip.h | 0
.../usb/usbip}/src/usbip_attach.c | 0
.../userspace => tools/usb/usbip}/src/usbip_bind.c | 0
.../usb/usbip}/src/usbip_detach.c | 0
.../userspace => tools/usb/usbip}/src/usbip_list.c | 0
.../usb/usbip}/src/usbip_network.c | 0
.../usb/usbip}/src/usbip_network.h | 0
.../userspace => tools/usb/usbip}/src/usbip_port.c | 0
.../usb/usbip}/src/usbip_unbind.c | 0
.../userspace => tools/usb/usbip}/src/usbipd.c | 0
.../userspace => tools/usb/usbip}/src/utils.c | 0
.../userspace => tools/usb/usbip}/src/utils.h | 0
60 files changed, 13 insertions(+), 31 deletions(-)
rename drivers/{staging => usb}/usbip/Kconfig (100%)
rename drivers/{staging => usb}/usbip/Makefile (100%)
rename drivers/{staging => usb}/usbip/README (100%)
rename drivers/{staging => usb}/usbip/stub.h (100%)
rename drivers/{staging => usb}/usbip/stub_dev.c (90%)
rename drivers/{staging => usb}/usbip/stub_main.c (100%)
rename drivers/{staging => usb}/usbip/stub_rx.c (100%)
rename drivers/{staging => usb}/usbip/stub_tx.c (100%)
rename drivers/{staging => usb}/usbip/usbip_common.c (100%)
rename drivers/{staging => usb}/usbip/usbip_common.h (99%)
rename drivers/{staging => usb}/usbip/usbip_event.c (100%)
rename drivers/{staging => usb}/usbip/usbip_protocol.txt (100%)
rename drivers/{staging => usb}/usbip/vhci.h (100%)
rename drivers/{staging => usb}/usbip/vhci_hcd.c (100%)
rename drivers/{staging => usb}/usbip/vhci_rx.c (100%)
[PATCH] thermal: exynos: Remove duplicate code when reading triminfo register of Exynos5440
This patch remove simply duplicate code when reading triminfo register of
Exynos5440.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Cc: Zhang Rui
Cc: Eduardo Valentin
Cc: Amit Daniel Kachhap
---
drivers/thermal/samsung/exynos_tmu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index ed01606..13c2e01 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -181,15 +181,13 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
*/
switch (data->id) {
case 0:
+ case 2:
trim_info = readl(data->base +
EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
break;
case 1:
trim_info = readl(data->base + reg->triminfo_data);
break;
- case 2:
- trim_info = readl(data->base -
- EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
}
} else {
/* On exynos5420 the triminfo register is in the shared space */
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] nfs: fix kernel warning when removing proc entry
Cong Wang writes:
> I saw the following kernel warning:
Cong thanks for finding and tracking this. I was clearly asleep at the
switch when I was testing my fix to the nfs client code :(
I have applied this patch and will push it to Linus after it has a
little bit to sit in linux-next.
Eric
> [ 1852.321222] [ cut here ]
> [ 1852.326527] WARNING: CPU: 0 PID: 118 at fs/proc/generic.c:521
> remove_proc_entry+0x154/0x16b()
> [ 1852.335630] remove_proc_entry: removing non-empty directory 'fs/nfsfs',
> leaking at least 'volumes'
> [ 1852.344084] CPU: 0 PID: 118 Comm: kworker/u8:2 Not tainted 3.16.0+ #540
> [ 1852.350036] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 1852.354992] Workqueue: netns cleanup_net
> [ 1852.358701] 880116f2fbd0 819c03e9
> 880116f2fc18
> [ 1852.366474] 880116f2fc08 810744ee 811e0e6e
> 8800d4e96238
> [ 1852.373507] 81dbe665 8800d46a5948 0005
> 880116f2fc68
> [ 1852.380224] Call Trace:
> [ 1852.381976] [] dump_stack+0x4d/0x66
> [ 1852.385495] [] warn_slowpath_common+0x7a/0x93
> [ 1852.389869] [] ? remove_proc_entry+0x154/0x16b
> [ 1852.393987] [] warn_slowpath_fmt+0x4c/0x4e
> [ 1852.397999] [] remove_proc_entry+0x154/0x16b
> [ 1852.402034] [] nfs_fs_proc_net_exit+0x53/0x56
> [ 1852.406136] [] nfs_net_exit+0x12/0x1d
> [ 1852.409774] [] ops_exit_list+0x44/0x55
> [ 1852.413529] [] cleanup_net+0xee/0x182
> [ 1852.417198] [] process_one_work+0x209/0x40d
> [ 1852.502320] [] ? process_one_work+0x162/0x40d
> [ 1852.587629] [] worker_thread+0x1f0/0x2c7
> [ 1852.673291] [] ? process_scheduled_works+0x2f/0x2f
> [ 1852.759470] [] kthread+0xc9/0xd1
> [ 1852.843099] [] ? finish_task_switch+0x3a/0xce
> [ 1852.926518] [] ? __kthread_parkme+0x61/0x61
> [ 1853.008565] [] ret_from_fork+0x7c/0xb0
> [ 1853.076477] [] ? __kthread_parkme+0x61/0x61
> [ 1853.140653] ---[ end trace 69c4c6617f78e32d ]---
>
> It looks wrong that we add "/proc/net/nfsfs" in nfs_fs_proc_net_init()
> while remove "/proc/fs/nfsfs" in nfs_fs_proc_net_exit().
>
> Fixes: commit 65b38851a17 (NFS: Fix /proc/fs/nfsfs/servers and
> /proc/fs/nfsfs/volumes)
> Cc: Eric W. Biederman
> Cc: Trond Myklebust
> Cc: Dan Aloni
> Signed-off-by: Cong Wang
> ---
> v2 - fix nfs_fs_proc_net_init() as well
>
> fs/nfs/client.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/client.c b/fs/nfs/client.c
> index 1c5ff6d..c117b96 100644
> --- a/fs/nfs/client.c
> +++ b/fs/nfs/client.c
> @@ -1418,7 +1418,7 @@ int nfs_fs_proc_net_init(struct net *net)
> error_2:
> remove_proc_entry("servers", nn->proc_nfsfs);
> error_1:
> - remove_proc_entry("fs/nfsfs", NULL);
> + remove_proc_entry("nfsfs", net->proc_net);
> error_0:
> return -ENOMEM;
> }
> @@ -1429,7 +1429,7 @@ void nfs_fs_proc_net_exit(struct net *net)
>
> remove_proc_entry("volumes", nn->proc_nfsfs);
> remove_proc_entry("servers", nn->proc_nfsfs);
> - remove_proc_entry("fs/nfsfs", NULL);
> + remove_proc_entry("nfsfs", net->proc_net);
> }
>
> /*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 05/18] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init
Hi Bob,
On 2014-8-20 6:55, Moore, Robert wrote:
> I should warn you that FADT version numbers are notoriously unreliable;
> In fact, in ACPICA we were eventually forced to abandon them entirely.
> We use the actual size of the FADT instead.
Yes, I heard that story, thanks for the reminding. But I also see that the
revision number is used on x86 and ia64 now in parsing FADT, it is a firmware
bug not to comply with the spec, and on ARM, only ACPI 5.1 or higher can be
used in Linux, Major.Minor revision was introduced in ACPI 5.1 and it was a
major change for it, so I think firmware should comply with that, if firmware
just copy some code from somewhere else and leave the revision number
unchanged, we will not boot (disable ACPI).
The size of FADT for 5.0 and 5.1 is no difference, it is pretty hard to use
that to identify the version of FADT, did I miss something?
Thanks
Hanjun
>
> Bob
>
>
>
>> -Original Message-
>> From: Hanjun Guo [mailto:hanjun@linaro.org]
>> Sent: Tuesday, August 19, 2014 5:14 AM
>> To: Mark Rutland
>> Cc: Catalin Marinas; Rafael J. Wysocki; graeme.greg...@linaro.org; Arnd
>> Bergmann; Olof Johansson; grant.lik...@linaro.org; Sudeep Holla; Will
>> Deacon; Jason Cooper; Marc Zyngier; Bjorn Helgaas; Daniel Lezcano; Mark
>> Brown; Rob Herring; Robert Richter; Zheng, Lv; Moore, Robert; Lorenzo
>> Pieralisi; Liviu Dudau; Randy Dunlap; Charles Garcia-Tobin; linux-
>> a...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
>> ker...@vger.kernel.org; linaro-a...@lists.linaro.org
>> Subject: Re: [PATCH v2 05/18] ARM64 / ACPI: Parse FADT table to get PSCI
>> flags for PSCI init
>>
>> On 2014-8-19 19:10, Mark Rutland wrote:
>> @@ -47,6 +49,26 @@ void __init __acpi_unmap_table(char *map, unsigned
>> long size)
>> early_memunmap(map, size);
>> }
>>
>> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> +{
>> +struct acpi_table_fadt *fadt = (struct acpi_table_fadt
>> *)table;
>> +
>> +/*
>> + * Revision in table header is the FADT Major version,
>> + * and there is a minor version of FADT which was introduced
>> + * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
>> + * to get arm boot flags, or we will disable ACPI.
>> + */
>> +if (table->revision < 5 || fadt->minor_revision < 1) {
>
> If we ever get revision 6.0, this would trigger.
Yes, good catch, actually I already fixed that in my local git repo,
+ if (table->revision > 5 ||
+ (table->revision == 5 && fadt->minor_revision >= 1)) {
+ return 0;
+ } else {
+ pr_info("FADT revision is %d.%d, no PSCI support,
+ should be 5.1
or higher\n",
+ table->revision, fadt->minor_revision);
+ disable_acpi();
+ return -EINVAL;
+ }
>>>
>>> Given you return in the first path, you don't need the remaining code
>>> to live in an else block.
>>
>> Agreed, I will update it, and move disable_acpi() outside this function
>> and keep it in one place as Sudeep suggested.
>>
>> Thanks
>> Hanjun
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 0/6] namespaces: log namespaces per task
Richard Guy Briggs writes: > On 14/05/20, Richard Guy Briggs wrote: >> On 14/05/20, Eric Paris wrote: >> > On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote: >> > > The purpose is to track namespaces in use by logged processes from the >> > > perspective of init_*_ns. > > (Including the Linux API list due to the additions to /proc//ns/. > Please see http://www.kernelhub.org/?p=2=477668 and in particular > http://www.kernelhub.org/?msg=477678=2 ) Sigh if you have to use something like this use the proc inode number. It is the same thing. I hate to claim it is unique absent of the proc superblock but it is and will be for the forseable future. It would be better to include the block device number that appears in proc of 3h of the primary mount of to qualify the number. But it is not particularly important. Coming up with an additional unique number that needs to be maintained seems stronlgy silly. Eric > > >> > > 5/6 provides an example of usage for audit_log_task_info() which is used >> > > by >> > > syscall audits, among others. audit_log_task() and >> > > audit_common_recv_message() >> > > would be other potential use cases. >> > > >> > > Proposed output format: >> > > This differs slightly from Aristeu's patch because of the label conflict >> > > with >> > > "pid=" due to including it in existing records rather than it being a >> > > seperate >> > > record. The serial numbers are printed in hex. >> > > type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272 >> > > success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0 >> > > ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 >> > > sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)" >> > > exe="/usr/lib/systemd/systemd" netns=97 utsns=2 ipcns=1 pidns=4 userns=3 >> > > mntns=5 subj=system_u:system_r:init_t:s0 key=(null) >> > >> > I'm undecided if I'd rather see this as a separate NS_INFO record type. >> > It would mean we could filter them out of the logs... >> >> I don't have a strong opinion either way. Steve G.'s opinion would be >> helpful here. > > Breaking this out into a seperate record type would mean calling > audit_log_namespace_info() from the callers of audit_log_task_info() > (presently audit_log_link_denied(), ima_audit_measurement(), > audit_log_exit() ), but would make it easier to emit with other record > types. > >> > Do we print out lots of pidns=0 for tasks not in a newly created NS? Do >> > we want to? >> >> There is no "pidns=0", but I understand your point. This would come >> back to Steve G.'s point about disappearing fields, and the value of >> having it as a seperate record that could be filtered. >> >> > > 6/6 tracks the creation and deletion of of namespaces, listing the type >> > > of >> > > namespace instance, related namespace id if there is one and the newly >> > > minted >> > > serial number. >> > > >> > > Proposed output format: >> > > type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0 >> > > auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 >> > > type=2 old_snum=0 snum=a1 res=1 >> > >> > I'd love to be able to grep for netns=20 and find both the NS_INIT and >> > the SYSCALL/NS_INFO records, instead of having them named different >> > things. So basically I think you want to translate the type= into a >> > string for the old_X= and X=... >> >> That actually makes a bit more sense, and we could do away with the >> "type=" field since the "Xns=" fields are self-describing. > > Steve, how do you feel about this since the NS_INIT/NS_DEL record type > would have changing fields amongst the 6 namespace types. Only one of > the 6 would be present in each message. I suppose we could have an > NS_INIT_XXX/NS_DEL_XXX for each namespace type. > >> - RGB > > - RGB > > -- > Richard Guy Briggs > Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, > Red Hat > Remote, Ottawa, Canada > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc: fsl_pamu_domain: Fix build error
Fix build failure in fsl_pamu_domain.o caused as follows drivers/iommu/fsl_pamu_domain.c: In function 'pamu_domain_init': drivers/iommu/fsl_pamu_domain.c:1103:17: error: 'pci_bus_type' undeclared (first use in this function) drivers/iommu/fsl_pamu_domain.c:1103:17: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [drivers/iommu/fsl_pamu_domain.o] Error 1 make[1]: *** [drivers/iommu] Error 2 make: *** [drivers] Error 2 We fix this by trying to dereference pci_bus_type only if CONFIG_PCI is defined. Signed-off-by: Pranith Kumar --- drivers/iommu/fsl_pamu_domain.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c index 61d1daf..bb56f86 100644 --- a/drivers/iommu/fsl_pamu_domain.c +++ b/drivers/iommu/fsl_pamu_domain.c @@ -1099,7 +1099,9 @@ int pamu_domain_init(void) return ret; bus_set_iommu(_bus_type, _pamu_ops); +#ifdef CONFIG_PCI bus_set_iommu(_bus_type, _pamu_ops); +#endif return ret; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] usbip: move usbip kernel code out of staging
On Tue, Aug 19, 2014 at 08:21:47PM -0700, Valentina Manea wrote: > On Tue, Aug 19, 2014 at 11:38 AM, Greg KH wrote: > > > > This patch moves the code, but now it's "gone" from the build system as > > it is not hooked up and can not be built at all. > > > > So while I really wanted to apply this series right now, I can't, as > > this is a regression (working driver -> no driver). > > You mean it should be in Kbuild and Makefile from drivers/, right? Yes, in drivers/usb/ thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [v2] TAINT_PERFORMANCE
From: Dave Hansen
Changes from v1:
* remove schedstats
* add DEBUG_PAGEALLOC and SLUB_DEBUG_ON
--
I have more than once myself been the victim of an accidentally-
enabled kernel config option being mistaken for a true
performance problem.
I'm sure I've also taken profiles or performance measurements
and assumed they were real-world when really I was measuing the
performance with an option that nobody turns on in production.
A warning like this late in boot will help remind folks when
these kinds of things are enabled.
As for the patch...
I originally wanted this for CONFIG_DEBUG_VM, but I think it also
applies to things like lockdep and slab debugging. See the patch
for the list of offending config options. I'm open to adding
more, but this seemed like a good list to start.
This could be done with Kconfig and an #ifdef to save us 8 bytes
of text and the entry in the late_initcall() section. Doing it
this way lets us keep the list of these things in one spot, and
also gives us a convenient way to dump out the name of the
offending option.
The dump_stack() is really just to be loud.
For anybody that *really* cares, I put the whole thing under
#ifdef CONFIG_DEBUG_KERNEL.
The messages look like this:
[2.534574] CONFIG_LOCKDEP enabled
[2.536392] Do not use this kernel for performance measurement.
[2.547189] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.16.0-10473-gc8d6637-dirty #800
[2.558075] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Bochs 01/01/2011
[2.564483] 8000 88009c70be78 817ce318
[2.582505] 81dca5b6 88009c70be88 81dca5e2
88009c70bef8
[2.588589] 81000377 000700070142
81b78968
[2.592638] Call Trace:
[2.593762] [] dump_stack+0x4e/0x68
[2.597742] [] ? oops_setup+0x2e/0x2e
[2.601247] [] performance_taint+0x2c/0x3c
[2.603498] [] do_one_initcall+0xe7/0x290
[2.606556] [] kernel_init_freeable+0x106/0x19a
[2.609718] [] ? do_early_param+0x86/0x86
[2.613772] [] ? rest_init+0x150/0x150
[2.617333] [] kernel_init+0xe/0xf0
[2.620840] [] ret_from_fork+0x7c/0xb0
[2.624718] [] ? rest_init+0x150/0x150
Signed-off-by: Dave Hansen
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: a...@linux.intel.com
Cc: tim.c.c...@linux.intel.com
Cc: Andrew Morton
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: linux-kernel@vger.kernel.org
Cc: linux...@kvack.org
Cc: kir...@shutemov.name
Cc: lau...@codeaurora.org
---
b/include/linux/kernel.h |1 +
b/kernel/panic.c | 41 +
2 files changed, 42 insertions(+)
diff -puN include/linux/kernel.h~taint-performance include/linux/kernel.h
--- a/include/linux/kernel.h~taint-performance 2014-08-19 11:38:07.424005355
-0700
+++ b/include/linux/kernel.h2014-08-19 11:38:20.960615904 -0700
@@ -471,6 +471,7 @@ extern enum system_states {
#define TAINT_OOT_MODULE 12
#define TAINT_UNSIGNED_MODULE 13
#define TAINT_SOFTLOCKUP 14
+#define TAINT_PERFORMANCE 15
extern const char hex_asc[];
#define hex_asc_lo(x) hex_asc[((x) & 0x0f)]
diff -puN kernel/panic.c~taint-performance kernel/panic.c
--- a/kernel/panic.c~taint-performance 2014-08-19 11:38:28.928975233 -0700
+++ b/kernel/panic.c2014-08-19 20:56:31.598705180 -0700
@@ -225,6 +225,7 @@ static const struct tnt tnts[] = {
{ TAINT_OOT_MODULE, 'O', ' ' },
{ TAINT_UNSIGNED_MODULE,'E', ' ' },
{ TAINT_SOFTLOCKUP, 'L', ' ' },
+ { TAINT_PERFORMANCE,'Q', ' ' },
};
/**
@@ -501,3 +502,43 @@ static int __init oops_setup(char *s)
return 0;
}
early_param("oops", oops_setup);
+
+#ifdef CONFIG_DEBUG_KERNEL
+#define TAINT_PERF_IF(x) do { \
+ if (IS_ENABLED(CONFIG_##x)) { \
+ do_taint = 1; \
+ pr_warn("CONFIG_%s enabled\n", __stringify(x));\
+ } \
+ } while (0)
+
+static int __init performance_taint(void)
+{
+ int do_taint = 0;
+
+ /*
+* This should list any kernel options that can substantially
+* affect performance. This is intended to give a big, fat
+* warning during bootup so that folks have a fighting chance
+* of noticing these things.
+*/
+ TAINT_PERF_IF(LOCKDEP);
+ TAINT_PERF_IF(LOCK_STAT);
+ TAINT_PERF_IF(DEBUG_VM);
+ TAINT_PERF_IF(DEBUG_VM_VMACACHE);
+ TAINT_PERF_IF(DEBUG_VM_RB);
+ TAINT_PERF_IF(DEBUG_SLAB);
+ TAINT_PERF_IF(DEBUG_OBJECTS_FREE);
+ TAINT_PERF_IF(DEBUG_KMEMLEAK);
+ TAINT_PERF_IF(DEBUG_PAGEALLOC);
+ TAINT_PERF_IF(SLUB_DEBUG_ON);
+
+ if (!do_taint)
+ return 0;
+
+
Re: [vfs mnt_set_mountpoint] invalid opcode: 0000 [#1] DEBUG_PAGEALLOC
Fengguang Wu writes: > // Fix email address for Eric and add another oops message. > // This commit seem to generate all kinds of oops. My apologies about the email. This patch has taken so long to get somewhere that email address has bit-rotted. > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > commit 89f7ca1af15bdfe7a6aed343032a84af2a69f736 > Author: Eric W. Biederman > AuthorDate: Sun Sep 22 19:37:01 2013 -0700 > Commit: Al Viro > CommitDate: Sun Aug 17 07:02:00 2014 -0400 > > vfs: Keep a list of mounts on a mount point > > To spot any possible problems call BUG if a mountpoint > is put when it's list of mounts is not empty. > > AV: use hlist instead of list_head Hugh Dickins has a fix for an unitialized field he has sent to Stephen Rothwell. > Reviewed-by: Miklos Szeredi > Signed-off-by: Eric W. Biederman > Signed-off-by: Al Viro I expect Al will sort things out when he get home from kernel summit. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] RCU-walk support for autofs
On Wed, 2014-08-20 at 11:42 +0800, Ian Kent wrote: > > > > From 201f75bc25906e8f64e28b37f1bb478958bf2987 Mon Sep 17 00:00:00 2001 > > From: NeilBrown > > Date: Wed, 20 Aug 2014 12:40:06 +1000 > > Subject: [PATCH] autofs4: make "autofs4_can_expire" idempotent. > > > > Have a "test" function change the value it is testing can > > be confusing, particularly as a future patch will be calling > > this function twice. > > > > So move the update for 'last_used' to avoid repeat expiry > > to the place where the final determination on what to expire is known. > > > > Signed-off-by: NeilBrown > > > > diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c > > index bee939efca2b..af09dada91bc 100644 > > --- a/fs/autofs4/expire.c > > +++ b/fs/autofs4/expire.c > > @@ -30,12 +30,6 @@ static inline int autofs4_can_expire(struct dentry > > *dentry, > > /* Too young to die */ > > if (!timeout || time_after(ino->last_used + timeout, now)) > > return 0; > > - > > - /* update last_used here :- > > - - obviously makes sense if it is in use now > > - - less obviously, prevents rapid-fire expire > > -attempts if expire fails the first time */ > > - ino->last_used = now; > > } > > return 1; > > } > > @@ -541,6 +535,8 @@ int autofs4_expire_run(struct super_block *sb, > > > > spin_lock(>fs_lock); > > ino = autofs4_dentry_ino(dentry); > > + /* avoid rapid-fire expire attempts if expiry fails */ > > + ino->last_used = now; > > ino->flags &= ~AUTOFS_INF_EXPIRING; > > complete_all(>expire_complete); > > spin_unlock(>fs_lock); > > @@ -567,6 +563,8 @@ int autofs4_do_expire_multi(struct super_block *sb, > > struct vfsmount *mnt, > > ret = autofs4_wait(sbi, dentry, NFY_EXPIRE); > > > > spin_lock(>fs_lock); > > + /* avoid rapid-fire expire attempts if expiry fails */ > > + ino->last_used = now; > > ino->flags &= ~AUTOFS_INF_EXPIRING; > > complete_all(>expire_complete); > > spin_unlock(>fs_lock); > On looking a little closer I've set last_used at slightly different locations. It is still does the same thing though. I'm not fussy where we actually do this, so your call. autofs - fix last_used usage From: Ian Kent Signed-off-by: Ian Kent --- fs/autofs4/expire.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c index cca5d1e..d97a761 100644 --- a/fs/autofs4/expire.c +++ b/fs/autofs4/expire.c @@ -30,12 +30,6 @@ static inline int autofs4_can_expire(struct dentry *dentry, /* Too young to die */ if (!timeout || time_after(ino->last_used + timeout, now)) return 0; - - /* update last_used here :- - - obviously makes sense if it is in use now - - less obviously, prevents rapid-fire expire -attempts if expire fails the first time */ - ino->last_used = now; } return 1; } @@ -341,6 +335,8 @@ struct dentry *autofs4_expire_direct(struct super_block *sb, ino->flags |= AUTOFS_INF_EXPIRING; smp_mb(); ino->flags &= ~AUTOFS_INF_NO_RCU; + /* Prevent rapid fire expire events */ + ino->last_used = now; init_completion(>expire_complete); spin_unlock(>fs_lock); return root; @@ -496,6 +492,8 @@ found: ino->flags |= AUTOFS_INF_EXPIRING; smp_mb(); ino->flags &= ~AUTOFS_INF_NO_RCU; + /* Prevent rapid fire expire events */ + ino->last_used = now; init_completion(>expire_complete); spin_unlock(>fs_lock); spin_lock(>lookup_lock); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] spi/rockchip: fixup incorrect dma direction setting
Signed-off-by: Addy Ke --- drivers/spi/spi-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c index cb8fd6f..4ef3fd3 100644 --- a/drivers/spi/spi-rockchip.c +++ b/drivers/spi/spi-rockchip.c @@ -679,7 +679,7 @@ static int rockchip_spi_probe(struct platform_device *pdev) rs->dma_tx.addr = (dma_addr_t)(mem->start + ROCKCHIP_SPI_TXDR); rs->dma_rx.addr = (dma_addr_t)(mem->start + ROCKCHIP_SPI_RXDR); rs->dma_tx.direction = DMA_MEM_TO_DEV; - rs->dma_tx.direction = DMA_DEV_TO_MEM; + rs->dma_rx.direction = DMA_DEV_TO_MEM; master->can_dma = rockchip_spi_can_dma; master->dma_tx = rs->dma_tx.ch; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] RCU-walk support for autofs
On Wed, 2014-08-20 at 13:13 +1000, NeilBrown wrote: > On Tue, 19 Aug 2014 20:36:55 +0800 Ian Kent wrote: > > > On Tue, 2014-08-19 at 21:16 +1000, NeilBrown wrote: > > > On Tue, 19 Aug 2014 18:02:27 +0800 Ian Kent wrote: > > > > > > > On Mon, 2014-08-18 at 16:25 +0800, Ian Kent wrote: > > > > > On Mon, 2014-08-18 at 16:33 +1000, NeilBrown wrote: > > > > > > Hi Ian, > > > > > > Have you had a chance to run your tests in these patches yet? > > > > > > I've done what testing I can think of and cannot fault them. > > > > > > > > > > I haven't, I've been plagued with illness so I'm not getting nearly > > > > > enough done. I'll try to put a kernel together and run the test in the > > > > > next week or so. > > > > > > > > Just to let you know that I managed to spend some time on this. I built > > > > a kernel (3.17.0-rc1) with the series and ran a couple of tests. > > > > > > > > I'm not certain that the patches I used are identical to your posting, I > > > > saw one difference, after the fact, that shouldn't matter, I'll have to > > > > check that. > > > > > > > > It isn't possible to test expire to mount races because the mounts in > > > > the tree never expire. > > > > > > > > At first I thought it was because so many processes were accessing the > > > > tree all the time but manually constructing the maps and mounting the > > > > mounts shows that nothing ever expires, at least for this tree. > > > > > > > > However, issuing a shut down does expire all the mounts and shuts down > > > > autofs cleanly. > > > > > > > > So there is something not quite right with the expire check or my > > > > patches have mistakes. > > > > > > Ahh.. I bet I know what it is. > > > autofs4_can_expire() isn't idempotent. > > > Because we call should_expire twice, autofs4_can_expire() is called twice > > > and > > > the second time it failed because the first time it resets ->last_used. > > > > > > diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c > > > index eb4b770a4bf6..80133a9d9427 100644 > > > --- a/fs/autofs4/expire.c > > > +++ b/fs/autofs4/expire.c > > > @@ -26,6 +26,9 @@ static inline int autofs4_can_expire(struct dentry > > > *dentry, > > > if (ino == NULL) > > > return 0; > > > > > > + if (ino->flags & AUTOFS_INF_NO_RCU) > > > + /* Already performed this test */ > > > + return 1; > > > > Wouldn't it be better to perform this check, or similar, further down > > where the last_used time is updated? After all it's only updated to > > prevent rapid fire expires on dentrys that refuse to umount for some > > reason. > > > > How about the follow approach instead? Great minds think alike. I have basically the exact same patch and I'm testing now. It probably should be folded into "autofs4: avoid taking fs_lock during rcu-walk". It takes ages though, the test has two configurations to test and each one takes about 70 minutes. fyi, my criteria for the test is if it runs through to completion once then that's essentially a pass. If not then there is a race that needs to be fixed before merge. If it fails on runs two or three then there's a hard to find race that needs attention but is not serious enough to block merging. I usually stop after three runs but if fails are seen later then, they too need to be resolved in the fullness of time. The reason for this is that in heavy use sites we rarely see more than about three processes concurrently accessing mount points and the test run uses 10 client instances (currently on a 6 CPU machine) that all access the mount tree at the same time so that should be somewhat more pressure than is seen under heavy use. And indeed this rule of has proven reliable so far. > Though I must admit that I find the 'now' global variable feels a bit > clumsy... > Is there a reason for not just using "jiffies" everywhere? Yeah, changing to use jiffies probably won't make any difference. TBH, I can't remember why I did that. > > I've created a tag 'autofs4' in git://neil.brown.name/md/ which has this in > with all the others, in case that is useful. I think I have all the patches but I may need to refer to that at some point. > > Thanks, > NeilBrown > > > > From 201f75bc25906e8f64e28b37f1bb478958bf2987 Mon Sep 17 00:00:00 2001 > From: NeilBrown > Date: Wed, 20 Aug 2014 12:40:06 +1000 > Subject: [PATCH] autofs4: make "autofs4_can_expire" idempotent. > > Have a "test" function change the value it is testing can > be confusing, particularly as a future patch will be calling > this function twice. > > So move the update for 'last_used' to avoid repeat expiry > to the place where the final determination on what to expire is known. > > Signed-off-by: NeilBrown > > diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c > index bee939efca2b..af09dada91bc 100644 > --- a/fs/autofs4/expire.c > +++ b/fs/autofs4/expire.c > @@ -30,12 +30,6 @@ static inline int autofs4_can_expire(struct dentry *dentry, > /* Too young to die */ >
[PATCH v2 5/5] Clk: RK808: Add clkout driver for RK808
Signed-off-by: Chris Zhong
---
Changes in v2: None
drivers/clk/Kconfig |9 +++
drivers/clk/Makefile|1 +
drivers/clk/clk-rk808.c | 146 +++
3 files changed, 156 insertions(+)
create mode 100644 drivers/clk/clk-rk808.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index cfd3af7..84e0590 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -38,6 +38,15 @@ config COMMON_CLK_MAX77686
---help---
This driver supports Maxim 77686 crystal oscillator clock.
+config COMMON_CLK_RK808
+ tristate "Clock driver for RK808"
+ depends on MFD_RK808
+ ---help---
+ This driver supports RK808 crystal oscillator clock. These
+ multi-function devices have two fixed-rate oscillators,
+ clocked at 32KHz each. Clkout1 is always on, Clkout2 can off
+ by control register.
+
config COMMON_CLK_SI5351
tristate "Clock driver for SiLabs 5351A/B/C"
depends on I2C
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f537a0b..99f53d5 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_ARCH_NOMADIK)+= clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
obj-$(CONFIG_COMMON_CLK_PALMAS)+= clk-palmas.o
obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+obj-$(CONFIG_COMMON_CLK_RK808) += clk-rk808.o
obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
diff --git a/drivers/clk/clk-rk808.c b/drivers/clk/clk-rk808.c
new file mode 100644
index 000..8d0467a
--- /dev/null
+++ b/drivers/clk/clk-rk808.c
@@ -0,0 +1,146 @@
+/*
+ * Clkout driver for Rockchip RK808
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Chris Zhong
+ * Author: Zhang Qing
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct rk808_clk {
+ struct rk808 *rk808;
+ struct clk_onecell_data clk_data;
+ struct clk_hw clkout1_hw;
+ struct clk_hw clkout2_hw;
+};
+
+static unsigned long rk808_clkout_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ return 32768;
+}
+
+static int rk808_clkout1_is_prepared(struct clk_hw *hw)
+{
+ return 1;
+}
+
+static int rk808_clkout2_control(struct clk_hw *hw, bool enable)
+{
+ struct rk808_clk *rk808_clk = container_of(hw, struct rk808_clk,
+ clkout2_hw);
+ struct rk808 *rk808 = rk808_clk->rk808;
+
+ return regmap_update_bits(rk808->regmap, RK808_CLK32OUT_REG,
+ CLK32KOUT2_EN, enable ? CLK32KOUT2_EN : 0);
+}
+
+static int rk808_clkout2_prepare(struct clk_hw *hw)
+{
+ return rk808_clkout2_control(hw, 1);
+}
+
+static void rk808_clkout2_unprepare(struct clk_hw *hw)
+{
+ rk808_clkout2_control(hw, 0);
+}
+
+static int rk808_clkout2_is_prepared(struct clk_hw *hw)
+{
+ struct rk808_clk *rk808_clk = container_of(hw, struct rk808_clk,
+ clkout2_hw);
+ struct rk808 *rk808 = rk808_clk->rk808;
+ uint32_t val;
+
+ int ret = regmap_read(rk808->regmap, RK808_CLK32OUT_REG, );
+
+ if (ret < 0)
+ return ret;
+
+ return (val & CLK32KOUT2_EN) ? 1 : 0;
+}
+
+static const struct clk_ops rk808_clkout1_ops = {
+ .is_prepared = rk808_clkout1_is_prepared,
+ .recalc_rate = rk808_clkout_recalc_rate,
+};
+
+static const struct clk_ops rk808_clkout2_ops = {
+ .prepare = rk808_clkout2_prepare,
+ .unprepare = rk808_clkout2_unprepare,
+ .is_prepared = rk808_clkout2_is_prepared,
+ .recalc_rate = rk808_clkout_recalc_rate,
+};
+
+static int rk808_clk_probe(struct platform_device *pdev)
+{
+ struct rk808 *rk808 = dev_get_drvdata(pdev->dev.parent);
+ struct clk_init_data init;
+ struct clk **clk_table;
+ struct rk808_clk *clkdata;
+ struct device_node *node = client->dev.of_node;
+ int ret;
+
+ clkdata = devm_kzalloc(>dev, sizeof(*clkdata), GFP_KERNEL);
+ if (!clkdata)
+ return -ENOMEM;
+
+ clkdata->rk808 = rk808;
+
+ clk_table = devm_kzalloc(>dev,
+2*sizeof(struct clk *), GFP_KERNEL);
+ if (!clk_table)
+
Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU
On Tue, Aug 19, 2014 at 09:29:44PM +, Haiyang Zhang wrote: > > > -Original Message- > > From: Sitsofe Wheeler [mailto:sits...@gmail.com] > > Sent: Tuesday, August 19, 2014 8:37 AM > > To: KY Srinivasan > > Cc: Greg Kroah-Hartman; Haiyang Zhang; de...@linuxdriverproject.org; > > linux-kernel@vger.kernel.org; Jason Wang; Daniel Borkmann; David S. > > Miller; net...@vger.kernel.org > > Subject: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU > > > > Now we get to the issue I've been meaning to report: changing the MTU of > > a Hyper-V network interface while traffic is flowing through it triggers > > a BUG. I've seen this happen on a variety of kernels but the trace below > > is from 3.17.0-rc1. > > > > Steps to reproduce: > > (Guests were customised Fedora 20 cloud images) > > 1.On Hyper-V VM 1 run > > iperf -s > > 2. On Hyper-V VM 2 run > > iperf -c -t 200 > > 3. On Hyper-V VM 2 run > > ip link set dev eth0 mtu 9000 > > > > Expected results: > > MTU of eth0 to be changed, packets to keep flowing or stop, interface to > > be at alive enough to be reconfigured. > > > > Actual results: > > Error messages on the console, eth0 winds up dead. > > Thanks for the report. > I tried changing mtu while iperf is running, but unable to reproduce it. > I repeated the changing MTU test 10+ times, the link is stable, and passing > traffic at ~8Gbps. > > Could you try a Distro without customization? > I just want to narrow down the possible causes for it. I've just installed ubuntu-14.04-server, installed all the debs to build the kernel, rebuilt the kernel and booted to that kernel. The good news (?) is that I'm not seeing the original stack trace any more (but then again the VM has different number of CPUs, network cards is running different distro etc). The bad news is that I'm now hitting lots of DIFFERENT BUGs using the original steps and eth0 still winds up dead. For example: Aug 20 03:42:56 ubuntuhv kernel: [ 10.469509] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro Aug 20 03:42:56 ubuntuhv kernel: [ 11.223527] hv_storvsc vmbus_0_1: cmd 0x85 scsi status 0x2 srb status 0x6 Aug 20 03:42:56 ubuntuhv kernel: [ 11.223934] hv_storvsc vmbus_0_1: cmd 0x85 scsi status 0x2 srb status 0x6 Aug 20 03:42:58 ubuntuhv kernel: [ 13.025064] psmouse serio1: trackpoint: IBM TrackPoint firmware: 0x01, buttons: 0/0 Aug 20 03:42:58 ubuntuhv kernel: [ 13.028182] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/input/input4 Aug 20 03:41:09 ubuntuhv kernel: [ 179.973064] hv_netvsc vmbus_0_14: net device safe to remove Aug 20 03:41:09 ubuntuhv kernel: [ 179.974995] hv_netvsc: hv_netvsc channel opened successfully Aug 20 03:41:10 ubuntuhv kernel: [ 180.402957] hv_netvsc vmbus_0_14 eth0: unable to establish send buffer's gpadl Aug 20 03:41:10 ubuntuhv kernel: [ 180.403080] [ cut here ] Aug 20 03:41:10 ubuntuhv kernel: [ 180.403141] kernel BUG at drivers/hv/channel.c:460! Aug 20 03:41:10 ubuntuhv kernel: [ 180.403253] invalid opcode: [#1] SMP Aug 20 03:41:10 ubuntuhv kernel: [ 180.403328] CPU: 1 PID: 1482 Comm: ifconfig Not tainted 3.17.0-rc1.x86_64 #1 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403431] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 05/23/2012 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] task: 88006e45b9f0 ti: 880070b2 task.ti: 880070b2 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RIP: 0010:[] [] vmbus_teardown_gpadl+0xc1/0x130 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RSP: 0018:880070b23c00 EFLAGS: 00010202 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RAX: 0004 RBX: 88006fef0e38 RCX: 0006 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RDX: 0006 RSI: 88006e45c130 RDI: 0246 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] RBP: 880070b23c20 R08: R09: Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] R10: 0001 R11: 0001 R12: 0296 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] R13: 88007b911520 R14: 88006fef0e58 R15: 0004 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] FS: 7fe5cd41d740() GS:88007fc2() knlGS: Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] CS: 0010 DS: ES: CR0: 80050033 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] CR2: 7f4e3766d410 CR3: 74bcb000 CR4: 000406e0 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] Stack: Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] 88007455 880078154520 88007455 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] 880070b23c48 814e8276 88007b916458 880078154520 Aug 20 03:41:10 ubuntuhv kernel: [ 180.403536] 88007455 880070b23cb8 814e957f 88007b911520 Aug 20 03:41:10 ubuntuhv kernel: [
[PATCH v2 4/5] Regulator: RK808: Add regulator driver for RK808
The regulator module consists of 4 DCDCs, 8 LDOs and 2 switches.
The output voltages are configurable and are meant to supply power
to the main processor and other components
Signed-off-by: Chris Zhong
---
Changes in v2:
Adviced by Mark Browm:
- use defines for register setting value
- remove rtc alarm disable in shutdown
- remove while(1) in shutdown
- remove read 0x2f in probe
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile |1 +
drivers/regulator/rk808-regulator.c | 410 +++
3 files changed, 421 insertions(+)
create mode 100644 drivers/regulator/rk808-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 2dc8289..fb32bab 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -459,6 +459,16 @@ config REGULATOR_RC5T583
through regulator interface. The device supports multiple DCDC/LDO
outputs which can be controlled by i2c communication.
+config REGULATOR_RK808
+ tristate "Rockchip RK808 Power regulators"
+ depends on MFD_RK808
+ help
+ Select this option to enable the power regulator of ROCKCHIP
+ PMIC RK808.
+ This driver supports the control of different power rails of device
+ through regulator interface. The device supports multiple DCDC/LDO
+ outputs which can be controlled by i2c communication.
+
config REGULATOR_S2MPA01
tristate "Samsung S2MPA01 voltage regulator"
depends on MFD_SEC_CORE
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index aa4a6aa..236fdbb 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_REGULATOR_PBIAS) += pbias-regulator.o
obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
obj-$(CONFIG_REGULATOR_RC5T583) += rc5t583-regulator.o
+obj-$(CONFIG_REGULATOR_RK808) += rk808-regulator.o
obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o
obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
diff --git a/drivers/regulator/rk808-regulator.c
b/drivers/regulator/rk808-regulator.c
new file mode 100644
index 000..94753fd
--- /dev/null
+++ b/drivers/regulator/rk808-regulator.c
@@ -0,0 +1,410 @@
+/*
+ * Regulator driver for Rockchip RK808
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Chris Zhong
+ * Author: Zhang Qing
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+/*
+ * Field Definitions.
+ */
+#define RK808_BUCK_VSEL_MASK 0x3f
+#define RK808_BUCK4_VSEL_MASK 0xf
+#define RK808_LDO_VSEL_MASK0x1f
+
+static const int buck_set_vol_base_addr[] = {
+ RK808_BUCK1_ON_VSEL_REG,
+ RK808_BUCK2_ON_VSEL_REG,
+ RK808_BUCK3_CONFIG_REG,
+ RK808_BUCK4_ON_VSEL_REG,
+};
+
+static const int buck_contr_base_addr[] = {
+ RK808_BUCK1_CONFIG_REG,
+ RK808_BUCK2_CONFIG_REG,
+ RK808_BUCK3_CONFIG_REG,
+ RK808_BUCK4_CONFIG_REG,
+};
+
+#define rk808_BUCK_SET_VOL_REG(x) (buck_set_vol_base_addr[x])
+#define rk808_BUCK_CONTR_REG(x) (buck_contr_base_addr[x])
+#define rk808_LDO_SET_VOL_REG(x) (ldo_set_vol_base_addr[x])
+
+static const int ldo_set_vol_base_addr[] = {
+ RK808_LDO1_ON_VSEL_REG,
+ RK808_LDO2_ON_VSEL_REG,
+ RK808_LDO3_ON_VSEL_REG,
+ RK808_LDO4_ON_VSEL_REG,
+ RK808_LDO5_ON_VSEL_REG,
+ RK808_LDO6_ON_VSEL_REG,
+ RK808_LDO7_ON_VSEL_REG,
+ RK808_LDO8_ON_VSEL_REG,
+};
+
+/*
+ * rk808 voltage number
+ */
+static const struct regulator_linear_range rk808_buck_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(70, 0, 63, 12500),
+};
+
+static const struct regulator_linear_range rk808_buck4_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(180, 0, 15, 10),
+};
+
+static const struct regulator_linear_range rk808_ldo_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(180, 0, 16, 10),
+};
+
+static const struct regulator_linear_range rk808_ldo3_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(80, 0, 13, 10),
+ REGULATOR_LINEAR_RANGE(250, 15, 15, 0),
+};
+
+static const struct regulator_linear_range rk808_ldo6_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(80, 0, 17, 10),
+};
+
+static struct regulator_ops rk808_reg_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+
[PATCH v2 3/5] RTC: RK808: add RTC driver for RK808
RK808 PMIC is a MFD with RTC as one of the device. Adding RTC driver
for supporting RTC device present inside RK808 PMIC.
Signed-off-by: Chris Zhong
---
Changes in v2:
Adviced by javier.martinez
- Add a separate clock driver, rather than in RTC driver
drivers/rtc/Kconfig | 11 ++
drivers/rtc/Makefile|1 +
drivers/rtc/rtc-rk808.c | 462 +++
3 files changed, 474 insertions(+)
create mode 100644 drivers/rtc/rtc-rk808.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a168e96..48f61b2 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -288,6 +288,17 @@ config RTC_DRV_MAX77686
This driver can also be built as a module. If so, the module
will be called rtc-max77686.
+config RTC_DRV_RK808
+ tristate "Rockchip RK808 RTC"
+ depends on MFD_RK808
+ help
+ If you say yes here you will get support for the
+ RTC of Rk808 PMIC.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-rk808.
+
+
config RTC_DRV_RS5C372
tristate "Ricoh R2025S/D, RS5C372A/B, RV5C386, RV5C387A"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 56f061c..91fe4647 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_RTC_DRV_PUV3) += rtc-puv3.o
obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
obj-$(CONFIG_RTC_DRV_RC5T583) += rtc-rc5t583.o
+obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
obj-$(CONFIG_RTC_DRV_RS5C348) += rtc-rs5c348.o
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
new file mode 100644
index 000..f5a2ec3
--- /dev/null
+++ b/drivers/rtc/rtc-rk808.c
@@ -0,0 +1,462 @@
+/*
+ * RTC driver for Rockchip RK808
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Chris Zhong
+ * Author: Zhang Qing
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* RTC_CTRL_REG bitfields */
+#define BIT_RTC_CTRL_REG_STOP_RTC_M0x01
+#define BIT_RTC_CTRL_REG_ROUND_30S_M 0x02
+#define BIT_RTC_CTRL_REG_AUTO_COMP_M 0x04
+#define BIT_RTC_CTRL_REG_MODE_12_24_M 0x08
+#define BIT_RTC_CTRL_REG_TEST_MODE_M 0x10
+#define BIT_RTC_CTRL_REG_SET_32_COUNTER_M 0x20
+#define BIT_RTC_CTRL_REG_GET_TIME_M0x40
+#define BIT_RTC_CTRL_REG_RTC_V_OPT_M 0x80
+
+/* RTC_STATUS_REG bitfields */
+#define BIT_RTC_STATUS_REG_RUN_M 0x02
+#define BIT_RTC_STATUS_REG_1S_EVENT_M 0x04
+#define BIT_RTC_STATUS_REG_1M_EVENT_M 0x08
+#define BIT_RTC_STATUS_REG_1H_EVENT_M 0x10
+#define BIT_RTC_STATUS_REG_1D_EVENT_M 0x20
+#define BIT_RTC_STATUS_REG_ALARM_M 0x40
+#define BIT_RTC_STATUS_REG_POWER_UP_M 0x80
+
+/* RTC_INTERRUPTS_REG bitfields */
+#define BIT_RTC_INTERRUPTS_REG_EVERY_M 0x03
+#define BIT_RTC_INTERRUPTS_REG_IT_TIMER_M 0x04
+#define BIT_RTC_INTERRUPTS_REG_IT_ALARM_M 0x08
+
+/* DEVCTRL bitfields */
+#define BIT_RTC_PWDN 0x40
+
+/* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
+#define ALL_TIME_REGS 7
+#define ALL_ALM_REGS 6
+
+#define RTC_SET_TIME_RETRIES 5
+#define RTC_GET_TIME_RETRIES 5
+
+struct rk808_rtc {
+ struct rk808 *rk808;
+ struct rtc_device *rtc;
+ unsigned int alarm_enabled:1;
+};
+
+/*
+ * Read current time and date in RTC
+ */
+static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
+{
+ struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
+ struct rk808 *rk808 = rk808_rtc->rk808;
+ int ret;
+ u8 rtc_data[ALL_TIME_REGS + 1];
+
+ /* Has the RTC been programmed? */
+ ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
+BIT_RTC_CTRL_REG_RTC_V_OPT_M, 0);
+ if (ret < 0) {
+ dev_err(dev, "Failed to update RTC control: %d\n", ret);
+ return ret;
+ }
+
+ ret = regmap_bulk_read(rk808->regmap, RK808_SECONDS_REG, rtc_data, 6);
+ if (ret < 0) {
+ dev_err(dev, "Failed to bulk read rtc_data: %d\n", ret);
+
[PATCH v2 2/5] MFD: RK808: Add new mfd driver for RK808
The RK808 chip is a power management IC for multimedia and handheld
devices. It contains the following components:
- Regulators
- RTC
The rk808 core driver is registered as a platform driver and provides
communication through I2C with the host device for the different
components.
Signed-off-by: Chris Zhong
---
Changes in v2:
Adviced by Mark Browm:
- change of_find_node_by_name to find_child_by_name
- use RK808_NUM_REGULATORS as the name of the constant
- create a pdata when missing platform data
- use the rk808_reg name to supply_regulator name
- replace regulator_register with devm_regulator_register
- some other problem with coding style
drivers/mfd/Kconfig | 13 ++
drivers/mfd/Makefile |1 +
drivers/mfd/rk808.c | 297 +
include/linux/mfd/rk808.h | 219 +
4 files changed, 530 insertions(+)
create mode 100644 drivers/mfd/rk808.c
create mode 100644 include/linux/mfd/rk808.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index de5abf2..1df133e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -582,6 +582,19 @@ config MFD_RC5T583
Additional drivers must be enabled in order to use the
different functionality of the device.
+config MFD_RK808
+ tristate "Rockchip RK808 Power Management chip"
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ select REGMAP_IRQ
+ help
+ Select this option to get support for the RK808 Power
+ Management system device.
+ This driver provides common support for accessing the device
+ through i2c interface. The device supports multiple sub-devices
+ like interrupts, RTC, LDO and DCDC regulators, onkey.
+
config MFD_SEC_CORE
bool "SAMSUNG Electronics PMIC Series Support"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f001487..dbc28e7 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -160,6 +160,7 @@ obj-$(CONFIG_MFD_INTEL_MSIC)+= intel_msic.o
obj-$(CONFIG_MFD_PALMAS) += palmas.o
obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
+obj-$(CONFIG_MFD_RK808)+= rk808.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
new file mode 100644
index 000..667cfdf
--- /dev/null
+++ b/drivers/mfd/rk808.c
@@ -0,0 +1,297 @@
+/*
+ * Mfd core driver for Rockchip RK808
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Chris Zhong
+ * Author: Zhang Qing
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct rk808_reg_data {
+ int addr;
+ int mask;
+ int value;
+};
+
+static struct rk808 *g_rk808;
+
+static struct resource rtc_resources[] = {
+ {
+ .start = RK808_IRQ_RTC_ALARM,
+ .end= RK808_IRQ_RTC_ALARM,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static const struct mfd_cell rk808s[] = {
+ {
+ .name = "rk808-regulator",
+ },
+ {
+ .name = "rk808-rtc",
+ .num_resources = ARRAY_SIZE(rtc_resources),
+ .resources = _resources[0],
+ },
+ {
+ .name = "rk808-clkout",
+ },
+};
+
+static const struct rk808_reg_data pre_init_reg[] = {
+ {RK808_BUCK3_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_150MA},
+ {RK808_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_200MA},
+ {RK808_BOOST_CONFIG_REG, BOOST_ILMIN_MASK, BOOST_ILMIN_100MA},
+ {RK808_BUCK1_CONFIG_REG, BUCK1_RATE_MASK, BUCK_ILMIN_200MA},
+ {RK808_BUCK2_CONFIG_REG, BUCK2_RATE_MASK, BUCK_ILMIN_200MA},
+ {RK808_VB_MON_REG, MASK_ALL, VB_LO_ACT | VB_LO_SEL_3500MV},
+ {RK808_INT_STS_REG1, MASK_NONE, 0},
+ {RK808_INT_STS_REG2, MASK_NONE, 0},
+};
+
+static const struct regmap_irq rk808_irqs[] = {
+ /* INT_STS */
+ [RK808_IRQ_VOUT_LO] = {
+ .mask = RK808_IRQ_VOUT_LO_MSK,
+ .reg_offset = 0,
+ },
+ [RK808_IRQ_VB_LO] = {
+ .mask = RK808_IRQ_VB_LO_MSK,
+
Re: [PATCH] [RFC] TAINT_PERFORMANCE
On Wed, 2014-08-20 at 01:26 +0300, Kirill A. Shutemov wrote: > On Tue, Aug 19, 2014 at 02:26:04PM -0700, Dave Hansen wrote: > > + TAINT_PERF_IF(SCHEDSTATS); > > Is SCHEDSTATS really harmful? If your config is minimalist, a tad. If your config is.. Rubenesque (distro), you probably won't notice the extra beauty. > It's enabled in some distro kernels. > At least in Arch: > > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/config.x86_64?h=packages/linux Ditto for SUSE. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/5] MFD: Add rk808 device tree bindings documentation
rk808.txt: Add device tree bindings for rockchip's rk808 pmic.
Signed-off-by: Chris Zhong
---
Changes in v2:
Adviced by javier.martinez
- separated from rtc-rk808.c
Documentation/devicetree/bindings/mfd/rk808.txt | 128 +++
1 file changed, 128 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rk808.txt
diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt
b/Documentation/devicetree/bindings/mfd/rk808.txt
new file mode 100644
index 000..876291d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rk808.txt
@@ -0,0 +1,128 @@
+RK808 Power Management Integrated Circuit
+
+Required properties:
+- compatible: "rockchip,rk808"
+- reg: I2C slave address
+- interrupt-parent: The parent interrupt controller.
+- interrupts: the interrupt outputs of the controller.
+- pinctrl-names: Should contain only one value - "default".
+- pinctrl-0: Should specify pin control groups used for this controller.
+- regulators: This is the list of child nodes that specify the regulator
+ initialization data for defined regulators. Not all regulators for the given
+ device need to be present. The definition for each of these nodes is defined
+ using the standard binding for regulators found at
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Optional properties:
+- rockchip,system-power-controller: Telling whether or not this pmic is
controlling
+ the system power.
+
+Example:
+rk808: pmic@1b {
+ compatible = "rockchip,rk808";
+ interrupt-parent = <>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_int>;
+ reg = <0x1b>;
+ rockchip,system-power-controller;
+
+ regulators {
+ rk808_dcdc1_reg: DCDC_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-name = "vdd_arm";
+ };
+
+ rk808_dcdc2_reg: DCDC_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <85>;
+ regulator-max-microvolt = <125>;
+ regulator-name = "vdd_gpu";
+ };
+
+ rk808_dcdc3_reg: DCDC_REG3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vdd_ddr";
+ };
+
+ rk808_dcdc4_reg: DCDC_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vccio";
+ };
+
+ rk808_ldo1_reg: LDO_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ rk808_ldo2_reg: LDO_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ rk808_ldo3_reg: LDO_REG3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ regulator-name = "LDO_REG3";
+ };
+
+ rk808_ldo4_reg: LDO_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ rk808_ldo5_reg: LDO_REG5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ };
+
+ rk808_ldo6_reg: LDO_REG6 {
+ regulator-always-on;
+ regulator-boot-on;
+
Re: [PATCH v2 08/18] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way
On 2014-8-20 3:25, Geoff Levand wrote:
> Hi Hanjun,
>
> On Tue, 2014-08-19 at 20:11 +0800, Hanjun Guo wrote:
>> On 2014-8-19 2:56, Geoff Levand wrote:
>
>>> message = acpi_disabled ? dn->full_name : "";
>>>
>>> ...
>>>
>>> pr_warn("CPU %d: %s unsupported enable-method property: %s\n",
>>> cpu, message, enable_method)
>>
>> In ACPI, there is no enable-method property, it is a term from, so I think
>> the
>> message printed can be separated.
>
> I think it better to have a single message that can cover all
> than to have separate messages. Wouldn't the enable method be
> "acpi-parking" or "acpi-psci"? Then something like this would
> work:
>
> pr_warn("CPU %d: %s Unsupported enable method: %s\n", cpu, message,
> enable_method);
Thanks for the suggestion, I will update it in next version.
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] Add rockchip RK808 pmic driver
This is the initial version of the RK808 PMIC. This is a power management IC for multimedia products. It provides regulators that are able to supply power to processor cores and other components. The chip provides other modules including RTC, Clockout Changes in v2: Adviced by javier.martinez - separated from rtc-rk808.c Adviced by Mark Browm: - change of_find_node_by_name to find_child_by_name - use RK808_NUM_REGULATORS as the name of the constant - create a pdata when missing platform data - use the rk808_reg name to supply_regulator name - replace regulator_register with devm_regulator_register - some other problem with coding style Adviced by javier.martinez - Add a separate clock driver, rather than in RTC driver Adviced by Mark Browm: - use defines for register setting value - remove rtc alarm disable in shutdown - remove while(1) in shutdown - remove read 0x2f in probe Chris Zhong (5): MFD: Add rk808 device tree bindings documentation MFD: RK808: Add new mfd driver for RK808 RTC: RK808: add RTC driver for RK808 Regulator: RK808: Add regulator driver for RK808 Clk: RK808: Add clkout driver for RK808 Documentation/devicetree/bindings/mfd/rk808.txt | 128 +++ drivers/clk/Kconfig |9 + drivers/clk/Makefile|1 + drivers/clk/clk-rk808.c | 146 +++ drivers/mfd/Kconfig | 13 + drivers/mfd/Makefile|1 + drivers/mfd/rk808.c | 297 +++ drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile |1 + drivers/regulator/rk808-regulator.c | 410 drivers/rtc/Kconfig | 11 + drivers/rtc/Makefile|1 + drivers/rtc/rtc-rk808.c | 462 +++ include/linux/mfd/rk808.h | 219 +++ 14 files changed, 1709 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/rk808.txt create mode 100644 drivers/clk/clk-rk808.c create mode 100644 drivers/mfd/rk808.c create mode 100644 drivers/regulator/rk808-regulator.c create mode 100644 drivers/rtc/rtc-rk808.c create mode 100644 include/linux/mfd/rk808.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linaro-acpi] [PATCH v2 06/18] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map
On 2014-8-20 0:46, Zi Shen Lim wrote: > Hanjun, Hi Lim, > > On Tue, Aug 19, 2014 at 6:00 AM, Hanjun Guo wrote: >> Will INTERRUPT_CONTROLLER confuse people? There is only one GIC redistributor >> (some people regard it as interrupt controller) in ARM system, if we use >> INTERRUPT_CONTROLLER people will regard it as multi-redistributors in the >> system, I think GIC_CPU_INTERFACE would be better, what do you think? > > I think you meant to say "one GIC _distributor_" (GICD) instead of > redistributor (GICR). > ACPI5.1 only describes one GICD per system, but we can most certainly > describe multiple GICRs. > For multi-cpu systems, you'll definitely see multiple GIC redistributors. Yes, you are right, thanks for pointing it out, I think I need more coffee :) Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc: Export dcr_ind_lock to fix build error
Fix build error caused by missing export: ERROR: "dcr_ind_lock" [drivers/net/ethernet/ibm/emac/ibm_emac.ko] undefined! Signed-off-by: Pranith Kumar --- arch/powerpc/sysdev/dcr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c index e9056e4..2d8a101 100644 --- a/arch/powerpc/sysdev/dcr.c +++ b/arch/powerpc/sysdev/dcr.c @@ -230,5 +230,6 @@ EXPORT_SYMBOL_GPL(dcr_unmap_mmio); #ifdef CONFIG_PPC_DCR_NATIVE DEFINE_SPINLOCK(dcr_ind_lock); +EXPORT_SYMBOL_GPL(dcr_ind_lock); #endif /* defined(CONFIG_PPC_DCR_NATIVE) */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] usbip: move usbip kernel code out of staging
On Tue, Aug 19, 2014 at 11:38 AM, Greg KH wrote: > > This patch moves the code, but now it's "gone" from the build system as > it is not hooked up and can not be built at all. > > So while I really wanted to apply this series right now, I can't, as > this is a regression (working driver -> no driver). You mean it should be in Kbuild and Makefile from drivers/, right? Will resend the series again, with MAINTAINERS modified. Thanks, Valentina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: pch_udc: USB gadget device support for Intel Quark X1000
Hi, On Wed, Aug 20, 2014 at 12:46:33AM +, Chen, Alvin wrote: > > > Hi, > > > > On Mon, Aug 04, 2014 at 10:22:54AM -0700, Chen, Alvin wrote: > > > From: Bryan O'Donoghue > > > > > > This patch is to enable the USB gadget device for Intel Quark X1000 > > > > > > Signed-off-by: Bryan O'Donoghue > > > Signed-off-by: Bing Niu > > > Signed-off-by: Alvin (Weike) Chen > > > > Can someone confirm to me this is not another incarnation of chipidea ? > > No, this is not another incarnation of chipidea. And its cover letter is as > following: > > On Mon, Aug 04, 2014 at 11:00:07AM -0700, Chen, Alvin wrote: > > From: "Alvin (Weike) Chen" > > > > Hi, > > Intel Quark X1000 consists of one USB gadget device which can be PCI > > enumerated. > > pch_udc layer doesn't support it. Thus, we add support for Intel Quark > > X1000 USB gadget device as well. hehe, right I *know* what the patch is doing. I can read the diff and figure out that you're adding support for Quark to PCH UDC because Quark's USB IP is the same, what I wasking was if that IP was actually an instance of the chipidea UDC. After looking at the address space definitions on both drivers, I see that it's not. So tomorrow I'll look at this patch again. -- balbi signature.asc Description: Digital signature
[PATCH v3] KVM: vmx: fix ept reserved bits for 1-GByte page
EPT misconfig handler in kvm will check which reason lead to EPT
misconfiguration after vmexit. One of the reasons is that an EPT
paging-structure entry is configured with settings reserved for
future functionality. However, the handler can't identify if
paging-structure entry of reserved bits for 1-GByte page are
configured, since PDPTE which point to 1-GByte page will reserve
bits 29:12 instead of bits 7:3 which are reserved for PDPTE that
references an EPT Page Directory. This patch fix it by reserve
bits 29:12 for 1-GByte page.
Signed-off-by: Wanpeng Li
---
v2 -> v3:
* return 0xf8 for level == 4
* check spte & (1ULL << 7) if level == 1
* (rsvd_mask & 0x38) == 0 for large page or leaf page
v1 -> v2:
* same "if" statement cover both 2MB and 1GB pages
* return 0xf8 for level == 4
* get the level by checking the return value of ept_rsvd_mask
arch/x86/kvm/vmx.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index cad37d5..3218359 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5521,17 +5521,18 @@ static u64 ept_rsvd_mask(u64 spte, int level)
for (i = 51; i > boot_cpu_data.x86_phys_bits; i--)
mask |= (1ULL << i);
- if (level > 2)
+ if (level == 4)
/* bits 7:3 reserved */
mask |= 0xf8;
- else if (level == 2) {
- if (spte & (1ULL << 7))
- /* 2MB ref, bits 20:12 reserved */
- mask |= 0x1ff000;
- else
- /* bits 6:3 reserved */
- mask |= 0x78;
- }
+ else if (spte & (1ULL << 7))
+ /*
+* 1GB/2MB page, bits 29:12 or 20:12 reserved respectively,
+* level == 1 if the hypervisor is using the ignored bit 7.
+*/
+ mask |= (PAGE_SIZE << ((level - 1) * 9)) - PAGE_SIZE;
+ else
+ /* bits 6:3 reserved */
+ mask |= 0x78;
return mask;
}
@@ -5561,7 +5562,8 @@ static void ept_misconfig_inspect_spte(struct kvm_vcpu
*vcpu, u64 spte,
WARN_ON(1);
}
- if (level == 1 || (level == 2 && (spte & (1ULL << 7 {
+ /* bits 5:3 are _not_ reserved for large page or leaf page */
+ if ((rsvd_bits & 0x38) == 0) {
u64 ept_mem_type = (spte & 0x38) >> 3;
if (ept_mem_type == 2 || ept_mem_type == 3 ||
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] RCU-walk support for autofs
On Tue, 19 Aug 2014 20:36:55 +0800 Ian Kent wrote: > On Tue, 2014-08-19 at 21:16 +1000, NeilBrown wrote: > > On Tue, 19 Aug 2014 18:02:27 +0800 Ian Kent wrote: > > > > > On Mon, 2014-08-18 at 16:25 +0800, Ian Kent wrote: > > > > On Mon, 2014-08-18 at 16:33 +1000, NeilBrown wrote: > > > > > Hi Ian, > > > > > Have you had a chance to run your tests in these patches yet? > > > > > I've done what testing I can think of and cannot fault them. > > > > > > > > I haven't, I've been plagued with illness so I'm not getting nearly > > > > enough done. I'll try to put a kernel together and run the test in the > > > > next week or so. > > > > > > Just to let you know that I managed to spend some time on this. I built > > > a kernel (3.17.0-rc1) with the series and ran a couple of tests. > > > > > > I'm not certain that the patches I used are identical to your posting, I > > > saw one difference, after the fact, that shouldn't matter, I'll have to > > > check that. > > > > > > It isn't possible to test expire to mount races because the mounts in > > > the tree never expire. > > > > > > At first I thought it was because so many processes were accessing the > > > tree all the time but manually constructing the maps and mounting the > > > mounts shows that nothing ever expires, at least for this tree. > > > > > > However, issuing a shut down does expire all the mounts and shuts down > > > autofs cleanly. > > > > > > So there is something not quite right with the expire check or my > > > patches have mistakes. > > > > Ahh.. I bet I know what it is. > > autofs4_can_expire() isn't idempotent. > > Because we call should_expire twice, autofs4_can_expire() is called twice > > and > > the second time it failed because the first time it resets ->last_used. > > > > diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c > > index eb4b770a4bf6..80133a9d9427 100644 > > --- a/fs/autofs4/expire.c > > +++ b/fs/autofs4/expire.c > > @@ -26,6 +26,9 @@ static inline int autofs4_can_expire(struct dentry > > *dentry, > > if (ino == NULL) > > return 0; > > > > + if (ino->flags & AUTOFS_INF_NO_RCU) > > + /* Already performed this test */ > > + return 1; > > Wouldn't it be better to perform this check, or similar, further down > where the last_used time is updated? After all it's only updated to > prevent rapid fire expires on dentrys that refuse to umount for some > reason. > How about the follow approach instead? Though I must admit that I find the 'now' global variable feels a bit clumsy... Is there a reason for not just using "jiffies" everywhere? I've created a tag 'autofs4' in git://neil.brown.name/md/ which has this in with all the others, in case that is useful. Thanks, NeilBrown From 201f75bc25906e8f64e28b37f1bb478958bf2987 Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Wed, 20 Aug 2014 12:40:06 +1000 Subject: [PATCH] autofs4: make "autofs4_can_expire" idempotent. Have a "test" function change the value it is testing can be confusing, particularly as a future patch will be calling this function twice. So move the update for 'last_used' to avoid repeat expiry to the place where the final determination on what to expire is known. Signed-off-by: NeilBrown diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c index bee939efca2b..af09dada91bc 100644 --- a/fs/autofs4/expire.c +++ b/fs/autofs4/expire.c @@ -30,12 +30,6 @@ static inline int autofs4_can_expire(struct dentry *dentry, /* Too young to die */ if (!timeout || time_after(ino->last_used + timeout, now)) return 0; - - /* update last_used here :- - - obviously makes sense if it is in use now - - less obviously, prevents rapid-fire expire -attempts if expire fails the first time */ - ino->last_used = now; } return 1; } @@ -541,6 +535,8 @@ int autofs4_expire_run(struct super_block *sb, spin_lock(>fs_lock); ino = autofs4_dentry_ino(dentry); + /* avoid rapid-fire expire attempts if expiry fails */ + ino->last_used = now; ino->flags &= ~AUTOFS_INF_EXPIRING; complete_all(>expire_complete); spin_unlock(>fs_lock); @@ -567,6 +563,8 @@ int autofs4_do_expire_multi(struct super_block *sb, struct vfsmount *mnt, ret = autofs4_wait(sbi, dentry, NFY_EXPIRE); spin_lock(>fs_lock); + /* avoid rapid-fire expire attempts if expiry fails */ + ino->last_used = now; ino->flags &= ~AUTOFS_INF_EXPIRING; complete_all(>expire_complete); spin_unlock(>fs_lock); signature.asc Description: PGP signature
Re: WARNING: CPU: 6 PID: 79 at fs/proc/generic.c:521 remove_proc_entry+0x170/0x180()
On Tue, Aug 19, 2014 at 7:50 PM, Jiang Liu wrote: > Hi Kujau, > It seems like a different issue, something wrong with > void nfs_fs_proc_net_exit(struct net *net) http://marc.info/?l=linux-nfs=140821782107427=2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] booke_wdt: Fix build failure as a module
Building booke_wdt fails when trying to build as a module as there is no
early_param() in module. Fix by enclosing within MODULE check.
Also remove notrace attribute as it is implicit in the __init attribute.
Signed-off-by: Pranith Kumar
---
drivers/watchdog/booke_wdt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 08a7853..8a26b54 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -41,8 +41,9 @@ u32 booke_wdt_period = CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT;
#define WDTP_MASK (TCR_WP_MASK)
#endif
+#ifndef MODULE
/* Checks wdt=x and wdt_period=xx command-line option */
-notrace int __init early_parse_wdt(char *p)
+int __init early_parse_wdt(char *p)
{
if (p && strncmp(p, "0", 1) != 0)
booke_wdt_enabled = 1;
@@ -63,6 +64,8 @@ int __init early_parse_wdt_period(char *p)
}
early_param("wdt_period", early_parse_wdt_period);
+#endif /* #ifndef MODULE */
+
#ifdef CONFIG_PPC_FSL_BOOK3E
/* For the specified period, determine the number of seconds
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.16 boot hangs at initramfs scripts when mounting filesystems
Alex's commit fixes the Linux 3.16 boot hang on BMIPS5000 that I reported. Please include this fix to 3.16.x and 3.14.x stable trains. commit e90e6fddc57055c4c6b57f92787fea1c065d440b Author: Alex Smith Date: Wed Jul 23 14:40:11 2014 +0100 MIPS: O32/32-bit: Fix bug which can cause incorrect system call restarts On Wed, Aug 13, 2014 at 7:12 PM, Petri Gynther wrote: > Hi linux-kernel and linux-mips: > > I'm trying to boot Linux 3.16 on Broadcom BMIPS5000-based platform. > However, 90% of the time, the system hangs at initramfs scripts at one > of the mount commands. I'm also seeing this same issue when booting > Linux 3.15. > > Please see the boot log below. At 2.583000, MMC partitions seem to be > detected correctly. At 2.809000 initramfs scripts start to run. The > scripts attempt to run the following commands: > > strace mount -t devtmpfs none /dev > strace mount -t proc none /proc > strace mount -t sysfs none /sys > strace mkdir /dev/pts /dev/shm > strace mount -t devpts none /dev/pts > strace mount -t tmpfs none /dev/shm > strace mount -t debugfs none /sys/kernel/debug > strace mount -o ro -t squashfs /dev/mmcblk0p19 /rootfs > > [0.00] Linux version 3.16.0 ... (gcc version 4.5.3 (Broadcom > stbgcc-4.5.3-1.3) ) #4 SMP Wed Aug 13 18:13:44 PDT 2014 > [0.00] Fetching vars from bootloader... found 10 vars. > [0.00] Options: moca=1 sata=0 pcie=0 usb=1 > [0.00] Using 1024 MB + 0 MB RAM (from CFE) > [0.00] bootconsole [early0] enabled > [0.00] CPU0 revision is: 00025a11 (Broadcom BMIPS5000) > [0.00] FPU revision is: 00130001 > [0.00] Determined physical RAM map: > [0.00] memory: 1000 @ (usable) > [0.00] memory: 3000 @ 2000 (usable) > [0.00] bmem: adding 109 MB LINUX region at 18 MB > (0x06d0a000@0x012f6000) > [0.00] bmem: adding 128 MB RESERVED region at 128 MB > (0x0800@0x0800) > [0.00] bmem: adding 320 MB RESERVED region at 512 MB > (0x1400@0x2000) > [0.00] bmem: adding 448 MB LINUX region at 832 MB > (0x1c00@0x3400) > [0.00] Initrd not found or empty - disabling initrd > [0.00] Zone ranges: > [0.00] Normal [mem 0x-0x4fff] > [0.00] HighMem empty > [0.00] Movable zone start for each node > [0.00] Early memory node ranges > [0.00] node 0: [mem 0x-0x0fff] > [0.00] node 0: [mem 0x2000-0x4fff] > [0.00] On node 0 totalpages: 262144 > [0.00] Normal zone: 2048 pages used for memmap > [0.00] Normal zone: 0 pages reserved > [0.00] Normal zone: 262144 pages, LIFO batch:31 > [0.00] Primary instruction cache 32kB, physically tagged, > 4-way, linesize 64 bytes. > [0.00] Primary data cache 32kB, 4-way, linesize 32 bytes. > [0.00] MIPS secondary cache 256kB, 8-way, linesize 128 bytes. > [0.00] PERCPU: Embedded 9 pages/cpu @81b1a000 s12416 r8192 d16256 > u36864 > [0.00] pcpu-alloc: s12416 r8192 d16256 u36864 alloc=9*4096 > [0.00] pcpu-alloc: [0] 0 [0] 1 > [0.00] Built 1 zonelists in Zone order, mobility grouping on. > Total pages: 260096 > [0.00] Kernel command line: splashmem=0x0/4m@memc1 > cfe_ver=3.53.24 display=on rootfstype=squashfs partitionver=2 > root=rootfs1 debug bmem=128m@128m bmem=320m@512m log_buf_len=8388608 > [0.00] Switched partition from version 0 to version 2. > [0.00] log_buf_len: 8388608 > [0.00] early log buf free: 13880(84%) > [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) > [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 > bytes) > [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > [0.00] Memory: 553056K/1048576K available (7245K kernel code, > 434K rwdata, 1944K rodata, 1688K init, 8087K bss, 495520K reserved, 0K > highmem) > [0.00] Hierarchical RCU implementation. > [0.00] NR_IRQS:160 > [0.00] Measuring MIPS counter frequency... > [0.00] Detected MIPS clock frequency: 1305 MHz (163.136 MHz counter) > [0.001000] Console: colour dummy device 80x25 > [0.002000] Lock dependency validator: Copyright (c) 2006 Red Hat, > Inc., Ingo Molnar > [0.003000] ... MAX_LOCKDEP_SUBCLASSES: 8 > [0.004000] ... MAX_LOCK_DEPTH: 48 > [0.005000] ... MAX_LOCKDEP_KEYS:8191 > [0.006000] ... CLASSHASH_SIZE: 4096 > [0.007000] ... MAX_LOCKDEP_ENTRIES: 32768 > [0.008000] ... MAX_LOCKDEP_CHAINS: 65536 > [0.009000] ... CHAINHASH_SIZE: 32768 > [0.01] memory used by lock dependency info: 5167 kB > [0.011000] per task-struct memory footprint: 1152 bytes > [0.018000] Calibrating delay loop... 864.25 BogoMIPS (lpj=432128) > [0.029000] pid_max: default: 32768 minimum: 301 > [0.032000] Mount-cache hash table entries:
[PATCH] nfs: use canonical path in nfs_show_devname
When export root dir(/) via nfs, and mount a particular dir under root, eg /nfsexport, there will be defect double slash output in /proc/mounts, like localhost://nfsexport. Signed-off-by: Xiong Zhou --- fs/nfs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/super.c b/fs/nfs/super.c index e4499d5..62b1cab 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -780,7 +780,7 @@ int nfs_show_devname(struct seq_file *m, struct dentry *root) int err = 0; if (!page) return -ENOMEM; - devname = nfs_path(, root, page, PAGE_SIZE, 0); + devname = nfs_path(, root, page, PAGE_SIZE, 1); if (IS_ERR(devname)) err = PTR_ERR(devname); else -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 03/15] clk: tegra: Add closed loop support for the DFLL
Hi,
On 08/19/2014 11:33 AM, Tuomas Tynkkynen wrote:
From: Tuomas Tynkkynen
With closed loop support, the clock rate of the DFLL can be adjusted.
The oscillator itself in the DFLL is a free-running oscillator whose
rate is directly determined the supply voltage. However, the DFLL
module contains logic to compare the DFLL output rate to a fixed
reference clock (51 MHz) and make a decision to either lower or raise
the DFLL supply voltage. The DFLL module can then autonomously change
the supply voltage by communicating with an off-chip PMIC via either I2C
or PWM signals. This driver currently supports only I2C.
Signed-off-by: Tuomas Tynkkynen
---
v3: Fix incorrect order of arguments to dfll_scale_dvco_rate
---
drivers/clk/tegra/clk-dfll.c | 656 ++-
1 file changed, 653 insertions(+), 3 deletions(-)
...
/**
+ * dfll_fetch_i2c_params - query PMIC I2C params from DT & regulator subsystem
+ * @td: DFLL instance
+ *
+ * Read all the parameters required for operation in I2C mode. The parameters
+ * can originate from the device tree or the regulator subsystem.
+ * Returns 0 on success or -err on failure.
+ */
+static int dfll_fetch_i2c_params(struct tegra_dfll *td)
+{
+ struct regmap *regmap;
+ struct device *i2c_dev;
+ struct i2c_client *i2c_client;
+ int vsel_reg, vsel_mask;
+ int ret;
+
+ if (!read_dt_param(td, "nvidia,i2c-fs-rate", >i2c_fs_rate))
+ return -EINVAL;
+
+ regmap = regulator_get_regmap(td->vdd_reg);
+ i2c_dev = regmap_get_device(regmap);
+ i2c_client = to_i2c_client(i2c_dev);
+
+ td->i2c_slave_addr = i2c_client->addr;
+
+ ret = regulator_get_hardware_vsel_register(td->vdd_reg,
+ _reg,
+ _mask);
+ if (ret < 0) {
+ dev_err(td->dev,
+ "regulator unsuitable for DFLL I2C operation\n");
+ return -EINVAL;
+ }
+
It seems that the td->i2c_reg never gets initialized, and we're lucky on
JetsonTK1 or Norrin. We should initialize the regulator offset here. Like:
td->i2c_reg = vsel_reg;
Thanks,
Vince
+ ret = dfll_build_i2c_lut(td);
+ if (ret) {
+ dev_err(td->dev, "couldn't build I2C LUT\n");
+ return ret;
+ }
+
+ return 0;
+}
+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: core: Fix build error due to const qualifier for ops
2014-08-18 22:10 GMT+08:00 Mark Brown : > On Mon, Aug 18, 2014 at 10:34:08AM +0800, Axel Lin wrote: >> Drop const qualifier for ops of struct regulator_desc. >> Allow regulator drivers to update ops before registering regulator. > > Applied, thanks. Hi Mark, I found this commit is applied and I got below build warning in your for-next tree. CC [M] drivers/regulator/hi6421-regulator.o drivers/regulator/hi6421-regulator.c:356:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:358:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:360:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:362:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:364:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:366:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:368:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:370:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:372:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:374:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:376:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:378:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:380:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:382:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:384:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:386:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:388:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:390:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:392:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:394:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:396:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:398:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:400:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:401:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:402:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:403:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:405:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/regulator/hi6421-regulator.c:407:2: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] As I mentioned in the commit log: Drop const qualifier for ops of struct regulator_desc. Allow regulator drivers to update ops before registering regulator. So I don't think it's necessary to add const for ops in struct regulator_desc. (I think the original point was the "regulator core" won't modify the ops). The fix is either drop the 'const' qualifier in hi6421-regulator driver or add back const qualifier for ops of struct regulator_desc in include/linux/regulator/driver.h. Which one do you prefer? Thanks, Axel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
Re: WARNING: CPU: 6 PID: 79 at fs/proc/generic.c:521 remove_proc_entry+0x170/0x180()
Hi Kujau,
It seems like a different issue, something wrong with
void nfs_fs_proc_net_exit(struct net *net)
{
struct nfs_net *nn = net_generic(net, nfs_net_id);
remove_proc_entry("volumes", nn->proc_nfsfs);
remove_proc_entry("servers", nn->proc_nfsfs);
remove_proc_entry("fs/nfsfs", NULL);
}
But I'm not familiar with this piece of code.
Regards!
Gerry
On 2014/8/20 9:04, Christian Kujau wrote:
> Hi,
>
> the warning below appeared while booting 3.17.0-rc1. I haven't seen the
> warning before, but found a recent report on oops.kernel.org:
>
> http://oops.kernel.org/oops/warning-at-fs-proc-generic-c521-remove_proc_entry0x18f-0x1a0/
>
> and also reports from July 2014, where the issue was reported to be fixed:
>
> https://lkml.org/lkml/2014/7/16/9
> https://lkml.org/lkml/2014/7/18/116
>
> And the patch really made it into 3.17.0-rc1, so maybe it's something else
> this time. Details and .config: http://nerdbynature.de/bits/3.17-rc1/
>
> Thanks,
> Christian.
>
> [ cut here ]
> WARNING: CPU: 6 PID: 79 at /usr/local/src/linux-git/fs/proc/generic.c:521
> remove_proc_entry+0x170/0x180()
> remove_proc_entry: removing non-empty directory 'fs/nfsfs', leaking at least
> 'volumes'
> Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops
> videobuf2_core v4l2_common btusb videodev bluetooth hid_logitech_dj
> sha256_ssse3 sha256_generic twofish_generic twofish_avx_x86_64
> twofish_x86_64_3way twofish_x86_64 twofish_common
> nfs xts lockd sunrpc arc4 coretemp x86_pkg_temp_thermal usbhid
> intel_powerclamp hid iwldvm kvm_intel
> mac80211 kvm snd_hda_codec_hdmi i2c_i801 iwlwifi cfg80211 thinkpad_acpi
> snd_hda_codec_conexant snd_hda_codec_generic nvram hwmon led_class wmi
> rtc_cmos i915 snd_hda_intel
> i2c_algo_bit snd_hda_controller drm_kms_helper snd_hda_codec drm snd_hwdep
> snd_pcm i2ccore snd_timer snd soundcore fuse autofs4 btrfs xor raid6_pq
> aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd sr_mod
> cdrom sg ehci_pci
> ehci_hcd xhci_hcd
> CPU: 6 PID: 79 Comm: kworker/u16:6 Not tainted 3.17.0-rc1 #1
> Hardware name: LENOVO 6277CTO/6277CTO, BIOS HEET42WW (1.23 ) 01/27/2014
> Workqueue: netns cleanup_net
> 0009 8149c1e2 880406c8fd18 8104ee6d
> 880406701580 880406c8fd68 0005 c0883bae
> c0883bb1 8104eed7 815b1578 88040030
> Call Trace:
> [] ? dump_stack+0x41/0x51
> [] ? warn_slowpath_common+0x6d/0x90
> [] ? warn_slowpath_fmt+0x47/0x50
> [] ? proc_entry_rundown+0x41/0x80
> [] ? remove_proc_entry+0x170/0x180
> [] ? nfs_net_exit+0x9/0x20 [nfs]
> [] ? ops_exit_list.isra.2+0x31/0x60
> [] ? cleanup_net+0x100/0x1e0
> [] ? process_one_work+0x16b/0x3b0
> [] ? worker_thread+0x63/0x490
> [] ? rescuer_thread+0x280/0x280
> [] ? kthread+0xca/0xe0
> [] ? kthread_create_on_node+0x170/0x170
> [] ? ret_from_fork+0x7c/0xb0
> [] ? kthread_create_on_node+0x170/0x170
> ---[ end trace c92165dd3f372cf6 ]---
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SOUND: kill gameport bits
Reply-To: In-Reply-To: <1408466497-25640-1-git-send-email-dmitry.torok...@gmail.com> X-Priority: none Hi, > Gameport support hasn't been working well ever since cpufreq became > mainstream and it becomes increasingly hard to find hardware and > software > that would run on such old hardware. Given that I'm puzzled why one would want to deprecate a whole subsystem which appears to be supported by a whole 14 different PCI sound card drivers (where the ones I'm owning hardware of are intended to be in active maintenance) and only 3 ISA-based ones, I'm missing several details and justifications of that decision here (perhaps there was a prior discussion/activity that I'm missing?). Also, I'm left wondering why e.g. my Athlon XP system (a very popular choice for longer times) would be affected by Cpufreq... And there are no details on how exactly cpufreq is a problem or how this timing issue could be fixed... The obvious workaround for such an ensuing dearth of hardware support could be USB 15-pin gameport adapters - but are they even supported on Linux? Haven't seen info on this... And even if supported, these adapters (at least the non-perfect ones, as can be seen from reviews on a well-known online shop site) are said to be hit-or-miss. http://www.flightsim.com/vbfs/showthread.php?238938-joystick-GamePort-to-USB-adapter-question http://reviews.thesource.ca/9026/2600164/nexxtech-usb-gameport-adapter-reviews/reviews.htm If we keep removing functionality like this, then why stop short of removing x86 32bit as a whole? By having Linux support nicely restricted to hardware made within the last 5 years, we would surely be doing the planned-obsolescence Micro$oft "ecosystem" (what was ecological about this again?) a huge favour... We already have an IMHO dangerous state in support of somewhat less mainstream hardware, so do we want to keep furthering that? Could we have more details/discussion prior to activities to remove whole subsystems? Thanks, Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] PC, KVM, CMA: Fix regression caused by wrong get_order() use
On Thu, Aug 14, 2014 at 03:03:07PM +1000, Alexey Kardashevskiy wrote: > fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no > functional change but this is not true as it calls get_order() (which > takes bytes) where it should have called ilog2() and the kernel stops > on VM_BUG_ON(). > > This replaces get_order() with order_base_2() (round-up version of ilog2). > > Suggested-by: Paul Mackerras > Cc: Alexander Graf > Cc: Aneesh Kumar K.V > Cc: Joonsoo Kim > Cc: Benjamin Herrenschmidt > Signed-off-by: Alexey Kardashevskiy Sorry for my fault. :( Acked-by: Joonsoo Kim Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/3] fs/buffer.c: allocate buffer cache with user specific flag
@@ -1381,12 +1383,7 @@ EXPORT_SYMBOL(__find_get_block);
struct buffer_head *
__getblk(struct block_device *bdev, sector_t block, unsigned size)
{
- struct buffer_head *bh = __find_get_block(bdev, block, size);
-
- might_sleep();
- if (bh == NULL)
- bh = __getblk_slow(bdev, block, size);
- return bh;
+ return __getblk_gfp(bdev, block, size, __GFP_MOVABLE);
}
EXPORT_SYMBOL(__getblk);
Why did you remove the __find_get_block() call? That looks like a bug.
I'm not sure if you didn't miss this comment
I'm sorry I missed it.
I think calling __find_get_block() in __getblk_gfp() can replace it.
I'm not sure about it.
If anybody disagree with it, I'll change it as the original code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf, map: Don't try to find DSOs in SYSV maps
We are seeing a lot of the following with regards to SYSV memory
Failed to open /SYSV279c, continuing without symbols
We don't believe this memory will have DSO info, so treat it like the heap and
stack for now and skip it to prevent the warning.
Signed-off-by: Joe Mario
Signed-off-by: Don Zickus
--
I am open to suggetions for a different fix - dcz
---
tools/perf/util/map.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 25c571f..0294f40 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -29,6 +29,7 @@ static inline int is_anon_memory(const char *filename)
static inline int is_no_dso_memory(const char *filename)
{
return !strncmp(filename, "[stack", 6) ||
+ !strncmp(filename, "/SYSV",5) ||
!strcmp(filename, "[heap]");
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: slub/debugobjects: lockup when freeing memory
On Tue, Aug 19, 2014 at 09:00:05PM -0500, Christoph Lameter wrote:
> On Mon, 18 Aug 2014, Paul E. McKenney wrote:
>
> > > +#ifdef CONFIG_RCU_DEBUG_XYZ
> >
> > If you make CONFIG_RCU_DEBUG_XYZ instead be CONFIG_DEBUG_OBJECTS_RCU_HEAD,
> > then it will automatically show up when it needs to.
>
> Ok.
>
> > The rest looks plausible, for whatever that is worth.
>
> We talked in the hallway about init_rcu_head not touching
> the contents of the rcu_head. If that is the case then we can simplify
> the patch.
That is correct -- the debug-objects code uses separate storage to track
states, and does not touch the memory to which the state applies.
> We could also remove the #ifdefs if init_rcu_head and destroy_rcu_head
> are no ops if CONFIG_DEBUG_RCU_HEAD is not defined.
And indeed they are, good point! It appears to me that both sets of
#ifdefs can go away.
Thanx, Paul
> Index: linux/mm/slub.c
> ===
> --- linux.orig/mm/slub.c
> +++ linux/mm/slub.c
> @@ -1308,6 +1308,25 @@ static inline struct page *alloc_slab_pa
> return page;
> }
>
> +#define need_reserve_slab_rcu
> \
> + (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
> +
> +static struct rcu_head *get_rcu_head(struct kmem_cache *s, struct page *page)
> +{
> + if (need_reserve_slab_rcu) {
> + int order = compound_order(page);
> + int offset = (PAGE_SIZE << order) - s->reserved;
> +
> + VM_BUG_ON(s->reserved != sizeof(struct rcu_head));
> + return page_address(page) + offset;
> + } else {
> + /*
> + * RCU free overloads the RCU head over the LRU
> + */
> + return (void *)>lru;
> + }
> +}
> +
> static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int
> node)
> {
> struct page *page;
> @@ -1357,6 +1376,22 @@ static struct page *allocate_slab(struct
> kmemcheck_mark_unallocated_pages(page, pages);
> }
>
> +#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
> + if (unlikely(s->flags & SLAB_DESTROY_BY_RCU) && page)
> + /*
> + * Initialize various things. However, this init is
> + * not allowed to modify the contents of the rcu head.
> + * Allocations are permitted. However, the use of
> + * the same cache or another cache with SLAB_RCU_DESTROY
> + * set may cause additional recursions.
> + *
> + * So in order to be safe the slab caches used
> + * in init_rcu_head should be restricted to be of the
> + * non rcu kind only.
> + */
> + init_rcu_head(get_rcu_head(s, page));
> +#endif
> +
> if (flags & __GFP_WAIT)
> local_irq_disable();
> if (!page)
> @@ -1452,13 +1487,13 @@ static void __free_slab(struct kmem_cach
> memcg_uncharge_slab(s, order);
> }
>
> -#define need_reserve_slab_rcu
> \
> - (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
> -
> static void rcu_free_slab(struct rcu_head *h)
> {
> struct page *page;
>
> +#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
> + destroy_rcu_head(h);
> +#endif
> if (need_reserve_slab_rcu)
> page = virt_to_head_page(h);
> else
> @@ -1469,24 +1504,9 @@ static void rcu_free_slab(struct rcu_hea
>
> static void free_slab(struct kmem_cache *s, struct page *page)
> {
> - if (unlikely(s->flags & SLAB_DESTROY_BY_RCU)) {
> - struct rcu_head *head;
> -
> - if (need_reserve_slab_rcu) {
> - int order = compound_order(page);
> - int offset = (PAGE_SIZE << order) - s->reserved;
> -
> - VM_BUG_ON(s->reserved != sizeof(*head));
> - head = page_address(page) + offset;
> - } else {
> - /*
> - * RCU free overloads the RCU head over the LRU
> - */
> - head = (void *)>lru;
> - }
> -
> - call_rcu(head, rcu_free_slab);
> - } else
> + if (unlikely(s->flags & SLAB_DESTROY_BY_RCU))
> + call_rcu(get_rcu_head(s, page), rcu_free_slab);
> + else
> __free_slab(s, page);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/3] fs/buffer.c: allocate buffer cache with user specific flag
On Wed 20-08-14 08:37:07, Gioh Kim wrote:
>
>
> 2014-08-19 오후 10:03, Jan Kara 쓴 글:
> > Hello,
> >
> >On Tue 19-08-14 15:52:38, Gioh Kim wrote:
> >>A buffer cache is allocated from movable area
> >>because it is referred for a while and released soon.
> >>But some filesystems are taking buffer cache for a long time
> >>and it can disturb page migration.
> >>
> >>A new API should be introduced to allocate buffer cache
> >>with user specific flag.
> >>For instance if user set flag to zero, buffer cache is allocated from
> >>non-movable area.
> >>
> >>Signed-off-by: Gioh Kim
> >>---
> >> fs/buffer.c | 52
> >> +--
> >> include/linux/buffer_head.h | 12 +-
> >> 2 files changed, 46 insertions(+), 18 deletions(-)
> >>
> >>diff --git a/fs/buffer.c b/fs/buffer.c
> >>index 8f05111..14f2f21 100644
> >>--- a/fs/buffer.c
> >>+++ b/fs/buffer.c
> >>@@ -993,7 +993,7 @@ init_page_buffers(struct page *page, struct
> >>block_device *bdev,
> >> */
> >> static int
> >> grow_dev_page(struct block_device *bdev, sector_t block,
> >>- pgoff_t index, int size, int sizebits)
> >>+ pgoff_t index, int size, int sizebits, gfp_t gfp)
> >> {
> >> struct inode *inode = bdev->bd_inode;
> >> struct page *page;
> >>@@ -1002,10 +1002,10 @@ grow_dev_page(struct block_device *bdev, sector_t
> >>block,
> >> int ret = 0;/* Will call free_more_memory() */
> >> gfp_t gfp_mask;
> >>
> >>- gfp_mask = mapping_gfp_mask(inode->i_mapping) & ~__GFP_FS;
> >>- gfp_mask |= __GFP_MOVABLE;
> >>+ gfp_mask = (mapping_gfp_mask(inode->i_mapping) & ~__GFP_FS) | gfp;
> >>+
> > Hum, it seems a bit misleading that the 'gfp' flags are just or-ed to
> >mapping_gfp_mask(inode->i_mapping). Usually, passed gfp mask is just
> >directly used. There are also interfaces like pagecache_get_page() which
> >play more complex tricks with mapping_gfp_mask(). This would be yet another
> >convention which I don't think is desirable. I know Andrew suggested what
> >you wrote so I guess I have to settle this with him. Andrew?
>
> I don't know mapping_gfp_mask(). I just add gfp at the original code.
> Whould you tell me why it is undesirable?
Well, it's not that mapping_gfp_mask() would be undesirable. It's that
the interface where you pass in gfp mask but it gets silently combined with
another gfp mask seems a bit error prone to me. So would prefer
grow_dev_page() to just use the gfp mask passed and then do something like:
struct buffer_head *getblk_unmovable(struct block_device *bdev, sector_t block,
unsigned size)
{
return __getblk_gfp(bdev, block, size,
mapping_gfp_mask(bdev->bd_inode->i_mapping));
}
And similarly in getblk() and other places. But before you go and do this,
I'd like Andrew to say what he thinks about it because maybe he had a good
reason why he wanted it the way you've implemented it.
> >>@@ -1381,12 +1383,7 @@ EXPORT_SYMBOL(__find_get_block);
> >> struct buffer_head *
> >> __getblk(struct block_device *bdev, sector_t block, unsigned size)
> >> {
> >>- struct buffer_head *bh = __find_get_block(bdev, block, size);
> >>-
> >>- might_sleep();
> >>- if (bh == NULL)
> >>- bh = __getblk_slow(bdev, block, size);
> >>- return bh;
> >>+ return __getblk_gfp(bdev, block, size, __GFP_MOVABLE);
> >> }
> >> EXPORT_SYMBOL(__getblk);
> > Why did you remove the __find_get_block() call? That looks like a bug.
I'm not sure if you didn't miss this comment
> I think the common interface is important.
>
> If sb_getblk_unmovable() is obvious for the filesystem,
> I will add some codes for getblk_unmovable() which calling __getblk_gfp(),
> and sb_bread_unmovable() calling __bread_gfp().
> If so, sb_bread_gfp is not necessary.
>
> It might be like followings:
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 14f2f21..35caf77 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1088,7 +1088,7 @@ grow_buffers(struct block_device *bdev, sector_t block,
> int siz
> return grow_dev_page(bdev, block, index, size, sizebits, gfp);
> }
>
> -struct buffer_head *
> +static struct buffer_head *
> __getblk_gfp(struct block_device *bdev, sector_t block,
> unsigned size, gfp_t gfp)
> {
> @@ -1119,7 +1119,13 @@ __getblk_gfp(struct block_device *bdev, sector_t block,
> free_more_memory();
> }
> }
> -EXPORT_SYMBOL(__getblk_gfp);
> +
> +struct buffer_head *getblk_unmovable(struct block_device *bdev, sector_t
> block,
> +unsigned size)
> +{
> + return __getblk_gfp(bdev, block, size, 0);
> +}
> +EXPORT_SYMBOL(getblk_unmovable);
>
> /*
> * The relationship between dirty buffers and dirty pages:
> diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
> index a1d73fd..c5fb4fc 100644
> --- a/include/linux/buffer_head.h
> +++
Re: [PATCH] zram: add num_discards for discarded pages stat
Hi Sergey,
On Tue, Aug 19, 2014 at 08:25:00PM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> On (08/19/14 13:45), Chao Yu wrote:
> > > On (08/15/14 11:27), Chao Yu wrote:
> > > > Now we have supported handling discard request which is sended by
> > > > filesystem,
> > > > but no interface could be used to show information of discard.
> > > > This patch adds num_discards to stat discarded pages, then export it to
> > > > sysfs
> > > > for displaying.
> > > >
> > >
> > > a side question: we account discarded pages via slot free notify in
> > > notify_free and via req_discard in num_discards. how about accounting
> > > both of them in num_discards? because, after all, they account a number
> > > of discarded pages (zram_free_page()). or there any particular reason we
> > > want to distinguish.
> >
> > Yeah, I agree with you as I have no such reason unless there are our users'
> > explicitly requirement for showing notify_free/num_discards separately
> > later.
> >
> > How do you think of sending another patch to merge these two counts?
> >
>
> Minchan, what do you think? let's account discarded pages in one place.
First of all, I'd like to know why we need num_discards.
It should be in description and depends on it whether we should merge both
counts or separate.
Thanks.
>
> > One more thing is that I am missing to update document of zram, sorry about
> > that, let me update it in v2.
>
> thanks.
>
> -ss
>
> > Thanks,
> > Yu
> >
> > >
> > > -ss
> > >
> > > > Signed-off-by: Chao Yu
> > > > ---
> > > > Documentation/ABI/testing/sysfs-block-zram | 10 ++
> > > > drivers/block/zram/zram_drv.c | 3 +++
> > > > drivers/block/zram/zram_drv.h | 1 +
> > > > 3 files changed, 14 insertions(+)
> > > >
> > > > diff --git a/Documentation/ABI/testing/sysfs-block-zram
> > > b/Documentation/ABI/testing/sysfs-block-zram
> > > > index 70ec992..fa8936e 100644
> > > > --- a/Documentation/ABI/testing/sysfs-block-zram
> > > > +++ b/Documentation/ABI/testing/sysfs-block-zram
> > > > @@ -57,6 +57,16 @@ Description:
> > > > The failed_writes file is read-only and specifies the
> > > > number of
> > > > failed writes happened on this device.
> > > >
> > > > +
> > > > +What: /sys/block/zram/num_discards
> > > > +Date: August 2014
> > > > +Contact: Chao Yu
> > > > +Description:
> > > > + The num_discards file is read-only and specifies the
> > > > number of
> > > > + physical blocks which are discarded by this device.
> > > > These blocks
> > > > + are included in discard request which is sended by
> > > > filesystem as
> > > > + the blocks are no longer used.
> > > > +
> > > > What: /sys/block/zram/max_comp_streams
> > > > Date: February 2014
> > > > Contact: Sergey Senozhatsky
> > > > diff --git a/drivers/block/zram/zram_drv.c
> > > > b/drivers/block/zram/zram_drv.c
> > > > index d00831c..904e7a5 100644
> > > > --- a/drivers/block/zram/zram_drv.c
> > > > +++ b/drivers/block/zram/zram_drv.c
> > > > @@ -606,6 +606,7 @@ static void zram_bio_discard(struct zram *zram, u32
> > > > index,
> > > > bit_spin_lock(ZRAM_ACCESS, >table[index].value);
> > > > zram_free_page(zram, index);
> > > > bit_spin_unlock(ZRAM_ACCESS, >table[index].value);
> > > > + atomic64_inc(>stats.num_discards);
> > > > index++;
> > > > n -= PAGE_SIZE;
> > > > }
> > > > @@ -866,6 +867,7 @@ ZRAM_ATTR_RO(num_reads);
> > > > ZRAM_ATTR_RO(num_writes);
> > > > ZRAM_ATTR_RO(failed_reads);
> > > > ZRAM_ATTR_RO(failed_writes);
> > > > +ZRAM_ATTR_RO(num_discards);
> > > > ZRAM_ATTR_RO(invalid_io);
> > > > ZRAM_ATTR_RO(notify_free);
> > > > ZRAM_ATTR_RO(zero_pages);
> > > > @@ -879,6 +881,7 @@ static struct attribute *zram_disk_attrs[] = {
> > > > _attr_num_writes.attr,
> > > > _attr_failed_reads.attr,
> > > > _attr_failed_writes.attr,
> > > > + _attr_num_discards.attr,
> > > > _attr_invalid_io.attr,
> > > > _attr_notify_free.attr,
> > > > _attr_zero_pages.attr,
> > > > diff --git a/drivers/block/zram/zram_drv.h
> > > > b/drivers/block/zram/zram_drv.h
> > > > index e0f725c..2994aaf 100644
> > > > --- a/drivers/block/zram/zram_drv.h
> > > > +++ b/drivers/block/zram/zram_drv.h
> > > > @@ -86,6 +86,7 @@ struct zram_stats {
> > > > atomic64_t num_writes; /* --do-- */
> > > > atomic64_t failed_reads;/* can happen when memory is
> > > > too low */
> > > > atomic64_t failed_writes; /* can happen when memory is
> > > > too low */
> > > > + atomic64_t num_discards;/* no. of discarded pages */
> > > > atomic64_t invalid_io; /* non-page-aligned I/O requests */
> > > > atomic64_t notify_free; /* no. of swap slot free notifications
> > > > */
> > > >
RE: [f2fs-dev] [PATCH 3/4] f2fs: avoid double lock in truncate_blocks
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Wednesday, August 20, 2014 12:58 AM
> To: Chao Yu
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 3/4] f2fs: avoid double lock in truncate_blocks
>
> On Tue, Aug 19, 2014 at 04:04:11PM +0800, Chao Yu wrote:
> > Hi Jaegeuk,
> >
> > > -Original Message-
> > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > > Sent: Saturday, August 16, 2014 6:04 AM
> > > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> > > linux-f2fs-de...@lists.sourceforge.net
> > > Cc: Jaegeuk Kim
> > > Subject: [f2fs-dev] [PATCH 3/4] f2fs: avoid double lock in truncate_blocks
> > >
> > > The init_inode_metadata calls truncate_blocks when error is occurred.
> > > The callers holds f2fs_lock_op, so we should not call it again in
> > > truncate_blocks.
> >
> > Nice catch! Your solution is a good way to fix this issue.
> >
> > Previously, in create inode path, I found there are some redundant codes
> > between
> > init_inode_metadata and evict_inode, including:
> > truncate_inode_pages(>i_data, 0);
> > truncate_blocks(inode, 0);
> > remove_dirty_dir_inode(inode);
> > remove_inode_page(inode);
> >
> > So I think there is another way to fix this issue by removing error path
> > handling
> > codes in init_inode_metadata, not making the inode bad to left garbage
> > clean work in
> > evict_inode. In this way we can avoid adding additional argument for all
> > different
> > callers.
>
> Well, possible.
> But we need to take a closer look at the race condition on the inode cache.
> What can happen if this bad inode is reassigned to the other thread?
I don't get it. As I know, in evict(), we call ->evict_inode before
remove_inode_hash(), so before all clean work was done we will not reassign
this hashed uncleaned inode to other thread.
Am I missing anything?
Regards,
Yu
>
> >
> > How do you think?
> >
> > Thanks,
> > Yu
> >
> > >
> > > Signed-off-by: Jaegeuk Kim
> > > ---
> > > fs/f2fs/data.c | 2 +-
> > > fs/f2fs/dir.c| 2 +-
> > > fs/f2fs/f2fs.h | 2 +-
> > > fs/f2fs/file.c | 13 -
> > > fs/f2fs/inline.c | 2 +-
> > > 5 files changed, 12 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > > index 68834e2..14cc3e8 100644
> > > --- a/fs/f2fs/data.c
> > > +++ b/fs/f2fs/data.c
> > > @@ -935,7 +935,7 @@ static void f2fs_write_failed(struct address_space
> > > *mapping, loff_t
> to)
> > >
> > > if (to > inode->i_size) {
> > > truncate_pagecache(inode, inode->i_size);
> > > - truncate_blocks(inode, inode->i_size);
> > > + truncate_blocks(inode, inode->i_size, true);
> > > }
> > > }
> > >
> > > diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> > > index a69bbfa..155fb05 100644
> > > --- a/fs/f2fs/dir.c
> > > +++ b/fs/f2fs/dir.c
> > > @@ -391,7 +391,7 @@ put_error:
> > > error:
> > > /* once the failed inode becomes a bad inode, i_mode is S_IFREG */
> > > truncate_inode_pages(>i_data, 0);
> > > - truncate_blocks(inode, 0);
> > > + truncate_blocks(inode, 0, false);
> > > remove_dirty_dir_inode(inode);
> > > remove_inode_page(inode);
> > > return ERR_PTR(err);
> > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > > index 2723b2d..7f976c1 100644
> > > --- a/fs/f2fs/f2fs.h
> > > +++ b/fs/f2fs/f2fs.h
> > > @@ -1122,7 +1122,7 @@ static inline void f2fs_stop_checkpoint(struct
> > > f2fs_sb_info *sbi)
> > > */
> > > int f2fs_sync_file(struct file *, loff_t, loff_t, int);
> > > void truncate_data_blocks(struct dnode_of_data *);
> > > -int truncate_blocks(struct inode *, u64);
> > > +int truncate_blocks(struct inode *, u64, bool);
> > > void f2fs_truncate(struct inode *);
> > > int f2fs_getattr(struct vfsmount *, struct dentry *, struct kstat *);
> > > int f2fs_setattr(struct dentry *, struct iattr *);
> > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > > index ecbdf6a..a8e97f8 100644
> > > --- a/fs/f2fs/file.c
> > > +++ b/fs/f2fs/file.c
> > > @@ -422,7 +422,7 @@ out:
> > > f2fs_put_page(page, 1);
> > > }
> > >
> > > -int truncate_blocks(struct inode *inode, u64 from)
> > > +int truncate_blocks(struct inode *inode, u64 from, bool lock)
> > > {
> > > struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
> > > unsigned int blocksize = inode->i_sb->s_blocksize;
> > > @@ -438,14 +438,16 @@ int truncate_blocks(struct inode *inode, u64 from)
> > > free_from = (pgoff_t)
> > > ((from + blocksize - 1) >> (sbi->log_blocksize));
> > >
> > > - f2fs_lock_op(sbi);
> > > + if (lock)
> > > + f2fs_lock_op(sbi);
> > >
> > > set_new_dnode(, inode, NULL, NULL, 0);
> > > err = get_dnode_of_data(, free_from, LOOKUP_NODE);
> > > if (err) {
> > > if (err == -ENOENT)
> > > goto free_next;
> > > - f2fs_unlock_op(sbi);
> > > + if (lock)
> > > +
[PATCH] regulator: max77802: Remove unused fields from struct max77802_regulator_prv
Both num_regulators and *rdev[MAX77802_REG_MAX] are not used, remove them.
Signed-off-by: Axel Lin
---
drivers/regulator/max77802.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 5f022f8..ad1caa9 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -65,8 +65,6 @@ static unsigned int ramp_table_77802_4bit[] = {
};
struct max77802_regulator_prv {
- int num_regulators;
- struct regulator_dev *rdev[MAX77802_REG_MAX];
unsigned int opmode[MAX77802_REG_MAX];
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: slub/debugobjects: lockup when freeing memory
On Mon, 18 Aug 2014, Paul E. McKenney wrote:
> > +#ifdef CONFIG_RCU_DEBUG_XYZ
>
> If you make CONFIG_RCU_DEBUG_XYZ instead be CONFIG_DEBUG_OBJECTS_RCU_HEAD,
> then it will automatically show up when it needs to.
Ok.
> The rest looks plausible, for whatever that is worth.
We talked in the hallway about init_rcu_head not touching
the contents of the rcu_head. If that is the case then we can simplify
the patch.
We could also remove the #ifdefs if init_rcu_head and destroy_rcu_head
are no ops if CONFIG_DEBUG_RCU_HEAD is not defined.
Index: linux/mm/slub.c
===
--- linux.orig/mm/slub.c
+++ linux/mm/slub.c
@@ -1308,6 +1308,25 @@ static inline struct page *alloc_slab_pa
return page;
}
+#define need_reserve_slab_rcu \
+ (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
+
+static struct rcu_head *get_rcu_head(struct kmem_cache *s, struct page *page)
+{
+ if (need_reserve_slab_rcu) {
+ int order = compound_order(page);
+ int offset = (PAGE_SIZE << order) - s->reserved;
+
+ VM_BUG_ON(s->reserved != sizeof(struct rcu_head));
+ return page_address(page) + offset;
+ } else {
+ /*
+* RCU free overloads the RCU head over the LRU
+*/
+ return (void *)>lru;
+ }
+}
+
static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
{
struct page *page;
@@ -1357,6 +1376,22 @@ static struct page *allocate_slab(struct
kmemcheck_mark_unallocated_pages(page, pages);
}
+#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
+ if (unlikely(s->flags & SLAB_DESTROY_BY_RCU) && page)
+ /*
+* Initialize various things. However, this init is
+* not allowed to modify the contents of the rcu head.
+* Allocations are permitted. However, the use of
+* the same cache or another cache with SLAB_RCU_DESTROY
+* set may cause additional recursions.
+*
+* So in order to be safe the slab caches used
+* in init_rcu_head should be restricted to be of the
+* non rcu kind only.
+*/
+ init_rcu_head(get_rcu_head(s, page));
+#endif
+
if (flags & __GFP_WAIT)
local_irq_disable();
if (!page)
@@ -1452,13 +1487,13 @@ static void __free_slab(struct kmem_cach
memcg_uncharge_slab(s, order);
}
-#define need_reserve_slab_rcu \
- (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
-
static void rcu_free_slab(struct rcu_head *h)
{
struct page *page;
+#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
+ destroy_rcu_head(h);
+#endif
if (need_reserve_slab_rcu)
page = virt_to_head_page(h);
else
@@ -1469,24 +1504,9 @@ static void rcu_free_slab(struct rcu_hea
static void free_slab(struct kmem_cache *s, struct page *page)
{
- if (unlikely(s->flags & SLAB_DESTROY_BY_RCU)) {
- struct rcu_head *head;
-
- if (need_reserve_slab_rcu) {
- int order = compound_order(page);
- int offset = (PAGE_SIZE << order) - s->reserved;
-
- VM_BUG_ON(s->reserved != sizeof(*head));
- head = page_address(page) + offset;
- } else {
- /*
-* RCU free overloads the RCU head over the LRU
-*/
- head = (void *)>lru;
- }
-
- call_rcu(head, rcu_free_slab);
- } else
+ if (unlikely(s->flags & SLAB_DESTROY_BY_RCU))
+ call_rcu(get_rcu_head(s, page), rcu_free_slab);
+ else
__free_slab(s, page);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] leds: make led_blink_set IRQ safe
On Tue, 19 Aug 2014, Vincent Donnefort wrote:
> This patch introduces a work which take care of reseting the blink workqueue
> and
> avoid calling the cancel_delayed_work_sync function which may sleep, from an
> IRQ
> context.
>
> Signed-off-by: Vincent Donnefort
Thanks. It does work for me. Though the problem was more general than
stated above: not just a problem in IRQ context, but in any atomic context.
I don't suppose it has any effect on Valdis's lockdep issue, which I
didn't get to see myself; but we should let Valdis report back on that.
May I (most ungratefully!) say that your patch doesn't fill me with
confidence that it's the right solution: adding yet another work_struct
to get around the issue seemed dubious to me, I wonder if it might expose
new races.
But rest assured that I know nothing about this, and I'm not at all
qualified to review your patch: I hope Bryan and others will do so.
Thanks,
Hugh
>
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 129729d..0971554 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -148,6 +148,24 @@ static void led_work_function(struct work_struct *ws)
> msecs_to_jiffies(delay));
> }
>
> +static void reset_blink_work_delayed(struct work_struct *ws)
> +{
> + struct led_classdev *led_cdev =
> + container_of(ws, struct led_classdev, reset_blink_work);
> +
> + cancel_delayed_work_sync(_cdev->blink_work);
> +
> + if (!led_cdev->blink_delay_on) {
> + __led_set_brightness(led_cdev, LED_OFF);
> + return;
> + } else if (!led_cdev->blink_delay_off) {
> + __led_set_brightness(led_cdev, led_cdev->blink_brightness);
> + return;
> + }
> +
> + queue_delayed_work(system_wq, _cdev->blink_work, 1);
> +}
> +
> static void set_brightness_delayed(struct work_struct *ws)
> {
> struct led_classdev *led_cdev =
> @@ -234,6 +252,7 @@ int led_classdev_register(struct device *parent, struct
> led_classdev *led_cdev)
> INIT_WORK(_cdev->set_brightness_work, set_brightness_delayed);
>
> INIT_DELAYED_WORK(_cdev->blink_work, led_work_function);
> + INIT_WORK(_cdev->reset_blink_work, reset_blink_work_delayed);
>
> #ifdef CONFIG_LEDS_TRIGGERS
> led_trigger_set_default(led_cdev);
> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> index 4bb1168..959510a 100644
> --- a/drivers/leds/led-core.c
> +++ b/drivers/leds/led-core.c
> @@ -40,19 +40,7 @@ static void led_set_software_blink(struct led_classdev
> *led_cdev,
> led_cdev->blink_delay_on = delay_on;
> led_cdev->blink_delay_off = delay_off;
>
> - /* never on - just set to off */
> - if (!delay_on) {
> - __led_set_brightness(led_cdev, LED_OFF);
> - return;
> - }
> -
> - /* never off - just set to brightness */
> - if (!delay_off) {
> - __led_set_brightness(led_cdev, led_cdev->blink_brightness);
> - return;
> - }
> -
> - queue_delayed_work(system_wq, _cdev->blink_work, 1);
> + schedule_work(_cdev->reset_blink_work);
> }
>
>
> @@ -76,8 +64,6 @@ void led_blink_set(struct led_classdev *led_cdev,
> unsigned long *delay_on,
> unsigned long *delay_off)
> {
> - cancel_delayed_work_sync(_cdev->blink_work);
> -
> led_cdev->flags &= ~LED_BLINK_ONESHOT;
> led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP;
>
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 6a599dc..6e5523d 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -69,6 +69,7 @@ struct led_classdev {
>
> unsigned longblink_delay_on, blink_delay_off;
> struct delayed_work blink_work;
> + struct work_struct reset_blink_work;
> int blink_brightness;
>
> struct work_struct set_brightness_work;
> --
> 1.9.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] perf/x86/uncore: register PMU only if uncore pci device exists
Current code reigsters PMUs for all possible uncore pci devices.
This is not good because, on some machines, one or more uncore pci
devices can be missing. The missing pci device make corresponding
PMU unusable.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 2485fd9..4b7b669 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -793,6 +793,7 @@ static int uncore_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id
struct intel_uncore_box *box;
struct intel_uncore_type *type;
int phys_id;
+ bool first_box = false;
phys_id = uncore_pcibus_to_physid[pdev->bus->number];
if (phys_id < 0)
@@ -827,9 +828,13 @@ static int uncore_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id
pci_set_drvdata(pdev, box);
raw_spin_lock(_box_lock);
+ if (list_empty(>box_list))
+ first_box = true;
list_add_tail(>list, >box_list);
raw_spin_unlock(_box_lock);
+ if (first_box)
+ uncore_pmu_register(pmu);
return 0;
}
@@ -838,6 +843,7 @@ static void uncore_pci_remove(struct pci_dev *pdev)
struct intel_uncore_box *box = pci_get_drvdata(pdev);
struct intel_uncore_pmu *pmu;
int i, cpu, phys_id = uncore_pcibus_to_physid[pdev->bus->number];
+ bool last_box = false;
box = pci_get_drvdata(pdev);
if (!box) {
@@ -859,6 +865,8 @@ static void uncore_pci_remove(struct pci_dev *pdev)
raw_spin_lock(_box_lock);
list_del(>list);
+ if (list_empty(>box_list))
+ last_box = true;
raw_spin_unlock(_box_lock);
for_each_possible_cpu(cpu) {
@@ -870,6 +878,9 @@ static void uncore_pci_remove(struct pci_dev *pdev)
WARN_ON_ONCE(atomic_read(>refcnt) != 1);
kfree(box);
+
+ if (last_box)
+ perf_pmu_unregister(>pmu);
}
static int __init uncore_pci_init(void)
@@ -1220,14 +1231,6 @@ static int __init uncore_pmus_register(void)
}
}
- for (i = 0; uncore_pci_uncores[i]; i++) {
- type = uncore_pci_uncores[i];
- for (j = 0; j < type->num_boxes; j++) {
- pmu = >pmus[j];
- uncore_pmu_register(pmu);
- }
- }
-
return 0;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] perf/x86/intel: Add Haswell-EP uncore support
The uncore subsystem in Haswell-EP is similar to Sandy/Ivy Bridge-EP. There are some differences in config register encoding and pci device IDs. The Haswell-EP uncore also supports a few new events. Signed-off-by: Yan, Zheng --- arch/x86/kernel/cpu/perf_event_intel_uncore.c | 6 +- arch/x86/kernel/cpu/perf_event_intel_uncore.h | 2 + .../x86/kernel/cpu/perf_event_intel_uncore_snbep.c | 590 - 3 files changed, 596 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c b/arch/x86/kernel/cpu/perf_event_intel_uncore.c index 4785ee8..2485fd9 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c @@ -883,6 +883,8 @@ static int __init uncore_pci_init(void) case 62: /* Ivy Bridge-EP */ ret = ivbep_uncore_pci_init(); break; + case 63: /* Haswell-EP */ + ret = hswep_uncore_pci_init(); case 42: /* Sandy Bridge */ ret = snb_uncore_pci_init(); break; @@ -1190,7 +1192,9 @@ static int __init uncore_cpu_init(void) case 62: /* Ivy Bridge-EP */ ivbep_uncore_cpu_init(); break; - + case 63: /* Haswell-EP */ + hswep_uncore_cpu_init(); + break; default: return 0; } diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.h b/arch/x86/kernel/cpu/perf_event_intel_uncore.h index 1d7e894..18eb78b 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.h +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.h @@ -332,6 +332,8 @@ int snbep_uncore_pci_init(void); void snbep_uncore_cpu_init(void); int ivbep_uncore_pci_init(void); void ivbep_uncore_cpu_init(void); +int hswep_uncore_pci_init(void); +void hswep_uncore_cpu_init(void); /* perf_event_intel_uncore_nhmex.c */ void nhmex_uncore_cpu_init(void); diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c b/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c index d3e9c55..7873b05 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c @@ -163,6 +163,53 @@ #define __BITS_VALUE(x, i, n) ((typeof(x))(((x) >> ((i) * (n))) & \ ((1ULL << (n)) - 1))) +/* Haswell-EP Ubox */ +#define HSWEP_U_MSR_PMON_CTR0 0x705 +#define HSWEP_U_MSR_PMON_CTL0 0x709 +#define HSWEP_U_MSR_PMON_FILTER0x707 + +#define HSWEP_U_MSR_PMON_UCLK_FIXED_CTL0x703 +#define HSWEP_U_MSR_PMON_UCLK_FIXED_CTR0x704 + +#define HSWEP_U_MSR_PMON_BOX_FILTER_TID(0x1 << 0) +#define HSWEP_U_MSR_PMON_BOX_FILTER_CID(0x1fULL << 1) +#define HSWEP_U_MSR_PMON_BOX_FILTER_MASK \ + (HSWEP_U_MSR_PMON_BOX_FILTER_TID | \ +HSWEP_U_MSR_PMON_BOX_FILTER_CID) + +/* Haswell-EP CBo */ +#define HSWEP_C0_MSR_PMON_CTR0 0xe08 +#define HSWEP_C0_MSR_PMON_CTL0 0xe01 +#define HSWEP_C0_MSR_PMON_BOX_CTL 0xe00 +#define HSWEP_C0_MSR_PMON_BOX_FILTER0 0xe05 +#define HSWEP_CBO_MSR_OFFSET 0x10 + + +#define HSWEP_CB0_MSR_PMON_BOX_FILTER_TID (0x3fULL << 0) +#define HSWEP_CB0_MSR_PMON_BOX_FILTER_LINK (0xfULL << 6) +#define HSWEP_CB0_MSR_PMON_BOX_FILTER_STATE(0x7fULL << 17) +#define HSWEP_CB0_MSR_PMON_BOX_FILTER_NID (0xULL << 32) +#define HSWEP_CB0_MSR_PMON_BOX_FILTER_OPC (0x1ffULL << 52) +#define HSWEP_CB0_MSR_PMON_BOX_FILTER_C6 (0x1ULL << 61) +#define HSWEP_CB0_MSR_PMON_BOX_FILTER_NC (0x1ULL << 62) +#define HSWEP_CB0_MSR_PMON_BOX_FILTER_IOSC (0x1ULL << 63) + + +/* Haswell-EP Sbox */ +#define HSWEP_S0_MSR_PMON_CTR0 0x726 +#define HSWEP_S0_MSR_PMON_CTL0 0x721 +#define HSWEP_S0_MSR_PMON_BOX_CTL 0x720 +#define HSWEP_SBOX_MSR_OFFSET 0xa +#define HSWEP_S_MSR_PMON_RAW_EVENT_MASK (SNBEP_PMON_RAW_EVENT_MASK | \ +SNBEP_CBO_PMON_CTL_TID_EN) + +/* Haswell-EP PCU */ +#define HSWEP_PCU_MSR_PMON_CTR00x717 +#define HSWEP_PCU_MSR_PMON_CTL00x711 +#define HSWEP_PCU_MSR_PMON_BOX_CTL 0x710 +#define HSWEP_PCU_MSR_PMON_BOX_FILTER 0x715 + + DEFINE_UNCORE_FORMAT_ATTR(event, event, "config:0-7"); DEFINE_UNCORE_FORMAT_ATTR(event_ext, event, "config:0-7,21"); DEFINE_UNCORE_FORMAT_ATTR(umask, umask, "config:8-15"); @@ -175,11 +222,16 @@ DEFINE_UNCORE_FORMAT_ATTR(occ_sel, occ_sel, "config:14-15"); DEFINE_UNCORE_FORMAT_ATTR(occ_invert, occ_invert, "config:30"); DEFINE_UNCORE_FORMAT_ATTR(occ_edge, occ_edge, "config:14-51"); DEFINE_UNCORE_FORMAT_ATTR(filter_tid, filter_tid, "config1:0-4");
Re: [PATCH v1 5/9] block: loop: convert to blk-mq
On Wed, Aug 20, 2014 at 4:50 AM, Jens Axboe wrote: > On 2014-08-18 06:53, Ming Lei wrote: >> >> On Mon, Aug 18, 2014 at 9:22 AM, Ming Lei wrote: >>> >>> On Mon, Aug 18, 2014 at 1:48 AM, Jens Axboe wrote: On 2014-08-16 02:06, Ming Lei wrote: > > > On 8/16/14, Jens Axboe wrote: >> >> >> On 08/15/2014 10:36 AM, Jens Axboe wrote: >>> >>> >>> On 08/15/2014 10:31 AM, Christoph Hellwig wrote: > > > +static void loop_queue_work(struct work_struct *work) Offloading work straight to a workqueue dosn't make much sense in the blk-mq model as we'll usually be called from one. If you need to avoid the cases where we are called directly a flag for the blk-mq code to always schedule a workqueue sounds like a much better plan. >>> >>> >>> >>> That's a good point - would clean up this bit, and be pretty close to >>> a >>> one-liner to support in blk-mq for the drivers that always need >>> blocking >>> context. >> >> >> >> Something like this should do the trick - totally untested. But with >> that, loop would just need to add BLK_MQ_F_WQ_CONTEXT to it's tag set >> flags and it could always do the work inline from ->queue_rq(). > > > > I think it is a good idea. > > But for loop, there may be two problems: > > - default max_active for bound workqueue is 256, which means several > slow > loop devices might slow down whole block system. With kernel AIO, it > won't > be a big deal, but some block/fs may not support direct I/O and still > fallback to > workqueue > > - 6. Guidelines of Documentation/workqueue.txt > If there is dependency among multiple work items used during memory > reclaim, they should be queued to separate wq each with WQ_MEM_RECLAIM. Both are good points. But I think this mainly means that we should support this through a potentially per-dispatch queue workqueue, separate from kblockd. There's no reason blk-mq can't support this with a per-hctx workqueue, for drivers that need it. >>> >>> >>> Good idea, and per-device workqueue should be enough if >>> BLK_MQ_F_WQ_CONTEXT flag is set. >> >> >> Maybe for most of cases per-device class(driver) workqueue should be >> enough since dependency between devices driven by same driver >> isn't common, for example, loop over loop is absolutely insane. > > > It's insane, but it can happen. And given how cheap it is to do a workqueue, Workqueue with WQ_MEM_RECLAIM need to create a standalone kthread for the queue, so at default there will be 8 kthreads created even no one uses loop at all. From current implementation the per-device thread is created only when one file or blk device is attached to the loop device, which may not be possible when blk-mq supports per-device workqueue. > I don't see a reason why we should not. Loop over loop might seem nutty, but > it's not that far out into the realm of nutty things that people end up > doing. Another reason I am still not sure if workqueue is good for loop, though I do really like workqueue for sake of simplicity, :-) - sequential read becomes a bit slow with workqueue, especially for some fast block(such as null_blk) - random read becomes a bit slow too for some fast devices(such as null_blk) in some environment(It is reproduced in my server, but can't in my laptop) even it can improve throughout quite much for common devices(HDD., SSD,..) >From my investigation, context switch increases almost 50% with workqueue compared with kthread in loop in a quad-core VM. With kthread, requests may be handled as batch in cases which won't be blocked in read()/write()(like null_blk, tmpfs, ...), but it is impossible with workqueue any more. Also block plug should have been used with kthread to optimize the case, especially when kernel AIO is applied, still impossible with work queue too. So looks kthread with kernel AIO is still not bad for the blk-mq conversion, which can improve throughput much too. Or other ideas? Thanks > > >> I will keep the work queue in loop-mq V2, and it should be easy to switch >> to the mechanism once it is ready. > > > Reworked a bit more: > > http://git.kernel.dk/?p=linux-block.git;a=commit;h=a323185a761b9a54dc340d383695b4205ea258b6 > > Lets base loop-mq on the blk-mq workqueues, it would simplify it quite a bit > and I don't think there's much point in doing v1 and then ripping it out for > v2. Especially since it isn't queued up for 3.18 yet. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/4 v2] drivers/bus: Added Freescale Management Complex APIs
On Tue, 2014-08-19 at 19:54 -0500, J. German Rivera wrote: > APIs to access the Management Complex (MC) hardware > module of Freescale LS2 SoCs. This patch includes > APIs to check the MC firmware version and to manipulate > DPRC objects in the MC. [] > include/linux/fsl_dpmng.h | 120 ++ > include/linux/fsl_dprc.h | 790 > > include/linux/fsl_mc_cmd.h | 182 + > include/linux/fsl_mc_sys.h | 50 +++ Why should any of these files be put in include/linux? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number
On Tue, Aug 19, 2014 at 5:29 PM, Xiao Guangrong wrote: > On 08/19/2014 05:03 PM, Paolo Bonzini wrote: >> Il 19/08/2014 10:50, Xiao Guangrong ha scritto: >>> Okay, what confused me it that it seems that the single line patch >>> is ok to you. :) >> >> No, it was late and I was confused. :) >> >>> Now, do we really need to care the case 2? like David said: >>> "Sorry I didn't explain myself very well: Since we can get a single wrong >>> mmio exit no matter what, it has to be handled in userspace. So my point >>> was, it doesn't really help to fix that one very specific way that it can >>> happen, because it can just happen in other ways. (E.g. update memslots >>> occurs after is_noslot_pfn() and before mmio exit)." >>> >>> What's your idea? >>> I think if you always treat the low bit as zero in mmio sptes, you can do that without losing a bit of the generation. >>> >>> What's you did is avoiding cache a invalid generation number into spte, but >>> actually if we can figure it out when we check mmio access, it's ok. Like >>> the >>> updated patch i posted should fix it, that way avoids doubly increase the >>> number. >> >> Yes. >> >>> Okay, if you're interested increasing the number doubly, there is the >>> simpler >>> one: >> >> This wastes a bit in the mmio spte though. My idea is to increase the >> memslots generation twice, but drop the low bit in the mmio spte. > > Yeah, really smart idea. :) > > Paolo/David, would you mind making a patch for this (+ the comments in David's > patch)? Paolo, since it was your idea would you like to write it? I don't mind either way. > > Please feel free to add my: > Reviewed-by: Xiao Guangrong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
WARNING: CPU: 6 PID: 79 at fs/proc/generic.c:521 remove_proc_entry+0x170/0x180()
Hi, the warning below appeared while booting 3.17.0-rc1. I haven't seen the warning before, but found a recent report on oops.kernel.org: http://oops.kernel.org/oops/warning-at-fs-proc-generic-c521-remove_proc_entry0x18f-0x1a0/ and also reports from July 2014, where the issue was reported to be fixed: https://lkml.org/lkml/2014/7/16/9 https://lkml.org/lkml/2014/7/18/116 And the patch really made it into 3.17.0-rc1, so maybe it's something else this time. Details and .config: http://nerdbynature.de/bits/3.17-rc1/ Thanks, Christian. [ cut here ] WARNING: CPU: 6 PID: 79 at /usr/local/src/linux-git/fs/proc/generic.c:521 remove_proc_entry+0x170/0x180() remove_proc_entry: removing non-empty directory 'fs/nfsfs', leaking at least 'volumes' Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common btusb videodev bluetooth hid_logitech_dj sha256_ssse3 sha256_generic twofish_generic twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common nfs xts lockd sunrpc arc4 coretemp x86_pkg_temp_thermal usbhid intel_powerclamp hid iwldvm kvm_intel mac80211 kvm snd_hda_codec_hdmi i2c_i801 iwlwifi cfg80211 thinkpad_acpi snd_hda_codec_conexant snd_hda_codec_generic nvram hwmon led_class wmi rtc_cmos i915 snd_hda_intel i2c_algo_bit snd_hda_controller drm_kms_helper snd_hda_codec drm snd_hwdep snd_pcm i2ccore snd_timer snd soundcore fuse autofs4 btrfs xor raid6_pq aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd sr_mod cdrom sg ehci_pci ehci_hcd xhci_hcd CPU: 6 PID: 79 Comm: kworker/u16:6 Not tainted 3.17.0-rc1 #1 Hardware name: LENOVO 6277CTO/6277CTO, BIOS HEET42WW (1.23 ) 01/27/2014 Workqueue: netns cleanup_net 0009 8149c1e2 880406c8fd18 8104ee6d 880406701580 880406c8fd68 0005 c0883bae c0883bb1 8104eed7 815b1578 88040030 Call Trace: [] ? dump_stack+0x41/0x51 [] ? warn_slowpath_common+0x6d/0x90 [] ? warn_slowpath_fmt+0x47/0x50 [] ? proc_entry_rundown+0x41/0x80 [] ? remove_proc_entry+0x170/0x180 [] ? nfs_net_exit+0x9/0x20 [nfs] [] ? ops_exit_list.isra.2+0x31/0x60 [] ? cleanup_net+0x100/0x1e0 [] ? process_one_work+0x16b/0x3b0 [] ? worker_thread+0x63/0x490 [] ? rescuer_thread+0x280/0x280 [] ? kthread+0xca/0xe0 [] ? kthread_create_on_node+0x170/0x170 [] ? ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x170/0x170 ---[ end trace c92165dd3f372cf6 ]--- -- BOFH excuse #285: Telecommunications is upgrading. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/4 v2] drivers/bus: Freescale Management Complex (fsl-mc) bus driver
From: "J. German Rivera"
Platform device driver that sets up the basic bus infrastructure
for the fsl-mc bus type, including support for adding/removing
fsl-mc devices, register/unregister of fsl-mc drivers, and bus
match support to bind devices to drivers.
Signed-off-by: J. German Rivera
---
drivers/bus/Kconfig |3 +
drivers/bus/Makefile|3 +
drivers/bus/fsl-mc/Kconfig | 13 +
drivers/bus/fsl-mc/Makefile | 14 +
drivers/bus/fsl-mc/fsl_mc_bus.c | 637 +++
include/linux/fsl_mc.h | 142 +
include/linux/fsl_mc_private.h | 55
7 files changed, 867 insertions(+)
create mode 100644 drivers/bus/fsl-mc/Kconfig
create mode 100644 drivers/bus/fsl-mc/Makefile
create mode 100644 drivers/bus/fsl-mc/fsl_mc_bus.c
create mode 100644 include/linux/fsl_mc.h
create mode 100644 include/linux/fsl_mc_private.h
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 603eb1b..2fbb1fd 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -67,4 +67,7 @@ config VEXPRESS_CONFIG
help
Platform configuration infrastructure for the ARM Ltd.
Versatile Express.
+
+source "drivers/bus/fsl-mc/Kconfig"
+
endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 2973c18..6abcab1 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -15,3 +15,6 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
obj-$(CONFIG_ARM_CCN) += arm-ccn.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
+
+# Freescale Management Complex (MC) bus drivers
+obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/
diff --git a/drivers/bus/fsl-mc/Kconfig b/drivers/bus/fsl-mc/Kconfig
new file mode 100644
index 000..e3226f9
--- /dev/null
+++ b/drivers/bus/fsl-mc/Kconfig
@@ -0,0 +1,13 @@
+#
+# Freescale Management Complex (MC) bus drivers
+#
+# Copyright (C) 2014 Freescale Semiconductor, Inc.
+#
+# This file is released under the GPLv2
+#
+
+config FSL_MC_BUS
+ tristate "Freescale Management Complex (MC) bus driver"
+ help
+ Driver to enable the bus infrastructure for the Freescale
+ QorIQ Management Complex.
diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile
new file mode 100644
index 000..f5f9033
--- /dev/null
+++ b/drivers/bus/fsl-mc/Makefile
@@ -0,0 +1,14 @@
+#
+# Freescale Management Complex (MC) bus drivers
+#
+# Copyright (C) 2014 Freescale Semiconductor, Inc.
+#
+# This file is released under the GPLv2
+#
+obj-$(CONFIG_FSL_MC_BUS) += fsl_mc_bus_driver.o
+
+fsl_mc_bus_driver-objs := fsl_mc_bus.o \
+ mc_sys.o \
+ dprc.o \
+ dpmng.o
+
diff --git a/drivers/bus/fsl-mc/fsl_mc_bus.c b/drivers/bus/fsl-mc/fsl_mc_bus.c
new file mode 100644
index 000..d6ded90
--- /dev/null
+++ b/drivers/bus/fsl-mc/fsl_mc_bus.c
@@ -0,0 +1,637 @@
+/*
+ * Freescale Management Complex (MC) bus driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "fsl_dprc_cmd.h"
+
+static struct kmem_cache *mc_dev_cache;
+
+/**
+ * fsl_mc_bus_match - device to driver matching callback
+ * @dev: the MC object device structure to match against
+ * @drv: the device driver to search for matching MC object device id
+ * structures
+ *
+ * Returns 1 on success, 0 otherwise.
+ */
+static int fsl_mc_bus_match(struct device *dev, struct device_driver *drv)
+{
+ const struct fsl_mc_device_match_id *id;
+ struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
+ struct fsl_mc_driver *mc_drv = to_fsl_mc_driver(drv);
+ bool found = false;
+
+ if (mc_drv->match_id_table == NULL)
+ goto out;
+
+ /*
+* If the object is not 'plugged' don't match.
+* Only exception is the root DPRC, which is a special case.
+*
+* NOTE: The parent bus for the root DPRC
+*/
+ if ((mc_dev->obj_desc.state & DPRC_OBJ_STATE_PLUGGED) == 0 &&
+ dev->bus == _mc_bus_type)
+ goto out;
+
+ /*
+* Traverse the match_id table of the given driver, trying to find
+* a matching for the given MC object device.
+*/
+ for (id = mc_drv->match_id_table; id->vendor != 0x0; id++) {
+ if (id->vendor == mc_dev->obj_desc.vendor &&
+ strcmp(id->obj_type, mc_dev->obj_desc.type) == 0 &&
+ id->ver_major == mc_dev->obj_desc.ver_major &&
+ id->ver_minor == mc_dev->obj_desc.ver_minor) {
+ found = true;
+ break;
+ }
+ }
+
+out:
+
[RFC PATCH 1/4 v2] drivers/bus: Added Freescale Management Complex APIs
From: "J. German Rivera"
APIs to access the Management Complex (MC) hardware
module of Freescale LS2 SoCs. This patch includes
APIs to check the MC firmware version and to manipulate
DPRC objects in the MC.
Signed-off-by: J. German Rivera
---
drivers/bus/fsl-mc/dpmng.c | 93 +
drivers/bus/fsl-mc/dprc.c | 504 +++
drivers/bus/fsl-mc/fsl_dpmng_cmd.h | 83
drivers/bus/fsl-mc/fsl_dprc_cmd.h | 545 +
drivers/bus/fsl-mc/mc_sys.c| 207 ++
include/linux/fsl_dpmng.h | 120 ++
include/linux/fsl_dprc.h | 790
include/linux/fsl_mc_cmd.h | 182 +
include/linux/fsl_mc_sys.h | 50 +++
9 files changed, 2574 insertions(+)
create mode 100644 drivers/bus/fsl-mc/dpmng.c
create mode 100644 drivers/bus/fsl-mc/dprc.c
create mode 100644 drivers/bus/fsl-mc/fsl_dpmng_cmd.h
create mode 100644 drivers/bus/fsl-mc/fsl_dprc_cmd.h
create mode 100644 drivers/bus/fsl-mc/mc_sys.c
create mode 100644 include/linux/fsl_dpmng.h
create mode 100644 include/linux/fsl_dprc.h
create mode 100644 include/linux/fsl_mc_cmd.h
create mode 100644 include/linux/fsl_mc_sys.h
diff --git a/drivers/bus/fsl-mc/dpmng.c b/drivers/bus/fsl-mc/dpmng.c
new file mode 100644
index 000..c6ed27c
--- /dev/null
+++ b/drivers/bus/fsl-mc/dpmng.c
@@ -0,0 +1,93 @@
+/* Copyright 2013-2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+#include "fsl_dpmng_cmd.h"
+
+int mc_get_version(struct fsl_mc_io *mc_io, struct mc_version *mc_ver_info)
+{
+ struct mc_command cmd = { 0 };
+ int err;
+
+ cmd.header = mc_encode_cmd_header(DPMNG_CMDID_GET_VERSION,
+ DPMNG_CMDSZ_GET_VERSION,
+ MC_CMD_PRI_LOW, 0);
+
+ err = mc_send_command(mc_io, );
+ if (!err)
+ DPMNG_RSP_GET_VERSION(cmd, mc_ver_info);
+
+ return err;
+}
+
+int dpmng_reset_aiop(struct fsl_mc_io *mc_io, int aiop_tile_id)
+{
+ struct mc_command cmd = { 0 };
+
+ cmd.header = mc_encode_cmd_header(DPMNG_CMDID_RESET_AIOP,
+ DPMNG_CMDSZ_RESET_AIOP,
+ MC_CMD_PRI_LOW, 0);
+
+ DPMNG_CMD_RESET_AIOP(cmd, aiop_tile_id);
+
+ return mc_send_command(mc_io, );
+}
+
+int dpmng_load_aiop(struct fsl_mc_io *mc_io,
+ int aiop_tile_id, uint8_t *img_addr, int img_size)
+{
+ struct mc_command cmd = { 0 };
+ uint64_t img_paddr = virt_to_phys(img_addr);
+
+ cmd.header = mc_encode_cmd_header(DPMNG_CMDID_LOAD_AIOP,
+ DPMNG_CMDSZ_LOAD_AIOP,
+ MC_CMD_PRI_LOW, 0);
+
+ DPMNG_CMD_LOAD_AIOP(cmd, aiop_tile_id, img_size, img_paddr);
+
+ return mc_send_command(mc_io, );
+}
+
+int dpmng_run_aiop(struct fsl_mc_io *mc_io,
+ int aiop_tile_id, uint32_t cores_mask, uint64_t options)
+{
+ struct mc_command cmd = { 0 };
+
+ cmd.header = mc_encode_cmd_header(DPMNG_CMDID_RUN_AIOP,
+
[RFC PATCH 4/4 v2] Update MAINTAINERS file
From: "J. German Rivera" Signed-off-by: J. German Rivera --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7e2eb4c..eb8597d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3841,6 +3841,14 @@ S: Maintained F: sound/soc/fsl/fsl* F: sound/soc/fsl/mpc8610_hpcd.c +FREESCALE QORIQ MANAGEMENT COMPLEX DRIVER +M: J. German Rivera +L: linux-kernel@vger.kernel.org +S: Maintained +F: include/linux/fsl_mc* +F: include/linux/fsl_dp* +F: drivers/bus/fsl-mc/* + FREEVXFS FILESYSTEM M: Christoph Hellwig W: ftp://ftp.openlinux.org/pub/people/hch/vxfs -- 1.7.9.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 3/4 v2] drivers/bus: Device driver for FSL-MC DPRC devices
From: "J. German Rivera"
A DPRC (Data Path Resource Container) is an isolation device
that contains a set of DPAA networking devices to be
assigned to an isolation domain (e.g., a virtual machine).
Signed-off-by: J. German Rivera
---
drivers/bus/fsl-mc/Makefile |3 +-
drivers/bus/fsl-mc/fsl_mc_dprc.c | 396 ++
include/linux/fsl_mc_private.h |6 +
3 files changed, 404 insertions(+), 1 deletion(-)
create mode 100644 drivers/bus/fsl-mc/fsl_mc_dprc.c
diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile
index f5f9033..4991999 100644
--- a/drivers/bus/fsl-mc/Makefile
+++ b/drivers/bus/fsl-mc/Makefile
@@ -5,7 +5,8 @@
#
# This file is released under the GPLv2
#
-obj-$(CONFIG_FSL_MC_BUS) += fsl_mc_bus_driver.o
+obj-$(CONFIG_FSL_MC_BUS) += fsl_mc_bus_driver.o \
+ fsl_mc_dprc.o
fsl_mc_bus_driver-objs := fsl_mc_bus.o \
mc_sys.o \
diff --git a/drivers/bus/fsl-mc/fsl_mc_dprc.c b/drivers/bus/fsl-mc/fsl_mc_dprc.c
new file mode 100644
index 000..5aaf3e6
--- /dev/null
+++ b/drivers/bus/fsl-mc/fsl_mc_dprc.c
@@ -0,0 +1,396 @@
+/*
+ * Freescale daata path resource container (DPRC) driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include "fsl_dprc_cmd.h"
+
+/**
+ * dprc_remove_all_devices - Does a bus remove for all objects of a DPRC
+ *
+ * @mc_bus: pointer to the logical bus that represents the DPRC
+ *
+ * Removes all devices from the logical bus (not from the physical MC)
+ */
+static void dprc_remove_all_devices(struct fsl_mc_bus *mc_bus)
+{
+ struct fsl_mc_device *mc_dev;
+ struct fsl_mc_device *next;
+
+ list_for_each_entry_safe(mc_dev, next, _bus->child_list,
+dev_node) {
+ WARN_ON(mc_dev->dev.parent != _bus->self->dev);
+ fsl_mc_device_remove(mc_dev);
+ }
+}
+
+/**
+ * dprc_remove_devices - Removes devices for objects removed from a DPRC
+ *
+ * @mc_bus: pointer to the logical bus that corresponds to the DPRC
+ * @obj_desc_array: array of object descriptors for child objects currently
+ * present in the DPRC in the MC.
+ * @num_child_objects_in_mc: number of entries in obj_desc_array
+ *
+ * Synchronizes the state of the Linux bus driver with the actual state of
+ * the MC by removing devices that represent MC objects that have
+ * been dynamically removed in the physical DPRC.
+ */
+static void dprc_remove_devices(struct fsl_mc_bus *mc_bus,
+ struct dprc_obj_desc *obj_desc_array,
+ int num_child_objects_in_mc)
+{
+ if (num_child_objects_in_mc != 0) {
+ /*
+* Remove child objects that are in the DPRC in Linux,
+* but not in the MC:
+*/
+ int i;
+ struct fsl_mc_device *child_obj;
+ struct fsl_mc_device *next;
+
+ list_for_each_entry_safe(child_obj, next,
+_bus->child_list, dev_node) {
+ for (i = 0; i < num_child_objects_in_mc; i++) {
+ if (strlen(obj_desc_array[i].type) != 0 &&
+ FSL_MC_DEVICE_MATCH(child_obj,
+ _desc_array[i]))
+ break;
+ }
+
+ if (i == num_child_objects_in_mc)
+ fsl_mc_device_remove(child_obj);
+ }
+ } else {
+ /*
+* There are no child objects for this DPRC in the MC.
+* So, remove all the child objects from Linux:
+*/
+ dprc_remove_all_devices(mc_bus);
+ }
+}
+
+/**
+ * dprc_add_new_devices - Adds devices to the logical bus for a DPRC
+ *
+ * @mc_bus: pointer to the logical bus that corresponds to the DPRC
+ * @obj_desc_array: array of device descriptors for child devices currently
+ * present in the physical DPRC.
+ * @num_child_objects_in_mc: number of entries in obj_desc_array
+ *
+ * Synchronizes the state of the Linux bus driver with the actual
+ * state of the MC by adding objects that have been newly discovered
+ * in the physical DPRC.
+ */
+static void dprc_add_new_devices(struct fsl_mc_bus *mc_bus,
+struct dprc_obj_desc *obj_desc_array,
+int num_child_objects_in_mc)
+{
+ int error;
+ int i;
+ struct fsl_mc_device *mc_bus_dev = mc_bus->self;
+
+ for (i = 0; i < num_child_objects_in_mc; i++) {
+ struct dprc_region_desc
[RFC PATCH 0/4 v2] drivers/bus: Freescale Management Complex bus driver patch series
This patch series introduces Linux support for the Freescale Management Complex (fsl-mc) hardware. The fsl-mc is a hardware resource manager that manages specialized hardware objects used in network-oriented packet processing applications. After the fsl-mc block is enabled, pools of hardware resources are available, such as queues, buffer poools, I/O interfaces. These resources are building blocks that can be used to create functional hardware objects such as network interfaces, crypto accelerator instances, or L2 switches. All the fsl-mc managed hardware resources/objects are represented in a physical grouping mechanism called a 'container' or DPRC (data path resource container). >From the point of view of an OS, a DPRC functions similar to a plug and play bus. Using fsl-mc commands software can enumerate the contents of the DPRC discovering the hardware objects present and binding them to drivers. Hardware objects can be created and removed dynamically, providing hot pluggability of the hardware objects. Software contexts interact with the fsl-mc by sending commands through a memory mapped hardware interface called an "MC portal". Every fsl-mc object type has a command set to manage the objects. Key DPRC commands include: -create/destroy a DPRC -enumerate objects and resource pools in the DPRC, including identifying mappable regions and the number of IRQs an object may have -IRQ configuration -move objects/resources between DPRCs -connecting objects (e.g. connecting a network interface to an L2 switch port) -reset Patch 1 contains a minimal set of low level functions to send an d receive commands to the fsl-mc. It includes support for basic management commands and commands to manipulate DPRC objects. Patch 2 contains a platform device driver that sets up and registers the basic bus infrastructure including support for adding/removing devices, register/unregister of drivers, and bus match support to bind devices to drivers. Patch 3 contains an driver that manages DPRC objects (the container that holds the hardware resources). This driver functions as a bus controller and handles enumeration of the objects in the container and hotplug events. Patch 4 contains the update to the MAINTAINERS file. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 03/11] arm64: Support restart through restart handler call chain
The kernel core now supports a restart handler call chain to restart the system. Call it if arm_pm_restart is not set. Signed-off-by: Guenter Roeck Acked-by: Catalin Marinas Acked-by: Heiko Stuebner --- v7: No change. v6: No change. v5: Renamed restart function to do_kernel_restart v4: No change. v3: Use wrapper function to execute notifier call chain. v2: Only call notifier call chain if arm_pm_restart is not set. Do not include linux/watchdog.h. arch/arm64/kernel/process.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c index 1309d64..0d3fb9f 100644 --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -180,6 +180,8 @@ void machine_restart(char *cmd) /* Now call the architecture specific reboot code. */ if (arm_pm_restart) arm_pm_restart(reboot_mode, cmd); + else + do_kernel_restart(cmd); /* * Whoops - the architecture was unable to reboot. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 05/11] watchdog: moxart: Register restart handler with kernel restart handler
The kernel now provides an API to trigger a system restart.
Register with it instead of setting arm_pm_restart.
Signed-off-by: Guenter Roeck
Acked-by: Catalin Marinas
Acked-by: Heiko Stuebner
---
v7: No change.
v6: No change.
v5: Functions and variables renamed: *notifier -> *handler
v4: Set notifier priority to 128.
v3: Move struct notifier_block into struct moxart_wdt_dev.
Drop static variable previously needed to access struct moxart_wdt_dev
from notifier function; use container_of instead.
v2: No change.
drivers/watchdog/moxart_wdt.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
index 4aa3a8a..a64405b 100644
--- a/drivers/watchdog/moxart_wdt.c
+++ b/drivers/watchdog/moxart_wdt.c
@@ -15,12 +15,12 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
-#include
-
#define REG_COUNT 0x4
#define REG_MODE 0x8
#define REG_ENABLE 0xC
@@ -29,17 +29,22 @@ struct moxart_wdt_dev {
struct watchdog_device dev;
void __iomem *base;
unsigned int clock_frequency;
+ struct notifier_block restart_handler;
};
-static struct moxart_wdt_dev *moxart_restart_ctx;
-
static int heartbeat;
-static void moxart_wdt_restart(enum reboot_mode reboot_mode, const char *cmd)
+static int moxart_restart_handle(struct notifier_block *this,
+unsigned long mode, void *cmd)
{
- writel(1, moxart_restart_ctx->base + REG_COUNT);
- writel(0x5ab9, moxart_restart_ctx->base + REG_MODE);
- writel(0x03, moxart_restart_ctx->base + REG_ENABLE);
+ struct moxart_wdt_dev *moxart_wdt = container_of(this,
+struct moxart_wdt_dev,
+restart_handler);
+ writel(1, moxart_wdt->base + REG_COUNT);
+ writel(0x5ab9, moxart_wdt->base + REG_MODE);
+ writel(0x03, moxart_wdt->base + REG_ENABLE);
+
+ return NOTIFY_DONE;
}
static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
@@ -136,8 +141,12 @@ static int moxart_wdt_probe(struct platform_device *pdev)
if (err)
return err;
- moxart_restart_ctx = moxart_wdt;
- arm_pm_restart = moxart_wdt_restart;
+ moxart_wdt->restart_handler.notifier_call = moxart_restart_handle;
+ moxart_wdt->restart_handler.priority = 128;
+ err = register_restart_handler(_wdt->restart_handler);
+ if (err)
+ dev_err(dev, "cannot register restart notifier (err=%d)\n",
+ err);
dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
moxart_wdt->dev.timeout, nowayout);
@@ -149,9 +158,8 @@ static int moxart_wdt_remove(struct platform_device *pdev)
{
struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
- arm_pm_restart = NULL;
+ unregister_restart_handler(_wdt->restart_handler);
moxart_wdt_stop(_wdt->dev);
- watchdog_unregister_device(_wdt->dev);
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 08/11] arm/arm64: Unexport restart handlers
Implementing a restart handler in a module don't make sense as there would be no guarantee that the module is loaded when a restart is needed. Unexport arm_pm_restart to ensure that no one gets the idea to do it anyway. Signed-off-by: Guenter Roeck Acked-by: Catalin Marinas Acked-by: Heiko Stuebner --- v7: No change v6: No change v5: No change v4: No change v3: No change v2: No change arch/arm/kernel/process.c | 1 - arch/arm64/kernel/process.c | 1 - 2 files changed, 2 deletions(-) diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c index ea279f7..250b6f6 100644 --- a/arch/arm/kernel/process.c +++ b/arch/arm/kernel/process.c @@ -121,7 +121,6 @@ void (*pm_power_off)(void); EXPORT_SYMBOL(pm_power_off); void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd); -EXPORT_SYMBOL_GPL(arm_pm_restart); /* * This is our default idle handler. diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c index 0d3fb9f..398ab05 100644 --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -98,7 +98,6 @@ void (*pm_power_off)(void); EXPORT_SYMBOL_GPL(pm_power_off); void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd); -EXPORT_SYMBOL_GPL(arm_pm_restart); /* * This is our default idle handler. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 06/11] watchdog: alim7101: Register restart handler with kernel restart handler
The kernel core now provides an API to trigger a system restart.
Register with it to restart the system instead of misusing the
reboot notifier.
Signed-off-by: Guenter Roeck
Acked-by: Catalin Marinas
Acked-by: Heiko Stuebner
---
v7: No change.
v6: No change.
v5: Function and variable renames: *notifier -> *handler.
v4: Set restart notifier priority to 128.
v3: No change.
v2: No change.
drivers/watchdog/alim7101_wdt.c | 42 +++--
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/alim7101_wdt.c b/drivers/watchdog/alim7101_wdt.c
index 996b2f7..665e0e7 100644
--- a/drivers/watchdog/alim7101_wdt.c
+++ b/drivers/watchdog/alim7101_wdt.c
@@ -301,6 +301,28 @@ static struct miscdevice wdt_miscdev = {
.fops = _fops,
};
+static int wdt_restart_handle(struct notifier_block *this, unsigned long mode,
+ void *cmd)
+{
+ /*
+* Cobalt devices have no way of rebooting themselves other
+* than getting the watchdog to pull reset, so we restart the
+* watchdog on reboot with no heartbeat.
+*/
+ wdt_change(WDT_ENABLE);
+
+ /* loop until the watchdog fires */
+ while (true)
+ ;
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block wdt_restart_handler = {
+ .notifier_call = wdt_restart_handle,
+ .priority = 128,
+};
+
/*
* Notifier for system down
*/
@@ -311,15 +333,6 @@ static int wdt_notify_sys(struct notifier_block *this,
if (code == SYS_DOWN || code == SYS_HALT)
wdt_turnoff();
- if (code == SYS_RESTART) {
- /*
-* Cobalt devices have no way of rebooting themselves other
-* than getting the watchdog to pull reset, so we restart the
-* watchdog on reboot with no heartbeat
-*/
- wdt_change(WDT_ENABLE);
- pr_info("Watchdog timer is now enabled with no heartbeat -
should reboot in ~1 second\n");
- }
return NOTIFY_DONE;
}
@@ -338,6 +351,7 @@ static void __exit alim7101_wdt_unload(void)
/* Deregister */
misc_deregister(_miscdev);
unregister_reboot_notifier(_notifier);
+ unregister_restart_handler(_restart_handler);
pci_dev_put(alim7101_pmu);
}
@@ -390,11 +404,17 @@ static int __init alim7101_wdt_init(void)
goto err_out;
}
+ rc = register_restart_handler(_restart_handler);
+ if (rc) {
+ pr_err("cannot register restart handler (err=%d)\n", rc);
+ goto err_out_reboot;
+ }
+
rc = misc_register(_miscdev);
if (rc) {
pr_err("cannot register miscdev on minor=%d (err=%d)\n",
wdt_miscdev.minor, rc);
- goto err_out_reboot;
+ goto err_out_restart;
}
if (nowayout)
@@ -404,6 +424,8 @@ static int __init alim7101_wdt_init(void)
timeout, nowayout);
return 0;
+err_out_restart:
+ unregister_restart_handler(_restart_handler);
err_out_reboot:
unregister_reboot_notifier(_notifier);
err_out:
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] USB: pch_udc: USB gadget device support for Intel Quark X1000
> Hi, > > On Mon, Aug 04, 2014 at 10:22:54AM -0700, Chen, Alvin wrote: > > From: Bryan O'Donoghue > > > > This patch is to enable the USB gadget device for Intel Quark X1000 > > > > Signed-off-by: Bryan O'Donoghue > > Signed-off-by: Bing Niu > > Signed-off-by: Alvin (Weike) Chen > > Can someone confirm to me this is not another incarnation of chipidea ? No, this is not another incarnation of chipidea. And its cover letter is as following: On Mon, Aug 04, 2014 at 11:00:07AM -0700, Chen, Alvin wrote: > From: "Alvin (Weike) Chen" > > Hi, > Intel Quark X1000 consists of one USB gadget device which can be PCI > enumerated. > pch_udc layer doesn't support it. Thus, we add support for Intel Quark > X1000 USB gadget device as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 07/11] watchdog: sunxi: Register restart handler with kernel restart handler
The kernel core now provides an API to trigger a system restart.
Register with it instead of setting arm_pm_restart.
Signed-off-by: Guenter Roeck
Acked-by: Heiko Stuebner
---
v7: Added patch to series. Necessary since the restart handler in the driver
is now available upstream.
drivers/watchdog/sunxi_wdt.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/watchdog/sunxi_wdt.c b/drivers/watchdog/sunxi_wdt.c
index 60deb9d..480bb55 100644
--- a/drivers/watchdog/sunxi_wdt.c
+++ b/drivers/watchdog/sunxi_wdt.c
@@ -21,14 +21,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
-
#define WDT_MAX_TIMEOUT 16
#define WDT_MIN_TIMEOUT 1
#define WDT_MODE_TIMEOUT(n) ((n) << 3)
@@ -50,6 +49,7 @@ static unsigned int timeout = WDT_MAX_TIMEOUT;
struct sunxi_wdt_dev {
struct watchdog_device wdt_dev;
void __iomem *wdt_base;
+ struct notifier_block restart_handler;
};
/*
@@ -74,24 +74,29 @@ static const int wdt_timeout_map[] = {
[16] = 0xB, /* 16s */
};
-static void __iomem *reboot_wdt_base;
-static void sun4i_wdt_restart(enum reboot_mode mode, const char *cmd)
+static int sunxi_restart_handle(struct notifier_block *this, unsigned long
mode,
+ void *cmd)
{
+ struct sunxi_wdt_dev *sunxi_wdt = container_of(this,
+ struct sunxi_wdt_dev,
+ restart_handler);
+ void __iomem *wdt_base = sunxi_wdt->wdt_base;
+
/* Enable timer and set reset bit in the watchdog */
- writel(WDT_MODE_EN | WDT_MODE_RST_EN, reboot_wdt_base + WDT_MODE);
+ writel(WDT_MODE_EN | WDT_MODE_RST_EN, wdt_base + WDT_MODE);
/*
* Restart the watchdog. The default (and lowest) interval
* value for the watchdog is 0.5s.
*/
- writel(WDT_CTRL_RELOAD, reboot_wdt_base + WDT_CTRL);
+ writel(WDT_CTRL_RELOAD, wdt_base + WDT_CTRL);
while (1) {
mdelay(5);
- writel(WDT_MODE_EN | WDT_MODE_RST_EN,
- reboot_wdt_base + WDT_MODE);
+ writel(WDT_MODE_EN | WDT_MODE_RST_EN, wdt_base + WDT_MODE);
}
+ return NOTIFY_DONE;
}
static int sunxi_wdt_ping(struct watchdog_device *wdt_dev)
@@ -205,8 +210,12 @@ static int sunxi_wdt_probe(struct platform_device *pdev)
if (unlikely(err))
return err;
- reboot_wdt_base = sunxi_wdt->wdt_base;
- arm_pm_restart = sun4i_wdt_restart;
+ sunxi_wdt->restart_handler.notifier_call = sunxi_restart_handle;
+ sunxi_wdt->restart_handler.priority = 128;
+ err = register_restart_handler(_wdt->restart_handler);
+ if (err)
+ dev_err(>dev,
+ "cannot register restart handler (err=%d)\n", err);
dev_info(>dev, "Watchdog enabled (timeout=%d sec, nowayout=%d)",
sunxi_wdt->wdt_dev.timeout, nowayout);
@@ -218,7 +227,7 @@ static int sunxi_wdt_remove(struct platform_device *pdev)
{
struct sunxi_wdt_dev *sunxi_wdt = platform_get_drvdata(pdev);
- arm_pm_restart = NULL;
+ unregister_restart_handler(_wdt->restart_handler);
watchdog_unregister_device(_wdt->wdt_dev);
watchdog_set_drvdata(_wdt->wdt_dev, NULL);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 11/11] clk: rockchip: add restart handler
From: Heiko Stübner
Add infrastructure to write the correct value to the restart register and
register the restart notifier for both rk3188 (including rk3066) and rk3288.
Signed-off-by: Heiko Stuebner
Signed-off-by: Guenter Roeck
---
v7: Added patch to series.
drivers/clk/rockchip/clk-rk3188.c | 2 ++
drivers/clk/rockchip/clk-rk3288.c | 2 ++
drivers/clk/rockchip/clk.c| 25 +
drivers/clk/rockchip/clk.h| 1 +
4 files changed, 30 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3188.c
b/drivers/clk/rockchip/clk-rk3188.c
index a83a6d8..71b661a 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -631,6 +631,8 @@ static void __init rk3188_common_clk_init(struct
device_node *np)
rockchip_register_softrst(np, 9, reg_base + RK2928_SOFTRST_CON(0),
ROCKCHIP_SOFTRST_HIWORD_MASK);
+
+ rockchip_register_restart_notifier(RK2928_GLB_SRST_FST);
}
static void __init rk3066a_clk_init(struct device_node *np)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 0d8c6c5..b604217 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -713,5 +713,7 @@ static void __init rk3288_clk_init(struct device_node *np)
rockchip_register_softrst(np, 9, reg_base + RK3288_SOFTRST_CON(0),
ROCKCHIP_SOFTRST_HIWORD_MASK);
+
+ rockchip_register_restart_notifier(RK3288_GLB_SRST_FST);
}
CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288-cru", rk3288_clk_init);
diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index 278cf9d..aa41433 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "clk.h"
/**
@@ -242,3 +243,27 @@ void __init rockchip_clk_register_branches(
rockchip_clk_add_lookup(clk, list->id);
}
}
+
+static unsigned int reg_restart;
+static int rockchip_restart_notify(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+ writel(0xfdb9, reg_base + reg_restart);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block rockchip_restart_handler = {
+ .notifier_call = rockchip_restart_notify,
+ .priority = 128,
+};
+
+void __init rockchip_register_restart_notifier(unsigned int reg)
+{
+ int ret;
+
+ reg_restart = reg;
+ ret = register_restart_handler(_restart_handler);
+ if (ret)
+ pr_err("%s: cannot register restart handler, %d\n",
+ __func__, ret);
+}
diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
index 887cbde..0b5eab5 100644
--- a/drivers/clk/rockchip/clk.h
+++ b/drivers/clk/rockchip/clk.h
@@ -329,6 +329,7 @@ void rockchip_clk_register_branches(struct
rockchip_clk_branch *clk_list,
unsigned int nr_clk);
void rockchip_clk_register_plls(struct rockchip_pll_clock *pll_list,
unsigned int nr_pll, int grf_lock_offset);
+void rockchip_register_restart_notifier(unsigned int reg);
#define ROCKCHIP_SOFTRST_HIWORD_MASK BIT(0)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 09/11] watchdog: s3c2410: add restart handler
From: Heiko Stübner
On a lot of Samsung systems the watchdog is responsible for restarting the
system and until now this code was contained in plat-samsung/watchdog-reset.c.
With the introduction of the restart handlers, this code can now move into
driver itself, removing the need for arch-specific code.
Tested on a S3C2442 based GTA02
Signed-off-by: Heiko Stuebner
Signed-off-by: Guenter Roeck
---
v7: Added patch to series.
drivers/watchdog/s3c2410_wdt.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7c6ccd0..2955aef 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -41,6 +41,8 @@
#include
#include
#include
+#include
+#include
#define S3C2410_WTCON 0x00
#define S3C2410_WTDAT 0x04
@@ -128,6 +130,7 @@ struct s3c2410_wdt {
unsigned long wtdat_save;
struct watchdog_device wdt_device;
struct notifier_block freq_transition;
+ struct notifier_block restart_handler;
struct s3c2410_wdt_variant *drv_data;
struct regmap *pmureg;
};
@@ -438,6 +441,31 @@ static inline void s3c2410wdt_cpufreq_deregister(struct
s3c2410_wdt *wdt)
}
#endif
+static int s3c2410wdt_restart(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+ struct s3c2410_wdt *wdt = container_of(this, struct s3c2410_wdt,
+ restart_handler);
+ void __iomem *wdt_base = wdt->reg_base;
+
+ /* disable watchdog, to be safe */
+ writel(0, wdt_base + S3C2410_WTCON);
+
+ /* put initial values into count and data */
+ writel(0x80, wdt_base + S3C2410_WTCNT);
+ writel(0x80, wdt_base + S3C2410_WTDAT);
+
+ /* set the watchdog to go and reset... */
+ writel(S3C2410_WTCON_ENABLE | S3C2410_WTCON_DIV16 |
+ S3C2410_WTCON_RSTEN | S3C2410_WTCON_PRESCALE(0x20),
+ wdt_base + S3C2410_WTCON);
+
+ /* wait for reset to assert... */
+ mdelay(500);
+
+ return NOTIFY_DONE;
+}
+
static inline unsigned int s3c2410wdt_get_bootstatus(struct s3c2410_wdt *wdt)
{
unsigned int rst_stat;
@@ -592,6 +620,12 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, wdt);
+ wdt->restart_handler.notifier_call = s3c2410wdt_restart;
+ wdt->restart_handler.priority = 128;
+ ret = register_restart_handler(>restart_handler);
+ if (ret)
+ pr_err("cannot register restart handler, %d\n", ret);
+
/* print out a statement of readiness */
wtcon = readl(wdt->reg_base + S3C2410_WTCON);
@@ -621,6 +655,8 @@ static int s3c2410wdt_remove(struct platform_device *dev)
int ret;
struct s3c2410_wdt *wdt = platform_get_drvdata(dev);
+ unregister_restart_handler(>restart_handler);
+
ret = s3c2410wdt_mask_and_disable_reset(wdt, true);
if (ret < 0)
return ret;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 10/11] clk: samsung: register restart handlers for s3c2412 and s3c2443
From: Heiko Stübner
S3C2412, S3C2443 and their derivatives contain a special software-reset
register in their system-controller.
Therefore register a restart handler for those.
Tested on a s3c2416-based board, s3c2412 compile-tested.
Signed-off-by: Heiko Stuebner
Signed-off-by: Guenter Roeck
---
v7: Added patch to series.
drivers/clk/samsung/clk-s3c2412.c | 29 +
drivers/clk/samsung/clk-s3c2443.c | 19 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/clk/samsung/clk-s3c2412.c
b/drivers/clk/samsung/clk-s3c2412.c
index 34af09f..2ceedaf 100644
--- a/drivers/clk/samsung/clk-s3c2412.c
+++ b/drivers/clk/samsung/clk-s3c2412.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
@@ -26,6 +27,7 @@
#define CLKCON 0x0c
#define CLKDIVN0x14
#define CLKSRC 0x1c
+#define SWRST 0x30
/* list of PLLs to be registered */
enum s3c2412_plls {
@@ -204,6 +206,28 @@ struct samsung_clock_alias s3c2412_aliases[] __initdata = {
ALIAS(MSYSCLK, NULL, "fclk"),
};
+static int s3c2412_restart(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+ /* errata "Watch-dog/Software Reset Problem" specifies that
+* this reset must be done with the SYSCLK sourced from
+* EXTCLK instead of FOUT to avoid a glitch in the reset
+* mechanism.
+*
+* See the watchdog section of the S3C2412 manual for more
+* information on this fix.
+*/
+
+ __raw_writel(0x00, reg_base + CLKSRC);
+ __raw_writel(0x533C2412, reg_base + SWRST);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block s3c2412_restart_handler = {
+ .notifier_call = s3c2412_restart,
+ .priority = 129,
+};
+
/*
* fixed rate clocks generated outside the soc
* Only necessary until the devicetree-move is complete
@@ -233,6 +257,7 @@ void __init s3c2412_common_clk_init(struct device_node *np,
unsigned long xti_f,
unsigned long ext_f, void __iomem *base)
{
struct samsung_clk_provider *ctx;
+ int ret;
reg_base = base;
if (np) {
@@ -267,6 +292,10 @@ void __init s3c2412_common_clk_init(struct device_node
*np, unsigned long xti_f,
s3c2412_clk_sleep_init();
samsung_clk_of_add_provider(np, ctx);
+
+ ret = register_restart_handler(_restart_handler);
+ if (ret)
+ pr_warn("cannot register restart handler, %d\n", ret);
}
static void __init s3c2412_clk_init(struct device_node *np)
diff --git a/drivers/clk/samsung/clk-s3c2443.c
b/drivers/clk/samsung/clk-s3c2443.c
index c92f853..0c3c182 100644
--- a/drivers/clk/samsung/clk-s3c2443.c
+++ b/drivers/clk/samsung/clk-s3c2443.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
@@ -33,6 +34,7 @@
#define HCLKCON0x30
#define PCLKCON0x34
#define SCLKCON0x38
+#define SWRST 0x44
/* the soc types */
enum supported_socs {
@@ -354,6 +356,18 @@ struct samsung_clock_alias s3c2450_aliases[] __initdata = {
ALIAS(PCLK_I2C1, "s3c2410-i2c.1", "i2c"),
};
+static int s3c2443_restart(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+ __raw_writel(0x533c2443, reg_base + SWRST);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block s3c2443_restart_handler = {
+ .notifier_call = s3c2443_restart,
+ .priority = 129,
+};
+
/*
* fixed rate clocks generated outside the soc
* Only necessary until the devicetree-move is complete
@@ -378,6 +392,7 @@ void __init s3c2443_common_clk_init(struct device_node *np,
unsigned long xti_f,
void __iomem *base)
{
struct samsung_clk_provider *ctx;
+ int ret;
reg_base = base;
if (np) {
@@ -447,6 +462,10 @@ void __init s3c2443_common_clk_init(struct device_node
*np, unsigned long xti_f,
s3c2443_clk_sleep_init();
samsung_clk_of_add_provider(np, ctx);
+
+ ret = register_restart_handler(_restart_handler);
+ if (ret)
+ pr_warn("cannot register restart handler, %d\n", ret);
}
static void __init s3c2416_clk_init(struct device_node *np)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Revert "aio: fix aio request leak when events are reaped by user space"
On Tue, Aug 19, 2014 at 08:14:26PM +0300, Dan Aloni wrote:
> On Tue, Aug 19, 2014 at 12:54:04PM -0400, Benjamin LaHaise wrote:
> > On Tue, Aug 19, 2014 at 07:37:33PM +0300, Dan Aloni wrote:
> > > Some testing I've done today indicates that the original commit broke
> > > AIO with regard to users that overflow the maximum number of request
> > > per IO context (where -EAGAIN is returned).
> > >
> > > In fact, it did worse - the attached C program can easily overrun the
> > > ring buffer that is responsible for managing the completed requests,
> > > and caused notification about their completion never to be returned.
> >
> > Argh, that would be a problem.
> >
> > ...
> > > This reverts commit b34e0e1319b31202eb142dcd9688cf7145a30bf6.
> >
> > Reverting isn't okay, as that reintroduces another regression. We need
> > to come up with a fix for this issue that doesn't reintroduce the other
> > regression for events reaped in user space. Let me have a look and see
> > what I can come up with...
>
> About the original regression you mention, is there a program you can
> indicate that reproduces it? On my setups, the regression testing in
> libaio was not able to detect the current regression too.
You can trigger the behaviour with fio by using userspace event reaping.
Adding a test case for that behaviour to libaio would be a good idea.
I thought about how to fix this, and it isn't actually that hard. Move
the put_reqs_available() call back into event consumption, and then add
code in the submit path to call put_reqs_available() if the system runs
out of events by noticing that there is free space in the event ring.
Something along the lines below should do it (please note, this is
completely untested!). I'll test and polish this off tomorrow, as it's
getting a bit late here.
-ben
--
"Thought is the essence of where you are now."
diff --git a/fs/aio.c b/fs/aio.c
index ae63587..749ac22 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -142,6 +142,7 @@ struct kioctx {
struct {
unsignedtail;
spinlock_t completion_lock;
+ unsignedcompleted_events;
} cacheline_aligned_in_smp;
struct page *internal_pages[AIO_RING_PAGES];
@@ -857,6 +858,31 @@ out:
return ret;
}
+static void refill_reqs_available(struct kioctx *ctx)
+{
+ spin_lock_irq(>completion_lock);
+ if (ctx->completed_events) {
+ unsigned head, tail, avail, completed;
+ struct aio_ring *ring;
+
+ ring = kmap_atomic(ctx->ring_pages[0]);
+ head = ACCESS_ONCE(ring->head);
+ tail = ACCESS_ONCE(ring->tail);
+ kunmap_atomic(ring);
+
+ avail = (head <= tail ? tail : ctx->nr_events) - head;
+ completed = ctx->completed_events;
+ if (avail < completed)
+ completed -= avail;
+ else
+ completed = 0;
+ put_reqs_available(ctx, completed);
+ }
+
+ spin_unlock_irq(>completion_lock);
+}
+
+
/* aio_get_req
* Allocate a slot for an aio request.
* Returns NULL if no requests are free.
@@ -865,8 +891,11 @@ static inline struct kiocb *aio_get_req(struct kioctx *ctx)
{
struct kiocb *req;
- if (!get_reqs_available(ctx))
- return NULL;
+ if (!get_reqs_available(ctx)) {
+ refill_reqs_available(ctx);
+ if (!get_reqs_available(ctx))
+ return NULL;
+ }
req = kmem_cache_alloc(kiocb_cachep, GFP_KERNEL|__GFP_ZERO);
if (unlikely(!req))
@@ -1005,7 +1034,6 @@ void aio_complete(struct kiocb *iocb, long res, long res2)
/* everything turned out well, dispose of the aiocb. */
kiocb_free(iocb);
- put_reqs_available(ctx, 1);
/*
* We have to order our ring_info tail store above and test
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 02/11] power/restart: Call machine_restart instead of arm_pm_restart
machine_restart is supported on non-ARM platforms, and and ultimately calls
arm_pm_restart, so dont call arm_pm_restart directly but use the more
generic function.
Cc: Russell King
Signed-off-by: Guenter Roeck
Acked-by: Catalin Marinas
Acked-by: Heiko Stuebner
---
v7: No change.
v6: No change.
v5: No change.
v4: No change.
v3: No change.
v2: Added patch.
drivers/power/reset/restart-poweroff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/power/reset/restart-poweroff.c
b/drivers/power/reset/restart-poweroff.c
index 3e51f8d..edd707e 100644
--- a/drivers/power/reset/restart-poweroff.c
+++ b/drivers/power/reset/restart-poweroff.c
@@ -20,7 +20,8 @@
static void restart_poweroff_do_poweroff(void)
{
- arm_pm_restart(REBOOT_HARD, NULL);
+ reboot_mode = REBOOT_HARD;
+ machine_restart(NULL);
}
static int restart_poweroff_probe(struct platform_device *pdev)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 01/11] kernel: Add support for kernel restart handler call chain
Various drivers implement architecture and/or device specific means to restart (reset) the system. Various mechanisms have been implemented to support those schemes. The best known mechanism is arm_pm_restart, which is a function pointer to be set either from platform specific code or from drivers. Another mechanism is to use hardware watchdogs to issue a reset; this mechanism is used if there is no other method available to reset a board or system. Two examples are alim7101_wdt, which currently uses the reboot notifier to trigger a reset, and moxart_wdt, which registers the arm_pm_restart function. The existing mechanisms have a number of drawbacks. Typically only one scheme to restart the system is supported (at least if arm_pm_restart is used). At least in theory there can be multiple means to restart the system, some of which may be less desirable (for example one mechanism may only reset the CPU, while another may reset the entire system). Using arm_pm_restart can also be racy if the function pointer is set from a driver, as the driver may be in the process of being unloaded when arm_pm_restart is called. Using the reboot notifier is always racy, as it is unknown if and when other functions using the reboot notifier have completed execution by the time the watchdog fires. Introduce a system restart handler call chain to solve the described problems. This call chain is expected to be executed from the architecture specific machine_restart() function. Drivers providing system restart functionality (such as the watchdog drivers mentioned above) are expected to register with this call chain. By using the priority field in the notifier block, callers can control restart handler execution sequence and thus ensure that the restart handler with the optimal restart capabilities for a given system is called first. Signed-off-by: Guenter Roeck Acked-by: Catalin Marinas Acked-by: Heiko Stuebner --- v7: Rebased to v3.17-rc1 v6: Use atomic notifier call chain v5: Function renames: register_restart_notifier -> register_restart_handler unregister_restart_notifier -> unregister_restart_handler kernel_restart_notify -> do_kernel_restart v4: Document and suggest values for notifier priorities v3: Add kernel_restart_notify wrapper function to execute notifier. Improve documentation. Move restart_notifier_list into kernel/reboot.c and make it static. v2: No change. include/linux/reboot.h | 3 ++ kernel/reboot.c| 81 ++ 2 files changed, 84 insertions(+) diff --git a/include/linux/reboot.h b/include/linux/reboot.h index 48bf152..67fc8fc 100644 --- a/include/linux/reboot.h +++ b/include/linux/reboot.h @@ -38,6 +38,9 @@ extern int reboot_force; extern int register_reboot_notifier(struct notifier_block *); extern int unregister_reboot_notifier(struct notifier_block *); +extern int register_restart_handler(struct notifier_block *); +extern int unregister_restart_handler(struct notifier_block *); +extern void do_kernel_restart(char *cmd); /* * Architecture-specific implementations of sys_reboot commands. diff --git a/kernel/reboot.c b/kernel/reboot.c index a3a9e24..5925f5a 100644 --- a/kernel/reboot.c +++ b/kernel/reboot.c @@ -104,6 +104,87 @@ int unregister_reboot_notifier(struct notifier_block *nb) } EXPORT_SYMBOL(unregister_reboot_notifier); +/* + * Notifier list for kernel code which wants to be called + * to restart the system. + */ +static ATOMIC_NOTIFIER_HEAD(restart_handler_list); + +/** + * register_restart_handler - Register function to be called to reset + *the system + * @nb: Info about handler function to be called + * @nb->priority: Handler priority. Handlers should follow the + * following guidelines for setting priorities. + * 0: Restart handler of last resort, + * with limited restart capabilities + * 128:Default restart handler; use if no other + * restart handler is expected to be available, + * and/or if restart functionality is + * sufficient to restart the entire system + * 255:Highest priority restart handler, will + * preempt all other restart handlers + * + * Registers a function with code to be called to restart the + * system. + * + * Registered functions will be called from machine_restart as last + * step of the restart sequence (if the architecture specific + * machine_restart function calls do_kernel_restart - see below + * for details). + * Registered functions are expected to restart the system immediately. + * If more than one function is registered, the restart handler priority + * selects which function will be called first. + * + * Restart handlers are expected to be
[PATCH v7 04/11] arm: Support restart through restart handler call chain
The kernel core now supports a restart handler call chain for system
restart functions.
With this change, the arm_pm_restart callback is now optional, so
drop its initialization and check if it is set before calling it.
Only call the kernel restart handler if arm_pm_restart is not set.
Signed-off-by: Guenter Roeck
Acked-by: Catalin Marinas
Acked-by: Heiko Stuebner
---
v7: Dropped null_restart and made arm_pm_restart truly optional.
v6: No change.
v5: Renamed restart function to do_kernel_restart
v4: No change.
v3: Use wrapper function to execute notifier call chain.
v2: Only call notifier call chain if arm_pm_restart is not set.
Do not include linux/watchdog.h.
arch/arm/kernel/process.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 81ef686..ea279f7 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -114,17 +114,13 @@ void soft_restart(unsigned long addr)
BUG();
}
-static void null_restart(enum reboot_mode reboot_mode, const char *cmd)
-{
-}
-
/*
* Function pointers to optional machine specific functions
*/
void (*pm_power_off)(void);
EXPORT_SYMBOL(pm_power_off);
-void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd) =
null_restart;
+void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
EXPORT_SYMBOL_GPL(arm_pm_restart);
/*
@@ -230,7 +226,10 @@ void machine_restart(char *cmd)
local_irq_disable();
smp_send_stop();
- arm_pm_restart(reboot_mode, cmd);
+ if (arm_pm_restart)
+ arm_pm_restart(reboot_mode, cmd);
+ else
+ do_kernel_restart(cmd);
/* Give a grace period for failure to restart of 1s */
mdelay(1000);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 00/11] kernel: Add support for restart handler call chain
Various drivers implement architecture and/or device specific means to restart (reset) the system. Various mechanisms have been implemented to support those schemes. The best known mechanism is arm_pm_restart, which is a function pointer to be set either from platform specific code or from drivers. Another mechanism is to use hardware watchdogs to issue a reset; this mechanism is used if there is no other method available to reset a board or system. Two examples are alim7101_wdt, which currently uses the reboot notifier to trigger a reset, and moxart_wdt, which registers the arm_pm_restart function. Several other restart drivers for arm, all directly calling arm_pm_restart, are in the process of being integrated into the kernel. All those drivers would benefit from the new API. The existing mechanisms have a number of drawbacks. Typically only one scheme to restart the system is supported (at least if arm_pm_restart is used). At least in theory there can be multiple means to restart the system, some of which may be less desirable (for example one mechanism may only reset the CPU, while another may reset the entire system). Using arm_pm_restart can also be racy if the function pointer is set from a driver, as the driver may be in the process of being unloaded when arm_pm_restart is called. Using the reboot notifier is always racy, as it is unknown if and when other functions using the reboot notifier have completed execution by the time the watchdog fires. Introduce a system restart handler call chain to solve the described problems. This call chain is expected to be executed from the architecture specific machine_restart() function. Drivers providing system restart functionality (such as the watchdog drivers mentioned above) are expected to register with this call chain. By using the priority field in the notifier block, callers can control restart handler execution sequence and thus ensure that the restart handler with the optimal restart capabilities for a given system is called first. Since the first revision of this patchset, a number of separate patch submissions have been made which either depend on it or could make use of it. http://www.spinics.net/linux/lists/arm-kernel/msg344796.html registers three notifiers. https://lkml.org/lkml/2014/7/8/962 would benefit from it. Patch 1 of this series implements the restart handler function. Patches 2 and 3 implement calling the restart handler chain from arm and arm64 restart code. Patch 4 modifies the restart-poweroff driver to no longer call arm_pm_restart directly but machine_restart. This is done to avoid calling arm_pm_restart from more than one place. The change makes the driver architecture independent, so it would be possible to drop the arm dependency from its Kconfig entry. Patch 5 and 6 convert existing restart handlers in the watchdog subsystem to use the restart handler. Patch 7 unexports arm_pm_restart to ensure that no one gets the idea to implement a restart handler as module. The entire patch series, including additional patches depending on it, is available from https://git.kernel.org/cgit/linux/kernel/git/groeck/linux-staging.git/ in branch 'restart-staging'. --- v7: Rebased to v3.17-rc1 Dropped null_restart from arm code to make arm_pm_restart truly optional Reordered series. power/restart must be patched to not use arm_pm_restart prior to making arm_pm_restart optional. Added all pending patches to series v6: Use atomic notifier call chain Rebased series to v3.16 v5: Rebased series to v3.16-rc5 Function renames: register_restart_notifier -> register_restart_handler unregister_restart_notifier -> unregister_restart_handler kernel_restart_notify -> do_kernel_restart v4: Document restart notifier priorities Select 128 as default priority for newly introduced notifiers Fix checkpatch warning (line too long) in moxart patch v3: Drop RFC. Add kernel_restart_notify wrapper function to execute notifier Improve documentation. Move restart_notifier_list into kernel/reboot.c and make it static. v2: Add patch 4. Only call blocking notifier call chain if arm_pm_restart was not set. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] UBI: block: fix dereference on uninitialized dev
Hi Colin,
Thanks for the fix.
On 16 Aug 05:49 PM, Colin King wrote:
> From: Colin Ian King
>
> commit 4df38926f337 ("UBI: block: Avoid disk size integer overflow")
> introduced a dereference on dev (which is not initialized at that
> point) when printing a warning message. Remove the reference to
> the dev's disk_name.
>
> Found by cppcheck:
> [drivers/mtd/ubi/block.c:509]: (error) Uninitialized variable: dev
>
> Signed-off-by: Colin Ian King
> ---
> drivers/mtd/ubi/block.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
> index 33c6495..944bdbd 100644
> --- a/drivers/mtd/ubi/block.c
> +++ b/drivers/mtd/ubi/block.c
> @@ -505,8 +505,8 @@ static int ubiblock_resize(struct ubi_volume_info *vi)
> u64 disk_capacity = ((u64)vi->size * vi->usable_leb_size) >> 9;
>
> if ((sector_t)disk_capacity != disk_capacity) {
> - ubi_warn("%s: the volume is too big, cannot resize (%d LEBs)",
> - dev->gd->disk_name, vi->size);
> + ubi_warn("block: the volume is too big, cannot resize (%d
> LEBs)",
> + vi->size);
Do you think you can resend this adding the name of the volume to the warning?
> return -EFBIG;
> }
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number
On 08/19/2014 05:03 PM, Paolo Bonzini wrote: > Il 19/08/2014 10:50, Xiao Guangrong ha scritto: >> Okay, what confused me it that it seems that the single line patch >> is ok to you. :) > > No, it was late and I was confused. :) > >> Now, do we really need to care the case 2? like David said: >> "Sorry I didn't explain myself very well: Since we can get a single wrong >> mmio exit no matter what, it has to be handled in userspace. So my point >> was, it doesn't really help to fix that one very specific way that it can >> happen, because it can just happen in other ways. (E.g. update memslots >> occurs after is_noslot_pfn() and before mmio exit)." >> >> What's your idea? >> >>> I think if you always treat the low bit as zero in mmio sptes, you can >>> do that without losing a bit of the generation. >> >> What's you did is avoiding cache a invalid generation number into spte, but >> actually if we can figure it out when we check mmio access, it's ok. Like the >> updated patch i posted should fix it, that way avoids doubly increase the >> number. > > Yes. > >> Okay, if you're interested increasing the number doubly, there is the simpler >> one: > > This wastes a bit in the mmio spte though. My idea is to increase the > memslots generation twice, but drop the low bit in the mmio spte. Yeah, really smart idea. :) Paolo/David, would you mind making a patch for this (+ the comments in David's patch)? Please feel free to add my: Reviewed-by: Xiao Guangrong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] TAINT_PERFORMANCE
On Tue, 19 Aug 2014, Laura Abbott wrote: > I nominate CONFIG_DEBUG_PAGEALLOC, CONFIG_SLUB_DEBUG, > CONFIG_SLUB_DEBUG_ON as well since I've wasted days debugging > supposed performance issues where those were on. CONFIG_SLUB_DEBUG is not enabling debugging. It just includes the code to do so at kernel bootup. Not a performance problem. CONFIG_SLUB_DEBUG_ON is a performance issue since debugging will be on by default. CONFIG_SLAB_DEBUG is also a performance issue since this option makes slab run with debugging. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virt/kvm/assigned-dev.c: Set 'dev->irq_source_id' to '-1' after free it
By the way, at present, I use Qemu as user mode program, is there common test with both Qemu and KVM/Xen? And is a PC enough for the common test? Thanks. On 08/20/2014 07:58 AM, Chen Gang wrote: > On 08/19/2014 11:49 PM, Paolo Bonzini wrote: >> Il 19/08/2014 17:44, Chen Gang ha scritto: Hello maintainers: Please help check this patch, when you have time. >> Hi, it's already on its way to 3.17-rc2, but I first have to run a bunch >> of tests. > > OK, thanks. Also can let me try the test, although I am not quite > familiar with KVM. Since I plan to focus on KVM/Xen next, I shall > construct related environments for its' common test, at least. > > I am just constructing the gcc common test environments under a new PC, > is a PC also enough for KVM/Xen common test? > > Welcome any ideas, suggestions or completions about it (especially the > information about KVM/Xen common test). > > > Thanks. > -- Chen Gang Open share and attitude like air water and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virt/kvm/assigned-dev.c: Set 'dev->irq_source_id' to '-1' after free it
On 08/19/2014 11:49 PM, Paolo Bonzini wrote: > Il 19/08/2014 17:44, Chen Gang ha scritto: >> > Hello maintainers: >> > >> > Please help check this patch, when you have time. > Hi, it's already on its way to 3.17-rc2, but I first have to run a bunch > of tests. OK, thanks. Also can let me try the test, although I am not quite familiar with KVM. Since I plan to focus on KVM/Xen next, I shall construct related environments for its' common test, at least. I am just constructing the gcc common test environments under a new PC, is a PC also enough for KVM/Xen common test? Welcome any ideas, suggestions or completions about it (especially the information about KVM/Xen common test). Thanks. -- Chen Gang Open share and attitude like air water and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3] thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
This patch add support for TRIM_RELOAD feature at Exynos3250. The TMU of
Exynos3250 has two TRIMINFO_CON register.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Cc: Zhang Rui
Cc: Eduardo Valentin
Cc: Amit Daniel Kachhap
---
Changes from v2:
- Fix build break because of missing 'or' operation.
Changes from v1:
- Add missing 'TMU_SUPPORT_TRIM_RELOAD' feature
drivers/thermal/samsung/exynos_tmu.c | 7 +--
drivers/thermal/samsung/exynos_tmu.h | 5 +++--
drivers/thermal/samsung/exynos_tmu_data.c | 11 +--
drivers/thermal/samsung/exynos_tmu_data.h | 7 +--
4 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index acbff14..ed01606 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -164,8 +164,11 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
}
}
- if (TMU_SUPPORTS(pdata, TRIM_RELOAD))
- __raw_writel(1, data->base + reg->triminfo_ctrl);
+ if (TMU_SUPPORTS(pdata, TRIM_RELOAD)) {
+ for (i = 0; i < pdata->triminfo_reload_count; i++)
+ __raw_writel(pdata->triminfo_reload[i],
+ data->base + reg->triminfo_ctrl[i]);
+ }
if (pdata->cal_mode == HW_MODE)
goto skip_calib_data;
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 1b4a644..72cb54e 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -151,8 +151,7 @@ struct exynos_tmu_registers {
u32 triminfo_25_shift;
u32 triminfo_85_shift;
- u32 triminfo_ctrl;
- u32 triminfo_ctrl1;
+ u32 triminfo_ctrl[2];
u32 triminfo_reload_shift;
u32 tmu_ctrl;
@@ -295,6 +294,8 @@ struct exynos_tmu_platform_data {
u8 second_point_trim;
u8 default_temp_offset;
u8 test_mux;
+ u8 triminfo_reload[2];
+ u8 triminfo_reload_count;
enum calibration_type cal_type;
enum calibration_mode cal_mode;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index aa8e0de..8cd609c 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -95,6 +95,8 @@ static const struct exynos_tmu_registers
exynos3250_tmu_registers = {
.triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
.triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
.triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
+ .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON1,
+ .triminfo_ctrl[1] = EXYNOS_TMU_TRIMINFO_CON2,
.tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
.test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
.buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
@@ -160,8 +162,11 @@ static const struct exynos_tmu_registers
exynos3250_tmu_registers = {
.temp_level = 95, \
}, \
.freq_tab_count = 2, \
+ .triminfo_reload[0] = 0x1, \
+ .triminfo_reload[1] = 0x11, \
+ .triminfo_reload_count = 2, \
.registers = _tmu_registers, \
- .features = (TMU_SUPPORT_EMULATION | \
+ .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
TMU_SUPPORT_EMUL_TIME)
#endif
@@ -184,7 +189,7 @@ static const struct exynos_tmu_registers
exynos4412_tmu_registers = {
.triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
.triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
.triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
- .triminfo_ctrl = EXYNOS_TMU_TRIMINFO_CON,
+ .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON2,
.triminfo_reload_shift = EXYNOS_TRIMINFO_RELOAD_SHIFT,
.tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
.test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
@@ -252,6 +257,8 @@ static const struct exynos_tmu_registers
exynos4412_tmu_registers = {
.temp_level = 95, \
}, \
.freq_tab_count = 2, \
+ .triminfo_reload[0] = 0x1, \
+ .triminfo_reload_count = 1, \
.registers = _tmu_registers, \
.features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
b/drivers/thermal/samsung/exynos_tmu_data.h
index f0979e5..e0536c3 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++ b/drivers/thermal/samsung/exynos_tmu_data.h
@@ -57,8 +57,11 @@
#define EXYNOS4210_TMU_TRIG_LEVEL_MASK 0x
#define EXYNOS4210_TMU_INTCLEAR_VAL0x
-/* Exynos5250 and Exynos4412 specific registers */
-#define EXYNOS_TMU_TRIMINFO_CON0x14
+/* Exynos3250 specific registers */
+#define EXYNOS_TMU_TRIMINFO_CON1
Re: [PATCH 2/3] kbuild: handle module compression while running 'make modules_install'.
> I understand your concern about this, but does is make sense to not use > -9 when then following files use gzip or other compression tools with -9 : Just because someone else makes mistakes doesn't mean that you should make them too. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
