[PATCH V4] mm: memory hot-add: memory can not be added to movable zone defaultly
From: Changsheng Liu After the user config CONFIG_MOVABLE_NODE and movable_node kernel option, When the memory is hot added, should_add_memory_movable() return 0 because all zones including movable zone are empty, so the memory that was hot added will be added to the normal zone and the normal zone will be created firstly. But we want the whole node to be added to movable zone defaultly. So we change should_add_memory_movable(): if the user config CONFIG_MOVABLE_NODE and movable_node kernel option it will always return 1 and all zones is empty at the same time, so that the movable zone will be created firstly and then the whole node will be added to movable zone defaultly. If we want the node to be added to normal zone, we can do it as follows: "echo online_kernel > /sys/devices/system/memory/memoryXXX/state" If the memory is added to movable zone defaultly, the user can offline it and add it to other zone again. But if the memory is added to normal zone defaultly, the user will not offline the memory used by kernel. Reviewed-by: Andrew Morton Reviewed-by: Yasuaki Ishimatsu Reviewed-by: Vlastimil Babka Reviewed-by: Xiaofeng Yan Signed-off-by: Changsheng Liu Tested-by: Dongdong Fan --- mm/memory_hotplug.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 26fbba7..d1149ff 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1197,6 +1197,11 @@ static int should_add_memory_movable(int nid, u64 start, u64 size) unsigned long start_pfn = start >> PAGE_SHIFT; pg_data_t *pgdat = NODE_DATA(nid); struct zone *movable_zone = pgdat->node_zones + ZONE_MOVABLE; + struct zone *normal_zone = pgdat->node_zones + ZONE_NORMAL; + + if (movable_node_is_enabled() + && (zone_end_pfn(normal_zone) <= start_pfn)) + return 1; if (zone_is_empty(movable_zone)) return 0; -- 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: [PATCH] ACPI / ARM64: Get configuration base address of ECAM via ACPI MCFG table
On Fri, Aug 28, 2015 at 03:39:43PM +0100, Lorenzo Pieralisi wrote:
> Hi Dennis,
>
> You should CC linux-...@vger.kernel.org and the PCI subsystem
> maintainer next time.
>
>
Good reminder! Thanks, mate ;-)
> On Fri, Aug 28, 2015 at 01:49:23PM +0100, Dennis Chen wrote:
> > This patch will fall back to ACPI MCFG table if _CBA method fails
> > to get the configuration base address of ECAM. Firmware on ARM
> > platform uses MCFG table instead of _CBA method. This is needed
> > to scan the PCIe root complex for ARM SoC.
>
> Code to enumerate PCI with ACPI on ARM64 is under review:
>
> https://lkml.org/lkml/2015/6/8/443
>
Oops,seems I am late, just go through the code to scan the root:
https://lkml.org/lkml/2015/5/26/215
a little bit complicated, to be honest. Maybe I can have some input then.
> Having said that, I do not think this patch will be needed,
> you can't add code in the kernel because it may be needed in
> the future, I do not see how it can be possibly useful at present
> on ARM64 unless you pulled some patch dependencies; if that's the
> case you should have listed them.
>
> This patch can't be review standalone since it has no use in
> the current kernel (at least for ARM64, it should be tested
> on x86 though).
I do have a patch set to enumerate all the downstream devices of
the PCIe root bridge. With this patch, I can focus on the enabling/fixing
of the drivers of those devices. As you can imagine, the patch have some
redundant codes with PCI/ACPI codes now under x86 directory. It's reasonable
to move those arch-agnostic codes to a common place. I am OK to keep
them pending as private as a test code base for me
As for this patch, it's used to get the ecam address from MCFG instead of
_CBA which x86 is using, see acpi_pci_root_get_mcfg_addr() code.
So, it's for ARM64 and can be tested with uefi definitely. I'm missing some
context here?
> Thanks,
> Lorenzo
>
> > Signed-off-by: Dennis Chen
> > ---
> > drivers/pci/pci-acpi.c | 102
> > ++---
> > 1 file changed, 97 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> > index 314a625..211b9d9 100644
> > --- a/drivers/pci/pci-acpi.c
> > +++ b/drivers/pci/pci-acpi.c
> > @@ -27,18 +27,110 @@ const u8 pci_acpi_dsm_uuid[] = {
> > 0x91, 0x17, 0xea, 0x4d, 0x19, 0xc3, 0x43, 0x4d
> > };
> >
> > +static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg)
> > +{
> > + if (mcfg->header.revision != 1) {
> > + pr_err("invalid header revision:%d in ACPI MCFG table\n",
> > + mcfg->header.revision);
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static phys_addr_t __init acpi_get_mcfg_cba(u16 segment, u8 bus)
> > +{
> > + struct acpi_table_header *table = NULL;
> > + acpi_size tbl_size;
> > + struct acpi_table_mcfg *mcfg = NULL;
> > + struct acpi_mcfg_allocation *cfg_table, *cfg;
> > + acpi_status status;
> > + phys_addr_t cba = 0;
> > + unsigned long i;
> > + int entries;
> > +
> > + if (acpi_disabled)
> > + return 0;
> > +
> > + status = acpi_get_table_with_size(ACPI_SIG_MCFG, 0, , _size);
> > + if (ACPI_FAILURE(status)) {
> > + const char *msg = acpi_format_exception(status);
> > +
> > + pr_err("Failed to get MCFG table, %s\n", msg);
> > + return 0;
> > + }
> > +
> > + if (table)
> > + mcfg = (struct acpi_table_mcfg *)table;
> > +
> > + entries = 0;
> > + i = table->length - sizeof(struct acpi_table_mcfg);
> > + while (i >= sizeof(struct acpi_mcfg_allocation)) {
> > + entries++;
> > + i -= sizeof(struct acpi_mcfg_allocation);
> > + }
> > + if (entries == 0) {
> > + pr_err("ACPI MCFG table has no entries\n");
> > + goto out;
> > + }
> > +
> > + cfg_table = (struct acpi_mcfg_allocation *) [1];
> > + for (i = 0; i < entries; i++) {
> > + cfg = _table[i];
> > + if (acpi_mcfg_check_entry(mcfg))
> > + goto out;
> > +
> > + if (cfg->pci_segment == segment &&
> > + cfg->start_bus_number <= bus &&
> > + bus <= cfg->end_bus_number) {
> > + cba = (phys_addr_t)cfg->address;
> > + goto out;
> > + }
> > + }
> > +out:
> > + /*
> > +* acpi_get_table_with_size() creates MCFG table mapping that
> > +* should be released after parsing and before resuming boot
> > +*/
> > + early_acpi_os_unmap_memory(table, tbl_size);
> > + return cba;
> > +}
> > +
> > phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle)
> > {
> > acpi_status status = AE_NOT_EXIST;
> > - unsigned long long mcfg_addr;
> > + unsigned long long mcfg_addr, mcfg_seg, mcfg_bus;
> > + u16 seg;
> > + u8 bus;
> > +
> > + if (!handle)
> > + return 0;
> >
> > - if (handle)
> > - status =
Re: [PATCH v3 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get
Hi, On Saturday 29 August 2015 12:33 AM, Tony Lindgren wrote: > * Olof Johansson [150828 11:11]: >> Hi, >> >> On Thu, Aug 27, 2015 at 2:13 AM, Kishon Vijay Abraham I >> wrote: >>> Now return error only if the return value of >>> devm_regulator_get_optional() is not the same as -ENODEV, since with >>> -EPROBE_DEFER, the regulator can be obtained later and all other >>> errors are fatal. >>> >>> Signed-off-by: Kishon Vijay Abraham I >>> Tested-by: Tony Lindgren >> >> I bisected boot failures on Panda ES with multi_v7_defconfig down to >> this commit on last night's -next build: >> >> http://arm-soc.lixom.net/bootlogs/next/next-20150828/pandaes-arm-multi_v7_defconfig.html > > MMC is working for me at least on Duovero. Interesting that you also > have all kind of errors there, I guess this is some older revision > of the board. > > Anyways, Kishon, care to look into what might be causing this? I think this might be because my pbias fix [1] patch wasn't merged yet. I'll try to get that resolved asap. Thanks Kishon [1] -> http://lkml.iu.edu/hypermail/linux/kernel/1507.3/01594.html > > Regards, > > Tony > -- 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] Revert part of "ASoC: tegra: Convert to managed resources"
On Tue, Aug 18, 2015 at 8:56 PM, Vaishali Thakkar
wrote:
> Revert the problematic part of commit 470805eb9f31 ("ASoC: tegra:
> Convert to managed resources"). Before this commit, PM cleanup was
> performed after the component was unregistered. But returning
> directly will skip PM cleanup. So, to be on safe side it is better
> to use snd_soc_register_component instead of
> devm_snd_soc_register_component.
>
> Signed-off-by: Vaishali Thakkar
I'm probably late for the party, but FWIW:
Reviewed-by: Alexandre Courbot
--
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] task_work: remove fifo ordering guarantee
> On Aug 30, 2015, at 01:08, Linus Torvalds > wrote: > > On Sat, Aug 29, 2015 at 7:11 AM, Eric Dumazet wrote: >> >> If this needs to be kept, maybe then add following, to make sure >> we flush the list at most every BITS_PER_LONG files > > Hmm. > > I'm wondering if we should just make close_files() (or maybe even > filp_close()) use a synchronous fput(). > > Iirc, the reason we delay fput() is that we had some nasty issues for > the generic fput case. It was called from interrupt context by the aio > code, and just in general there's a lot of nasty cases that can cause > the final fput to happen (so there are lockdep issues with the mmap > locks because the last fput being from munmap etc). > > Maybe I forget some detail - it's been several years by now - but I > think we could make the regular "close()" and "exit()" cases just use > the synchronous fput (it's called "__fput_sync()" and currently > explicitly limited to just kernel threads). > > Al? > > Because it feels all kinds of stupid to add things to the task-work > queue just to then remove it almost immediately again. And > close_files() is also called from various contexts. but the whole "put > the final 'files_struct' case is certainly not at all as special as > the 'put the final file'. > >Linus > — why not provide API like: fput() fput_nosync() ? because synchronous version are reasonable and safe in most time, let the user to select which version to use is more feasible, no matter if it is kthread or not. 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/
[PATCH] drm/fsl-dcu: Cleanup vblank interrupt mask and status setting code
Switch update interrupt mask bit with regmap_update_bits, and clear
interrupt status by writing 1 to relevant bit before setting mask in
fsl_dcu_drm_irq_init function.
Signed-off-by: Jianwei Wang
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 9a8e2da..bf36971 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -38,21 +38,17 @@ static const struct regmap_config fsl_dcu_regmap_config = {
static int fsl_dcu_drm_irq_init(struct drm_device *dev)
{
struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
- unsigned int value;
int ret;
ret = drm_irq_install(dev, fsl_dev->irq);
if (ret < 0)
dev_err(dev->dev, "failed to install IRQ handler\n");
- ret = regmap_write(fsl_dev->regmap, DCU_INT_STATUS, 0);
+ ret = regmap_write(fsl_dev->regmap, DCU_INT_STATUS, 0x);
if (ret)
dev_err(dev->dev, "set DCU_INT_STATUS failed\n");
- ret = regmap_read(fsl_dev->regmap, DCU_INT_MASK, );
- if (ret)
- dev_err(dev->dev, "read DCU_INT_MASK failed\n");
- value &= DCU_INT_MASK_VBLANK;
- ret = regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
+ ret = regmap_update_bits(fsl_dev->regmap, DCU_INT_MASK,
+DCU_INT_MASK_VBLANK, ~DCU_INT_MASK_VBLANK);
if (ret)
dev_err(dev->dev, "set DCU_INT_MASK failed\n");
ret = regmap_write(fsl_dev->regmap, DCU_UPDATE_MODE,
@@ -143,14 +139,10 @@ static irqreturn_t fsl_dcu_drm_irq(int irq, void *arg)
static int fsl_dcu_drm_enable_vblank(struct drm_device *dev, int crtc)
{
struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
- unsigned int value;
int ret;
- ret = regmap_read(fsl_dev->regmap, DCU_INT_MASK, );
- if (ret)
- dev_err(dev->dev, "read DCU_INT_MASK failed\n");
- value &= ~DCU_INT_MASK_VBLANK;
- ret = regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
+ ret = regmap_update_bits(fsl_dev->regmap, DCU_INT_MASK,
+DCU_INT_MASK_VBLANK, ~DCU_INT_MASK_VBLANK);
if (ret)
dev_err(dev->dev, "set DCU_INT_MASK failed\n");
return 0;
@@ -159,14 +151,10 @@ static int fsl_dcu_drm_enable_vblank(struct drm_device
*dev, int crtc)
static void fsl_dcu_drm_disable_vblank(struct drm_device *dev, int crtc)
{
struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
- unsigned int value;
int ret;
- ret = regmap_read(fsl_dev->regmap, DCU_INT_MASK, );
- if (ret)
- dev_err(dev->dev, "read DCU_INT_MASK failed\n");
- value |= DCU_INT_MASK_VBLANK;
- ret = regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
+ ret = regmap_update_bits(fsl_dev->regmap, DCU_INT_MASK,
+DCU_INT_MASK_VBLANK, DCU_INT_MASK_VBLANK);
if (ret)
dev_err(dev->dev, "set DCU_INT_MASK failed\n");
}
--
2.1.0.27.g96db324
--
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] regmap: Support bulk reads for devices without raw formatting
Hi Mark,
Yes, this patch solved the issue.It avoid the null function and just
need to handle the native endian case.
Thanks.
Henry
On Fri, 2015-08-28 at 20:11 +0100, Mark Brown wrote:
> When doing a bulk read from a device which lacks raw I/O support we fall
> back to doing register at a time reads but we still use the raw
> formatters in order to render the data into the word size used by the
> device (since bulk reads still operate on the device word size rather
> than unsigned ints). This means that devices without raw formatting
> such as those that provide reg_read() are not supported. Provide
> handling for them by copying the values read into native endian values
> of the appropriate size.
>
> Signed-off-by: Mark Brown
> ---
>
> This is tested with my "hey, look - it compiles!" test plan. Based on
> looking at the users and the other ways formatting is used this is the
> interface that makes most sense to me, we'll need similar handling for
> the write case. Does this solve the problems you are seeing?
>
> drivers/base/regmap/regmap.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
> index c13b1f2..62e3d7c 100644
> --- a/drivers/base/regmap/regmap.c
> +++ b/drivers/base/regmap/regmap.c
> @@ -2364,7 +2364,34 @@ int regmap_bulk_read(struct regmap *map, unsigned int
> reg, void *val,
> );
> if (ret != 0)
> return ret;
> - map->format.format_val(val + (i * val_bytes), ival, 0);
> +
> + if (map->format.format_val) {
> + map->format.format_val(val + (i * val_bytes),
> ival, 0);
> + } else {
> + /* Devices providing read and write
> + * operations can use the bulk I/O
> + * functions if they define a val_bytes,
> + * we assume that the values are native
> + * endian.
> + */
> + u32 *u32 = val;
> + u16 *u16 = val;
> + u8 *u8 = val;
> +
> + switch (map->format.val_bytes) {
> + case 4:
> + u32[i] = ival;
> + break;
> + case 2:
> + u16[i] = ival;
> + break;
> + case 1:
> + u8[i] = ival;
> + break;
> + default:
> + return -EINVAL;
> + }
> + }
> }
> }
>
--
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] gpio: gpiolib: use devm_* API to simplify driver code
On Tue, Aug 25, 2015 at 5:38 PM, Grygorii Strashko wrote: > On 08/24/2015 03:05 PM, Peng Fan wrote: >> >> Use devm_* API to simplify driver code. >> >> Signed-off-by: Peng Fan >> Cc: Linus Walleij >> Cc: Alexandre Courbot > > --- >> >> drivers/gpio/gpiolib.c | 11 +-- >> 1 file changed, 5 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c >> index 6bc612b..f9470b0 100644 >> --- a/drivers/gpio/gpiolib.c >> +++ b/drivers/gpio/gpiolib.c >> @@ -243,7 +243,8 @@ int gpiochip_add(struct gpio_chip *chip) >> int base = chip->base; >> struct gpio_desc *descs; >> >> - descs = kcalloc(chip->ngpio, sizeof(descs[0]), GFP_KERNEL); >> + descs = devm_kcalloc(chip->dev, chip->ngpio, sizeof(descs[0]), >> +GFP_KERNEL); > > > ^ above will not work for every one as NOT all GPIO drivers > implemented using dev/drv model, so chip->dev could be not set > (at least it was true when I've checked it last time). AFAICT that is still true as of today. -- 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 net-next v2 0/8] net: thunderx: New features and fixes
From: Aleksey Makarov Date: Sun, 30 Aug 2015 12:29:08 +0300 > v2: > - The unused affinity_mask field of the structure cmp_queue > has been deleted. (thanks to David Miller) > - The unneeded initializers have been dropped. (thanks to Alexey Klimov) > - The commit message "net: thunderx: Rework interrupt handling" > has been fixed. (thanks to Alexey Klimov) Series applied, 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: [PATCH] input: gpio_keys: Don't report events on gpio failure
On Tue, Aug 18, 2015 at 4:34 AM, Bjorn Andersson wrote: > On Sun 16 Aug 23:59 PDT 2015, Alexandre Courbot wrote: > >> On Thu, Aug 13, 2015 at 10:06 PM, Linus Walleij >> wrote: >> > On Tue, Aug 11, 2015 at 12:41 AM, Bjorn Andersson >> > wrote: >> > >> >> But then the question first goes to Linus & co. >> >> >> >> gpio_chip->get() can return a negative value to indicate errors (and did >> >> so in this case), all parts of the API seems indicates that we can get >> >> an error (int vs bool). >> > >> > Ooops. >> > >> >> Should we change _gpiod_get_raw_value() to propagate this error? >> > >> > Yes for now. Can you patch it? :) >> > >> >> Or >> >> should we just ignore this issue and propagate an error as GPIO high >> >> reading? >> > >> > I don't know about the future. In some sense GPIOs are so smallish >> > resources that errorhandling every call to read/write them seem to >> > be a royal PITA. That is why I wanted to switch them to bool and get >> > rid of the problem, but now I also see that maybe that was not such a >> > smart idea, if errors do occur on the set/get_value path. >> >> Nowadays GPIOs may reside at the other end of an i2c bus, which means >> that even the simplest operation like reading a GPIO value can >> potentially fail. And it will probably not get better - wait until we >> implement GPIO-over-IP! :) >> > > Now that's progress! I can't wait ;) > >> So I'd say it makes sense to propagate errors returned by the driver's >> get() hook. This might contradict some of our earlier statements about >> simplifying the GPIO API, but is preferrable to having to make a >> decision as to which valid value to return if the driver fails... >> > > Sounds good. > > As we're patching up _gpiod_get_raw_value(), is the lack of a get() > implementation the same as a LOW or is that -ENOTSUPP? I don't see any reason why it should not be -ENOTSUPP if we start to manage errors properly. > >> It should then be made very clear in the documentation that the only >> positive values ever returned by the GPIO API will be 0 and 1 (we >> already have a clamping mechanism for that IIRC), and that negative >> values are propagated as-is. >> > > That makes sense. I'm however not able to find such clamping > macro/mechanism and it would be very beneficial here... > >> Linus, does that seem reasonable to you? Does anyone has the intention >> to address that one or should I add it to my short-term TODO list? > > If you have some input on above (is lack of get() an error) I can hack > up the patch. Excellent - since Linus gave his thumb up, I think you can go ahead. Looking forward to seeing this finally fixed. Thanks! Alex. -- 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/
[RESEND PATCH v2] usb/gadget: make composite gadget meet usb compliance for vbus draw
>From 08df419517694c4dd9ff328f5644b46a99c2999e Mon Sep 17 00:00:00 2001
From: "Du, Changbin"
Date: Thu, 23 Jul 2015 20:08:04 +0800
Subject: [PATCH v2] usb/gadget: make composite gadget meet usb compliance for
vbus draw
USB-IF compliance requirement limits the vbus current according to
current state. USB2 Spec requires that un-configured current must
be <= 100mA, for USB3 is 150mA, OTG is 2.5mA. So set corresponding
vbus draw current according to device mode.
Signed-off-by: Du, Changbin
---
Resend patch since no response for 4 weeks, probably bee missed.
Changes from v1:
Also update configfs to use new api composite_reset.
---
drivers/usb/gadget/composite.c | 39 ---
drivers/usb/gadget/configfs.c | 2 +-
include/linux/usb/composite.h | 1 +
include/uapi/linux/usb/ch9.h | 9 +
4 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 4e3447b..b3896e9 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -610,6 +610,21 @@ static void device_qual(struct usb_composite_dev *cdev)
qual->bRESERVED = 0;
}
+static unsigned unconfigured_vbus_draw(struct usb_composite_dev *cdev)
+{
+ struct usb_gadget *g = cdev->gadget;
+ unsigned power;
+
+ if (gadget_is_otg(g))
+ power = USB_OTG_UNCONF_STATE_VBUS_MAX_DRAW;
+ else if (g->speed == USB_SPEED_SUPER)
+ power = USB3_UNCONF_STATE_VBUS_MAX_DRAW;
+ else
+ power = USB2_UNCONF_STATE_VBUS_MAX_DRAW;
+
+ return power;
+}
+
/*-*/
static void reset_config(struct usb_composite_dev *cdev)
@@ -634,7 +649,7 @@ static int set_config(struct usb_composite_dev *cdev,
struct usb_gadget *gadget = cdev->gadget;
struct usb_configuration *c = NULL;
int result = -EINVAL;
- unsignedpower = gadget_is_otg(gadget) ? 8 : 100;
+ unsignedpower = unconfigured_vbus_draw(cdev);
int tmp;
if (number) {
@@ -1829,6 +1844,15 @@ done:
return value;
}
+void composite_reset(struct usb_gadget *gadget)
+{
+ struct usb_composite_dev *cdev = get_gadget_data(gadget);
+
+ DBG(cdev, "reset\n");
+ usb_gadget_vbus_draw(gadget, unconfigured_vbus_draw(cdev));
+ composite_disconnect(gadget);
+}
+
void composite_disconnect(struct usb_gadget *gadget)
{
struct usb_composite_dev*cdev = get_gadget_data(gadget);
@@ -2095,7 +2119,7 @@ void composite_suspend(struct usb_gadget *gadget)
cdev->suspended = 1;
- usb_gadget_vbus_draw(gadget, 2);
+ usb_gadget_vbus_draw(gadget, USB_SUSPEND_STATE_VBUS_MAX_DRAW);
}
void composite_resume(struct usb_gadget *gadget)
@@ -2117,10 +2141,11 @@ void composite_resume(struct usb_gadget *gadget)
}
maxpower = cdev->config->MaxPower;
-
- usb_gadget_vbus_draw(gadget, maxpower ?
- maxpower : CONFIG_USB_GADGET_VBUS_DRAW);
- }
+ if (!maxpower)
+ maxpower = CONFIG_USB_GADGET_VBUS_DRAW;
+ } else
+ maxpower = unconfigured_vbus_draw(cdev);
+ usb_gadget_vbus_draw(gadget, maxpower);
cdev->suspended = 0;
}
@@ -2132,7 +2157,7 @@ static const struct usb_gadget_driver
composite_driver_template = {
.unbind = composite_unbind,
.setup = composite_setup,
- .reset = composite_disconnect,
+ .reset = composite_reset,
.disconnect = composite_disconnect,
.suspend= composite_suspend,
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 0495c94..e16335d 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1449,7 +1449,7 @@ static const struct usb_gadget_driver
configfs_driver_template = {
.unbind = configfs_composite_unbind,
.setup = composite_setup,
- .reset = composite_disconnect,
+ .reset = composite_reset,
.disconnect = composite_disconnect,
.suspend= composite_suspend,
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 2511469..825ad39 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -506,6 +506,7 @@ extern struct usb_string *usb_gstrings_attach(struct
usb_composite_dev *cdev,
extern int usb_string_ids_n(struct usb_composite_dev *c, unsigned n);
+extern void composite_reset(struct usb_gadget *gadget);
extern void composite_disconnect(struct usb_gadget *gadget);
extern int composite_setup(struct usb_gadget *gadget,
const struct usb_ctrlrequest *ctrl);
diff --git a/include/uapi/linux/usb/ch9.h
Re: [PATCH RFC V4 0/2] Optimize the snmp stat aggregation for large cpus
From: Raghavendra K T Date: Sun, 30 Aug 2015 11:29:40 +0530 > While creating 1000 containers, perf is showing lot of time spent in > snmp_fold_field on a large cpu system. > > The current patch tries to improve by reordering the statistics gathering. ... Series applied, 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: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm
On 08/30/2015 09:16 PM, Huang Rui wrote:
On Fri, Aug 28, 2015 at 07:05:13AM -0700, Guenter Roeck wrote:
On 08/28/2015 03:45 AM, Huang Rui wrote:
On Thu, Aug 27, 2015 at 10:30:43AM -0700, Guenter Roeck wrote:
On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
This patch introduces an algorithm that computes the average power by
reading a delta value of “core power accumulator” register during
measurement interval, and then dividing delta value by the length of
the time interval.
User is able to use power1_acc entry to measure the processor power
consumption and power1_acc just needs to be read twice with an needed
interval in-between.
A simple example:
$ cat /sys/bus/pci/devices/\:00\:18.4/hwmon/hwmon0/power1_acc
$ sleep 1s
$ cat /sys/bus/pci/devices/\:00\:18.4/hwmon/hwmon0/power1_acc
The result is current average processor power consumption in 1
seconds. The unit of the result is uWatt.
Signed-off-by: Huang Rui
---
drivers/hwmon/fam15h_power.c | 62
1 file changed, 62 insertions(+)
diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index d529e4b..3bab797 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -60,6 +60,7 @@ struct fam15h_power_data {
u64 cu_acc_power[MAX_CUS];
/* performance timestamp counter */
u64 cpu_sw_pwr_ptsc[MAX_CUS];
+ struct mutex acc_pwr_mutex;
};
static ssize_t show_power(struct device *dev,
@@ -121,17 +122,74 @@ static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit,
NULL);
static struct attribute_group fam15h_power_group;
__ATTRIBUTE_GROUPS(fam15h_power);
+static ssize_t show_power_acc(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int cpu, cu, cu_num, cores_per_cu;
+ u64 curr_cu_acc_power[MAX_CUS],
+ curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
+ u64 tdelta, avg_acc;
+ struct fam15h_power_data *data = dev_get_drvdata(dev);
+
+ cores_per_cu = amd_get_cores_per_cu();
+ cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
+
+ for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu +=
cores_per_cu) {
+ cu = cpu / cores_per_cu;
+ if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, _ptsc[cu])) {
+ pr_err("Failed to read PTSC counter MSR on core%d\n",
+ cpu);
+ return 0;
+ }
+
+ if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
+ _cu_acc_power[cu])) {
+ pr_err("Failed to read compute unit power accumulator MSR on
core%d\n",
+ cpu);
+ return 0;
+ }
+
+ if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
+ jdelta[cu] = data->max_cu_acc_power +
curr_cu_acc_power[cu];
+ jdelta[cu] -= data->cu_acc_power[cu];
+ } else {
+ jdelta[cu] = curr_cu_acc_power[cu] -
data->cu_acc_power[cu];
+ }
+ tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
+ jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
+ do_div(jdelta[cu], tdelta);
+
+ mutex_lock(>acc_pwr_mutex);
+ data->cu_acc_power[cu] = curr_cu_acc_power[cu];
+ data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
+ mutex_unlock(>acc_pwr_mutex);
+
+ /* the unit is microWatt */
+ avg_acc += jdelta[cu];
+ }
+
+ return sprintf(buf, "%u\n", (unsigned int) avg_acc);
+}
+static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);
I am not really a friend of introducing a non-standard attribute.
Does the energy attribute not work here ?
You're right. Non-standard attribute might not be good. Could you
please give me some hints if I use "energy" instead?
1 Joule = 1 Watt-second.
Something else, though - did you make sure that your code doesn't overflow ?
Even though you calculate the average in an u64, you display it as unsigned.
Thanks to your reminder. It should not be overflow. The maximum power
consumption of processor (AMD CZ and future 15h) is about 15 Watts =
15,000,000 uWatts = 0xE4E1C0 uWatts, the size is 24 < 32 < 64 bits.
Actually, the unit of jdelta is not Joule. Because the tdelta is the
loops (cycles) that PTSC counter (the freqency is about 100 MHz)
counts not seconds.
So avg_acc is the average power consumption not the accumulated energy.
Would power1_average then be better suitable for the attribute ?
There is also power1_average_interval which could be used to make
the interval configurable.
Thanks,
Guenter
--
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
[PATCH v2] MIPS: Fix console output for Fulong2e system
Commit 3adeb2566b9b ("MIPS: Loongson: Improve LEFI firmware interface")
made the number of UARTs dynamic if LEFI_FIRMWARE_INTERFACE is configured.
Unfortunately, it did not initialize the number of UARTs if
LEFI_FIRMWARE_INTERFACE is not configured. As a result, the Fulong2e
system has no console.
Fixes: 3adeb2566b9b ("MIPS: Loongson: Improve LEFI firmware interface")
Acked-by: Huacai Chen
Signed-off-by: Guenter Roeck
---
v2: Changed subject to 'MIPS'
Added Acked-by:
Rebased to v4.2 and re-tested with qemu
arch/mips/loongson64/common/env.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/mips/loongson64/common/env.c
b/arch/mips/loongson64/common/env.c
index f6c44dd332e2..d6d07ad56180 100644
--- a/arch/mips/loongson64/common/env.c
+++ b/arch/mips/loongson64/common/env.c
@@ -64,6 +64,9 @@ void __init prom_init_env(void)
}
if (memsize == 0)
memsize = 256;
+
+ loongson_sysconf.nr_uarts = 1;
+
pr_info("memsize=%u, highmemsize=%u\n", memsize, highmemsize);
#else
struct boot_params *boot_p;
--
2.1.4
--
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 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm
On Fri, Aug 28, 2015 at 07:05:13AM -0700, Guenter Roeck wrote:
> On 08/28/2015 03:45 AM, Huang Rui wrote:
> >On Thu, Aug 27, 2015 at 10:30:43AM -0700, Guenter Roeck wrote:
> >>On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
> >>>This patch introduces an algorithm that computes the average power by
> >>>reading a delta value of “core power accumulator” register during
> >>>measurement interval, and then dividing delta value by the length of
> >>>the time interval.
> >>>
> >>>User is able to use power1_acc entry to measure the processor power
> >>>consumption and power1_acc just needs to be read twice with an needed
> >>>interval in-between.
> >>>
> >>>A simple example:
> >>>
> >>>$ cat /sys/bus/pci/devices/\:00\:18.4/hwmon/hwmon0/power1_acc
> >>>$ sleep 1s
> >>>$ cat /sys/bus/pci/devices/\:00\:18.4/hwmon/hwmon0/power1_acc
> >>>
> >>>The result is current average processor power consumption in 1
> >>>seconds. The unit of the result is uWatt.
> >>>
> >>>Signed-off-by: Huang Rui
> >>>---
> >>> drivers/hwmon/fam15h_power.c | 62
> >>>
> >>> 1 file changed, 62 insertions(+)
> >>>
> >>>diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> >>>index d529e4b..3bab797 100644
> >>>--- a/drivers/hwmon/fam15h_power.c
> >>>+++ b/drivers/hwmon/fam15h_power.c
> >>>@@ -60,6 +60,7 @@ struct fam15h_power_data {
> >>> u64 cu_acc_power[MAX_CUS];
> >>> /* performance timestamp counter */
> >>> u64 cpu_sw_pwr_ptsc[MAX_CUS];
> >>>+ struct mutex acc_pwr_mutex;
> >>> };
> >>>
> >>> static ssize_t show_power(struct device *dev,
> >>>@@ -121,17 +122,74 @@ static DEVICE_ATTR(power1_crit, S_IRUGO,
> >>>show_power_crit, NULL);
> >>> static struct attribute_group fam15h_power_group;
> >>> __ATTRIBUTE_GROUPS(fam15h_power);
> >>>
> >>>+static ssize_t show_power_acc(struct device *dev,
> >>>+struct device_attribute *attr, char *buf)
> >>>+{
> >>>+ int cpu, cu, cu_num, cores_per_cu;
> >>>+ u64 curr_cu_acc_power[MAX_CUS],
> >>>+ curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
> >>>+ u64 tdelta, avg_acc;
> >>>+ struct fam15h_power_data *data = dev_get_drvdata(dev);
> >>>+
> >>>+ cores_per_cu = amd_get_cores_per_cu();
> >>>+ cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> >>>+
> >>>+ for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu +=
> >>>cores_per_cu) {
> >>>+ cu = cpu / cores_per_cu;
> >>>+ if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, _ptsc[cu])) {
> >>>+ pr_err("Failed to read PTSC counter MSR on core%d\n",
> >>>+ cpu);
> >>>+ return 0;
> >>>+ }
> >>>+
> >>>+ if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> >>>+ _cu_acc_power[cu])) {
> >>>+ pr_err("Failed to read compute unit power accumulator
> >>>MSR on core%d\n",
> >>>+ cpu);
> >>>+ return 0;
> >>>+ }
> >>>+
> >>>+ if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
> >>>+ jdelta[cu] = data->max_cu_acc_power +
> >>>curr_cu_acc_power[cu];
> >>>+ jdelta[cu] -= data->cu_acc_power[cu];
> >>>+ } else {
> >>>+ jdelta[cu] = curr_cu_acc_power[cu] -
> >>>data->cu_acc_power[cu];
> >>>+ }
> >>>+ tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
> >>>+ jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
> >>>+ do_div(jdelta[cu], tdelta);
> >>>+
> >>>+ mutex_lock(>acc_pwr_mutex);
> >>>+ data->cu_acc_power[cu] = curr_cu_acc_power[cu];
> >>>+ data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
> >>>+ mutex_unlock(>acc_pwr_mutex);
> >>>+
> >>>+ /* the unit is microWatt */
> >>>+ avg_acc += jdelta[cu];
> >>>+ }
> >>>+
> >>>+ return sprintf(buf, "%u\n", (unsigned int) avg_acc);
> >>>+}
> >>>+static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);
> >>
> >>I am not really a friend of introducing a non-standard attribute.
> >>Does the energy attribute not work here ?
> >>
> >
> >You're right. Non-standard attribute might not be good. Could you
> >please give me some hints if I use "energy" instead?
> >
> 1 Joule = 1 Watt-second.
>
> Something else, though - did you make sure that your code doesn't overflow ?
> Even though you calculate the average in an u64, you display it as unsigned.
>
Thanks to your reminder. It should not be overflow. The maximum power
consumption of processor (AMD CZ and future 15h) is about 15 Watts =
15,000,000 uWatts = 0xE4E1C0 uWatts, the size is 24 < 32 < 64 bits.
Actually, the unit of jdelta is not Joule. Because the tdelta is the
loops (cycles) that PTSC counter (the freqency is about 100 MHz)
counts not seconds.
So avg_acc is the average power consumption not the accumulated energy.
> 100w * 10,000s = 1,000,000ws = 1,000,000,000,000 micro-watt-seconds, which is
> a
Re: [PATCH v3] selftests/zram: Adding zram tests
On Tue, 2015-08-18 at 12:31 +0530, naresh.kamb...@linaro.org wrote: > From: Naresh Kamboju > > diff --git a/tools/testing/selftests/zram/Makefile > b/tools/testing/selftests/zram/Makefile > new file mode 100644 > index 000..ec45513 > --- /dev/null > +++ b/tools/testing/selftests/zram/Makefile > @@ -0,0 +1,12 @@ > +all: > + > +TEST_PROGS := zram.sh > +TEST_FILES := zram01.sh zram02.sh zram_lib.sh > + > +include ../lib.mk > + > +run_tests: > + @/bin/bash ./zram.sh > + This is wrong, it gives me: $ make TARGETS=zram install ... Makefile:9: warning: overriding recipe for target 'run_tests' ../lib.mk:12: warning: ignoring old recipe for target 'run_tests' If you want to define run_tests you need to do: override define RUN_TESTS ./zram.sh endef BUT, I don't see any reason why you need to override run_tests. The default rule will just run TEST_PROGS, which is zram.sh so that should work fine? cheers -- 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] drm/fsl-dcu: Fix no fb check bug
For state->fb may be NULL in fsl_dcu_drm_plane_atomic_check function,
if so, return -EINVAL. No need check in fsl_dcu_drm_plane_atomic_update
anymore.
Signed-off-by: Jianwei Wang
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
index 82be6b8..8787920 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
@@ -41,6 +41,9 @@ static int fsl_dcu_drm_plane_atomic_check(struct drm_plane
*plane,
{
struct drm_framebuffer *fb = state->fb;
+ if (!fb)
+ return -EINVAL;
+
switch (fb->pixel_format) {
case DRM_FORMAT_RGB565:
case DRM_FORMAT_RGB888:
@@ -84,9 +87,6 @@ static void fsl_dcu_drm_plane_atomic_update(struct drm_plane
*plane,
unsigned int alpha, bpp;
int index, ret;
- if (!fb)
- return;
-
index = fsl_dcu_drm_plane_index(plane);
if (index < 0)
return;
--
2.1.0.27.g96db324
--
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] ARM: dts: Add exynos5422-odroidxu4 board
Add Hardkernel Odroid XU4 board Device Tree sources. The board differs
from Odroid XU3 and XU3-Lite by:
1. No green and red leds (except standard red power led).
2. No audio codec.
3. Two USB3 ports in host mode (no micro USB3 connector for OTG).
4. Realtek RTL8153-CG gigabit network adapter (instead of SMSC9514).
5. Additional connector with IO ports (I2S_0, I2C_5).
6. No DisplayPort.
7. No TI INA231 power measurement sensors.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi | 56 ++
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 90 +-
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts| 52 +
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 52 +
arch/arm/boot/dts/exynos5422-odroidxu4.dts | 48
6 files changed, 210 insertions(+), 89 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
create mode 100644 arch/arm/boot/dts/exynos5422-odroidxu4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d2eaab..3d27fe34647f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -123,6 +123,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5420-smdk5420.dtb \
exynos5422-odroidxu3.dtb \
exynos5422-odroidxu3-lite.dtb \
+ exynos5422-odroidxu4.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb \
exynos5800-peach-pi.dtb
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
new file mode 100644
index ..eee16a820484
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
@@ -0,0 +1,56 @@
+/*
+ * Hardkernel Odroid XU3 Audio Codec device tree source
+ *
+ * Copyright (c) 2015 Krzysztof Kozlowski
+ * Copyright (c) 2014 Collabora Ltd.
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/ {
+ sound: sound {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,name = "Odroid-XU3";
+ simple-audio-card,widgets =
+ "Headphone", "Headphone Jack",
+ "Speakers", "Speakers";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPL",
+ "Headphone Jack", "HPR",
+ "Headphone Jack", "MICBIAS",
+ "IN1", "Headphone Jack",
+ "Speakers", "SPKL",
+ "Speakers", "SPKR";
+
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <_codec>;
+ simple-audio-card,frame-master = <_codec>;
+
+ simple-audio-card,cpu {
+ sound-dai = < 0>;
+ system-clock-frequency = <1920>;
+ };
+
+ link0_codec: simple-audio-card,codec {
+ sound-dai = <>;
+ clocks = < CLK_I2S_CDCLK>;
+ };
+ };
+};
+
+_5 {
+ max98090: max98090@10 {
+ compatible = "maxim,max98090";
+ reg = <0x10>;
+ interrupt-parent = <>;
+ interrupts = <2 0>;
+ clocks = < CLK_I2S_CDCLK>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ };
+};
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index dd8bc86d9de4..52c34d8e791f 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -46,70 +46,6 @@
reset-gpios = < 0 1>;
};
- pwmleds {
- compatible = "pwm-leds";
-
- greenled {
- label = "green:mmc0";
- pwms = < 1 200 0>;
- pwm-names = "pwm1";
- /*
-* Green LED is much brighter than the others
-* so limit its max brightness
-*/
- max_brightness = <127>;
- linux,default-trigger = "mmc0";
- };
-
- blueled {
- label = "blue:heartbeat";
- pwms = < 2 200 0>;
- pwm-names = "pwm2";
- max_brightness = <255>;
- linux,default-trigger = "heartbeat";
- };
- };
-
- gpioleds {
- compatible = "gpio-leds";
- redled {
-
Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
On Wed, Aug 26, 2015 at 10:27:44AM -0500, Nathan Sullivan wrote:
> The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING flag,
> unlike the default platform data. Add platform data specific to the
> Zynq udc.
>
You may add the possible reason, eg, tx buffer is not enough.
Others are ok.
> Based on a patch by the same name from the Xilinx vendor tree.
>
> Signed-off-by: Nathan Sullivan
> ---
> drivers/usb/chipidea/ci_hdrc_usb2.c | 25 +++--
> 1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c
> b/drivers/usb/chipidea/ci_hdrc_usb2.c
> index 9eae1a1..4456d2c 100644
> --- a/drivers/usb/chipidea/ci_hdrc_usb2.c
> +++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -30,18 +31,36 @@ static const struct ci_hdrc_platform_data
> ci_default_pdata = {
> .flags = CI_HDRC_DISABLE_STREAMING,
> };
>
> +static struct ci_hdrc_platform_data ci_zynq_pdata = {
> + .capoffset = DEF_CAPOFFSET,
> +};
> +
> +static const struct of_device_id ci_hdrc_usb2_of_match[] = {
> + { .compatible = "chipidea,usb2"},
> + { .compatible = "xlnx,zynq-usb-2.20a", .data = _zynq_pdata},
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ci_hdrc_usb2_of_match);
> +
> static int ci_hdrc_usb2_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct ci_hdrc_usb2_priv *priv;
> struct ci_hdrc_platform_data *ci_pdata = dev_get_platdata(dev);
> int ret;
> + const struct of_device_id *match;
>
> if (!ci_pdata) {
> ci_pdata = devm_kmalloc(dev, sizeof(*ci_pdata), GFP_KERNEL);
> *ci_pdata = ci_default_pdata; /* struct copy */
> }
>
> + match = of_match_device(ci_hdrc_usb2_of_match, >dev);
> + if (match && match->data) {
> + /* struct copy */
> + *ci_pdata = *(struct ci_hdrc_platform_data *)match->data;
> + }
> +
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
> @@ -96,12 +115,6 @@ static int ci_hdrc_usb2_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -static const struct of_device_id ci_hdrc_usb2_of_match[] = {
> - { .compatible = "chipidea,usb2" },
> - { }
> -};
> -MODULE_DEVICE_TABLE(of, ci_hdrc_usb2_of_match);
> -
> static struct platform_driver ci_hdrc_usb2_driver = {
> .probe = ci_hdrc_usb2_probe,
> .remove = ci_hdrc_usb2_remove,
> --
> 1.7.10.4
>
--
Best Regards,
Peter Chen
--
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] usb: chipidea: add xilinx zynq platform data
On Mon, Aug 31, 2015 at 09:01:51AM +0530, punnaiah choudary kalluri wrote: > On Mon, Aug 31, 2015 at 6:10 AM, Peter Chen wrote: > > On Fri, Aug 28, 2015 at 09:42:56AM -0500, Nathan Sullivan wrote: > >> On Fri, Aug 28, 2015 at 09:30:12AM +0800, Peter Chen wrote: > >> > On Thu, Aug 27, 2015 at 09:33:07AM -0500, Nathan Sullivan wrote: > >> > > On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary kalluri > >> > > wrote: > >> > > > Hi, > >> > > > > >> > > > On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen > >> > > > wrote: > >> > > > > On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote: > >> > > > >> Hi, > >> > > > >> > >> > > > >> > >> > > > >> On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan > >> > > > >> wrote: > >> > > > >> > The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING > >> > > > >> > flag, > >> > > > >> > unlike the default platform data. Add platform data specific > >> > > > >> > to the > >> > > > >> > Zynq udc. > >> > > > >> > > >> > > > >> > Based on a patch by the same name from the Xilinx vendor tree. > >> > > > >> > >> > > > >> I am that Xilinx guy who sent this patch :). It is in Xilinx tree > >> > > > >> as > >> > > > >> temporary fix and > >> > > > >> I did not debug further why UDC works only when streaming is > >> > > > >> enabled. > >> > > > >> Probably this is right time to post my question here. > >> > > > >> I was expecting like: > >> > > > >> Streaming disabled - both low bandwidth and high bandwidth systems > >> > > > >> should work fine > >> > > > >> Streaming enabled - only for high bandwidth systems > >> > > > >> but this is not the case, Zynq UDC works only when Streaming is > >> > > > >> enabled. > >> > > > >> Please correct me if I am wrong. > >> > > > > > >> > > > > You are right, stream mode disabled should work at anytime. > >> > > > > It is so strange why zynq UDC only works when stream mode is > >> > > > > enabled. > >> > > > > >> > > > I am referring the section 8.5.2 in Synopsys usb 2.0 HS > >> > > > controllervDoc 2.20a, > >> > > > this is what it says about SDIS (streaming mode disable option) > >> > > > > >> > > > Before activating this mode, the user must check if the TX latency > >> > > > buffers per endpoint are able to > >> > > > accommodate at least one entire maximum size packet. The RX buffer > >> > > > size must, at least, double the TX > >> > > > buffer size per endpoint. To optimize the stream disable performance, > >> > > > system bus burst must be set as high > >> > > > as possible. > >> > > > When the stream disable mode is used, the burst size > >> > > > (VUSB_HS_RX_BURST > >> > > > and VUSB_HS_TX_BURST) > >> > > > must be a integer sub-multiple of the latency buffer size > >> > > > (VUSB_HS_RX_DEPTH for RX buffer and > >> > > > VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the > >> > > > controller will not work properly in stream > >> > > > disable mode. > >> > > > The stream disable mode should just be used in situations where the > >> > > > available system bandwidth is low or the > >> > > > system bus access latency is high, in order to avoid underruns and > >> > > > overruns in the latency buffers. This works > >> > > > for all types of endpoints, except for ISO endpoints. > >> > > > Such a system can't ensure the real time support that the ISO > >> > > > endpoints require, so the ISO endpoints are not > >> > > > supported when the SDIS bit is set. > >> > > > > >> > > > Definitely we need to root cause why disable streaming mode is not > >> > > > working for zynq but from controller spec > >> > > > point of view it is possible that controller not work properly in > >> > > > stream disable mode. > >> > > > > >> > > > Regards, > >> > > > Punnaiah > >> > > > > >> > > > >> > > Maybe the burst size isn't set correctly by default? It does say the > >> > > controller > >> > > won't work correctly with stream disable set and an invalid burst > >> > > size. Looks > >> > > like TX and RX burst both default to 16, per the Zynq manual. > >> > > > >> > > With the stream disable bit set, the behvior we see on our hardware is > >> > > that priming just stops, with an outstanding transfer in memory marked > >> > > active in the status field by the controller. This happens at random, > >> > > even > >> > > when doing single transfers at a time like with g_ether set to have a > >> > > queue > >> > > size of 1. With SDIS clear everything works great. Given that the > >> > > Zynq is not > >> > > bandwidth constrained, it seems like SDIS clear should be the default. > >> > > > >> > > >> > I suspect the possible reason is the tx buffer for each endpoint is > >> > small (<=512 bytes), so it can't copy one packet (assume max packet size > >> > for bulk) to tx buffer, then the prime can't be finished. > >> > > >> > Would you help to dump the registers HWTXBUF ($BASE + 0x10) and DCCPARAMS > >> > ($BASE + 124)? > >> > > >> > tx buffer size = ((2 ^ HWTXBUF.VUSB_HS_TX_ADD) / DCCPARAMS.DEN) * > >> >
Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Tue, Aug 25, 2015 at 12:16 PM, punnaiah choudary kalluri
wrote:
> Hi Rob,
>
> On Tue, Aug 25, 2015 at 12:23 AM, Rob Herring wrote:
>> On Wed, Aug 5, 2015 at 10:19 PM, Punnaiah Choudary Kalluri
>> wrote:
>>> Device-tree binding documentation for Xilinx zynqmp dma engine used in
>>> Zynq UltraScale+ MPSoC.
>>>
>>> Signed-off-by: Punnaiah Choudary Kalluri
>>> ---
>>> Changes in v4:
>>> - None
>>> Changes in v3:
>>> - None
>>> Changes in v2:
>>> - None
>>> ---
>>> .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 61
>>>
>>> 1 files changed, 61 insertions(+), 0 deletions(-)
>>> create mode 100644
>>> Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>>> b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>>> new file mode 100644
>>> index 000..e4f92b9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>>> @@ -0,0 +1,61 @@
>>> +Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
>>> +memory to device and device to memory transfers. It also has flow
>>> +control and rate control support for slave/peripheral dma access.
>>> +
>>> +Required properties:
>>> +- compatible: Should be "xlnx,zynqmp-dma-1.0"
>>> +- #dma-cells: Should be <1>, a single cell holding a line request number
>>> +- reg: Memory map for module access
>>> +- interrupt-parent: Interrupt controller the interrupt is routed through
>>> +- interrupts: Should contain DMA channel interrupt
>>> +- xlnx,bus-width: AXI buswidth in bits. Should contain 128 or 64
>>> +
>>> +Optional properties:
>>> +- xlnx,include-sg: Indicates the controller to operate in simple or scatter
>>> + gather dma mode
>>> +- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
>>> +source AXI transaction
>>> +- xlnx,overfetch: Tells whether the channel is allowed to over fetch the
>>> data
>>> +- xlnx,src-issue: Number of AXI outstanding transactions on source side
>>> +- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for
>>> the
>>> + descriptor read are marked Non-coherent
>>> +- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
>>> + source descriptor payload are marked Non-coherent
>>> +- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
>>> + dst descriptor payload are marked Non-coherent
>>
>> Do you really need 3? dma-coherent property doesn't work for you?
>>
>> Not that it should dictate the binding, but the kernel doesn't support
>> a device needing both coherent and non-coherent DMA ops.
>
> I will get back to you shortly on this
Yes. dma-coherent property works. I will modify the bindings.
Thanks,
Punnaiah
>
>>
>>> +- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
>>> +- xlnx,src-axi-qos: AXI QOS bits to be used for data read
>>> +- xlnx,dst-axi-qos: AXI QOS bits to be used for data write
>>> +- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch.
>>> +- xlnx,desc-axi-cache: AXI cache bits to be used for data read
>>> +- xlnx,desc-axi-cache: AXI cache bits to be used for data write
>>
>> These signals are generally part of the coherent or not setting. This
>> allows for potentially invalid combinations.
>>
>> Plus you have a copy/paste error.
>
> I will fix this.
>
> Thanks,
> Punnaiah
>>
>>> +- xlnx,src-burst-len: AXI length for data read. Support only power of 2
>>> values
>>> + i.e 1,2,4,8 and 16
>>> +- xlnx,dst-burst-len: AXI length for data write. Support only power of 2
>>> values
>>> + i.e 1,2,4,8 and 16
>>> +
>>> +Example:
>>> +
>>> +fpd_dma_chan1: dma@FD50 {
>>> + compatible = "xlnx,zynqmp-dma-1.0";
>>> + reg = <0x0 0xFD50 0x1000>;
>>> + #dma_cells = <1>;
>>> + interrupt-parent = <>;
>>> + interrupts = <0 117 4>;
>>> + xlnx,bus-width = <128>;
>>> + xlnx,include-sg;
>>> + xlnx,overfetch;
>>> + xlnx,ratectrl = <0>;
>>> + xlnx,src-issue = <16>;
>>> + xlnx,desc-axi-cohrnt;
>>> + xlnx,src-axi-cohrnt;
>>> + xlnx,dst-axi-cohrnt;
>>> + xlnx,desc-axi-qos = <0>;
>>> + xlnx,desc-axi-cache = <0>;
>>> + xlnx,src-axi-qos = <0>;
>>> + xlnx,src-axi-cache = <2>;
>>> + xlnx,dst-axi-qos = <0>;
>>> + xlnx,dst-axi-cache = <2>;
>>> + xlnx,src-burst-len = <4>;
>>> + xlnx,dst-burst-len = <4>;
>>> +};
>>> --
>>> 1.7.4
>>>
>>>
>>> ___
>>> linux-arm-kernel mailing list
>>> linux-arm-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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
[PATCH v3] cpuidle/coupled: Add sanity check for safe_state_index
From: Xunlei Pang
Since we are using cpuidle_driver::safe_state_index directly as the
target state index, it is better to add the sanity check at the point
of registering the driver.
Signed-off-by: Xunlei Pang
---
v2->v3:
Move the code to a new cpuidle_coupled_state_verify() depending on
CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED, to avoid using #ifdef in function
bodies. Thanks Rafael's comments on this.
drivers/cpuidle/coupled.c | 22 ++
drivers/cpuidle/cpuidle.h | 6 ++
drivers/cpuidle/driver.c | 4
3 files changed, 32 insertions(+)
diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index 1523e2d..344058f 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
@@ -187,6 +187,28 @@ bool cpuidle_state_is_coupled(struct cpuidle_driver *drv,
int state)
}
/**
+ * cpuidle_coupled_state_verify - check if the coupled states are correctly
set.
+ * @drv: struct cpuidle_driver for the platform
+ *
+ * Returns 0 for valid state values, a negative error code otherwise:
+ * * -EINVAL if any coupled state(safe_state_index) is wrongly set.
+ */
+int cpuidle_coupled_state_verify(struct cpuidle_driver *drv)
+{
+ int i;
+
+ for (i = drv->state_count - 1; i >= 0; i--) {
+ if (cpuidle_state_is_coupled(drv, i) &&
+ (drv->safe_state_index == i ||
+drv->safe_state_index < 0 ||
+drv->safe_state_index >= drv->state_count))
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/**
* cpuidle_coupled_set_ready - mark a cpu as ready
* @coupled: the struct coupled that contains the current cpu
*/
diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
index 178c5ad..f87f399 100644
--- a/drivers/cpuidle/cpuidle.h
+++ b/drivers/cpuidle/cpuidle.h
@@ -35,6 +35,7 @@ extern void cpuidle_remove_sysfs(struct cpuidle_device *dev);
#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
bool cpuidle_state_is_coupled(struct cpuidle_driver *drv, int state);
+int cpuidle_coupled_state_verify(struct cpuidle_driver *drv);
int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int next_state);
int cpuidle_coupled_register_device(struct cpuidle_device *dev);
@@ -46,6 +47,11 @@ bool cpuidle_state_is_coupled(struct cpuidle_driver *drv,
int state)
return false;
}
+static inline int cpuidle_coupled_state_verify(struct cpuidle_driver *drv)
+{
+ return 0;
+}
+
static inline int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int next_state)
{
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 5db1478..389ade4 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -227,6 +227,10 @@ static int __cpuidle_register_driver(struct cpuidle_driver
*drv)
if (!drv || !drv->state_count)
return -EINVAL;
+ ret = cpuidle_coupled_state_verify(drv);
+ if (ret)
+ return ret;
+
if (cpuidle_disabled())
return -ENODEV;
--
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 1/2] usb: chipidea: add xilinx zynq platform data
On Mon, Aug 31, 2015 at 6:10 AM, Peter Chen wrote: > On Fri, Aug 28, 2015 at 09:42:56AM -0500, Nathan Sullivan wrote: >> On Fri, Aug 28, 2015 at 09:30:12AM +0800, Peter Chen wrote: >> > On Thu, Aug 27, 2015 at 09:33:07AM -0500, Nathan Sullivan wrote: >> > > On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary kalluri >> > > wrote: >> > > > Hi, >> > > > >> > > > On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen >> > > > wrote: >> > > > > On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote: >> > > > >> Hi, >> > > > >> >> > > > >> >> > > > >> On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan >> > > > >> wrote: >> > > > >> > The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING >> > > > >> > flag, >> > > > >> > unlike the default platform data. Add platform data specific to >> > > > >> > the >> > > > >> > Zynq udc. >> > > > >> > >> > > > >> > Based on a patch by the same name from the Xilinx vendor tree. >> > > > >> >> > > > >> I am that Xilinx guy who sent this patch :). It is in Xilinx tree as >> > > > >> temporary fix and >> > > > >> I did not debug further why UDC works only when streaming is >> > > > >> enabled. >> > > > >> Probably this is right time to post my question here. >> > > > >> I was expecting like: >> > > > >> Streaming disabled - both low bandwidth and high bandwidth systems >> > > > >> should work fine >> > > > >> Streaming enabled - only for high bandwidth systems >> > > > >> but this is not the case, Zynq UDC works only when Streaming is >> > > > >> enabled. >> > > > >> Please correct me if I am wrong. >> > > > > >> > > > > You are right, stream mode disabled should work at anytime. >> > > > > It is so strange why zynq UDC only works when stream mode is enabled. >> > > > >> > > > I am referring the section 8.5.2 in Synopsys usb 2.0 HS controllervDoc >> > > > 2.20a, >> > > > this is what it says about SDIS (streaming mode disable option) >> > > > >> > > > Before activating this mode, the user must check if the TX latency >> > > > buffers per endpoint are able to >> > > > accommodate at least one entire maximum size packet. The RX buffer >> > > > size must, at least, double the TX >> > > > buffer size per endpoint. To optimize the stream disable performance, >> > > > system bus burst must be set as high >> > > > as possible. >> > > > When the stream disable mode is used, the burst size (VUSB_HS_RX_BURST >> > > > and VUSB_HS_TX_BURST) >> > > > must be a integer sub-multiple of the latency buffer size >> > > > (VUSB_HS_RX_DEPTH for RX buffer and >> > > > VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the >> > > > controller will not work properly in stream >> > > > disable mode. >> > > > The stream disable mode should just be used in situations where the >> > > > available system bandwidth is low or the >> > > > system bus access latency is high, in order to avoid underruns and >> > > > overruns in the latency buffers. This works >> > > > for all types of endpoints, except for ISO endpoints. >> > > > Such a system can't ensure the real time support that the ISO >> > > > endpoints require, so the ISO endpoints are not >> > > > supported when the SDIS bit is set. >> > > > >> > > > Definitely we need to root cause why disable streaming mode is not >> > > > working for zynq but from controller spec >> > > > point of view it is possible that controller not work properly in >> > > > stream disable mode. >> > > > >> > > > Regards, >> > > > Punnaiah >> > > > >> > > >> > > Maybe the burst size isn't set correctly by default? It does say the >> > > controller >> > > won't work correctly with stream disable set and an invalid burst size. >> > > Looks >> > > like TX and RX burst both default to 16, per the Zynq manual. >> > > >> > > With the stream disable bit set, the behvior we see on our hardware is >> > > that priming just stops, with an outstanding transfer in memory marked >> > > active in the status field by the controller. This happens at random, >> > > even >> > > when doing single transfers at a time like with g_ether set to have a >> > > queue >> > > size of 1. With SDIS clear everything works great. Given that the Zynq >> > > is not >> > > bandwidth constrained, it seems like SDIS clear should be the default. >> > > >> > >> > I suspect the possible reason is the tx buffer for each endpoint is >> > small (<=512 bytes), so it can't copy one packet (assume max packet size >> > for bulk) to tx buffer, then the prime can't be finished. >> > >> > Would you help to dump the registers HWTXBUF ($BASE + 0x10) and DCCPARAMS >> > ($BASE + 124)? >> > >> > tx buffer size = ((2 ^ HWTXBUF.VUSB_HS_TX_ADD) / DCCPARAMS.DEN) * >> > (DWORD_PER_BYTES) >> > >> > DWORD_PER_BYTES is 4 >> > >> > -- >> > >> > Best Regards, >> > Peter Chen >> >> HWTXBUF is 0x80060A10, DCCPARAMS is 0xE0003124. > > Are you sure you read correct address? Your DCCPARAMS means > it is host capable, but not device capable. HWTXBUF is 0x8060A10 DCCPARAMS is 0x018C
Re: [PATCH 6/7] selftests: only compile userfaultfd for x86 and powperpc
On Fri, 2015-08-14 at 21:43 +0800, Bamvor Jian Zhang wrote:
> Signed-off-by: Bamvor Jian Zhang
> ---
> tools/testing/selftests/vm/Makefile | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/tools/testing/selftests/vm/Makefile
> b/tools/testing/selftests/vm/Makefile
> index bb888c6..4dd6e4f 100644
> --- a/tools/testing/selftests/vm/Makefile
> +++ b/tools/testing/selftests/vm/Makefile
> @@ -1,5 +1,15 @@
> # Makefile for vm selftests
>
> +uname_M := $(shell uname -m 2>/dev/null || echo not)
> +ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/ -e s/ppc.*/powerpc/)
> +
> +ifeq ($(ARCH),powerpc)
> +support_userfaultfd = yes
> +endif
> +ifeq ($(ARCH),x86)
> +support_userfaultfd = yes
> +endif
> +
> CFLAGS = -Wall
> BINARIES = compaction_test
> BINARIES += hugepage-mmap
> @@ -9,7 +19,9 @@ BINARIES += mlock2-tests
> BINARIES += on-fault-limit
> BINARIES += thuge-gen
> BINARIES += transhuge-stress
> +ifdef support_userfaultfd
> BINARIES += userfaultfd
> +endif
>
> all: $(BINARIES)
> %: %.c
This is nasty. It means when userfaultfd gets implemented for other arches
someone has to remember to update the logic here, which they won't.
Instead the C program should just do nothing when __NR_userfaultfd is not
defined, eg:
#ifdef __NR_userfaultfd
int main(int argc, char **argv)
{
...
}
#else
int main(void)
{
printf("skip: Skipping userfaultfd test\n");
return 0;
}
#endif
This way when the syscall is implemented for other arches the test will just
start working.
cheers
--
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/
linux-next: manual merge of the trivial tree with the drm tree
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in:
drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c
between commit:
109c2f2f1c42 ("drm/nouveau/gr: switch to subdev printk macros")
from the drm tree and commit:
4bb138a47b7f ("drm/nouveau/gr: Fix typo in nv10.c")
from the trivial tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c
index 9436ada62cba,d6ace41830e9..
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c
@@@ -791,7 -845,7 +791,7 @@@ nv10_gr_ctx_regs_find_offset(struct nv1
if (nv10_gr_ctx_regs[i] == reg)
return i;
}
- nvkm_error(subdev, "unknow offset nv10_ctx_regs %d\n", reg);
- nv_error(priv, "unknown offset nv10_ctx_regs %d\n", reg);
++ nvkm_error(subdev, "unknown offset nv10_ctx_regs %d\n", reg);
return -1;
}
@@@ -804,7 -857,7 +804,7 @@@ nv17_gr_ctx_regs_find_offset(struct nv1
if (nv17_gr_ctx_regs[i] == reg)
return i;
}
- nvkm_error(subdev, "unknow offset nv17_ctx_regs %d\n", reg);
- nv_error(priv, "unknown offset nv17_ctx_regs %d\n", reg);
++ nvkm_error(subdev, "unknown offset nv17_ctx_regs %d\n", reg);
return -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 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses
On 08/26/2015 01:10 PM, Jason Wang wrote:
> On 08/25/2015 07:51 PM, Michael S. Tsirkin wrote:
>> > On Tue, Aug 25, 2015 at 05:05:47PM +0800, Jason Wang wrote:
>> > We register wildcard mmio eventfd on two buses, one for KVM_MMIO_BUS
>> > and another is KVM_FAST_MMIO_BUS. This leads to issue:
>> >
>> > - kvm_io_bus_destroy() knows nothing about the devices on two buses
>> > points to a single dev. Which will lead double free [1] during exit.
>> > - wildcard eventfd ignores data len, so it was registered as a
>> > kvm_io_range with zero length. This will fail the binary search in
>> > kvm_io_bus_get_first_dev() when we try to emulate through
>> > KVM_MMIO_BUS. This will cause userspace io emulation request instead
>> > of a eventfd notification (virtqueue kick will be trapped by qemu
>> > instead of vhost in this case).
>> >
>> > Fixing this by don't register wildcard mmio eventfd on two
>> > buses. Instead, only register it in KVM_FAST_MMIO_BUS. This fixes the
>> > double free issue of kvm_io_bus_destroy(). For the arch/setups that
>> > does not utilize KVM_FAST_MMIO_BUS, before searching KVM_MMIO_BUS, try
>> > KVM_FAST_MMIO_BUS first to see it it has a match.
>> >
>> > [1] Panic caused by double free:
>> >
>> > CPU: 1 PID: 2894 Comm: qemu-system-x86 Not tainted 3.19.0-26-generic
>> > #28-Ubuntu
>> > Hardware name: LENOVO 2356BG6/2356BG6, BIOS G7ET96WW (2.56 )
>> > 09/12/2013
>> > task: 88009ae0c4b0 ti: 88020e7f task.ti: 88020e7f
>> > RIP: 0010:[] []
>> > ioeventfd_release+0x28/0x60 [kvm]
>> > RSP: 0018:88020e7f3bc8 EFLAGS: 00010292
>> > RAX: dead00200200 RBX: 8801ec19c900 RCX: 00018200016d
>> > RDX: 8801ec19cf80 RSI: ea0008bf1d40 RDI: 8801ec19c900
>> > RBP: 88020e7f3bd8 R08: 2fc75a01 R09: 00018200016d
>> > R10: c07df6ae R11: 88022fc75a98 R12: 88021e7cc000
>> > R13: 88021e7cca48 R14: 88021e7cca50 R15: 8801ec19c880
>> > FS: 7fc1ee3e6700() GS:88023e24()
>> > knlGS:
>> > CS: 0010 DS: ES: CR0: 80050033
>> > CR2: 7f8f389d8000 CR3: 00023dc13000 CR4: 001427e0
>> > Stack:
>> > 88021e7cc000 88020e7f3be8 c07e2622
>> > 88020e7f3c38 c07df69a 880232524160 88020e792d80
>> > 880219b78c00 0008 8802321686a8
>> > Call Trace:
>> > [] ioeventfd_destructor+0x12/0x20 [kvm]
>> > [] kvm_put_kvm+0xca/0x210 [kvm]
>> > [] kvm_vcpu_release+0x18/0x20 [kvm]
>> > [] __fput+0xe7/0x250
>> > [] fput+0xe/0x10
>> > [] task_work_run+0xd4/0xf0
>> > [] do_exit+0x368/0xa50
>> > [] ? recalc_sigpending+0x1f/0x60
>> > [] do_group_exit+0x45/0xb0
>> > [] get_signal+0x291/0x750
>> > [] do_signal+0x28/0xab0
>> > [] ? do_futex+0xdb/0x5d0
>> > [] ? __wake_up_locked_key+0x18/0x20
>> > [] ? SyS_futex+0x76/0x170
>> > [] do_notify_resume+0x69/0xb0
>> > [] int_signal+0x12/0x17
>> > Code: 5d c3 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48
>> > 8b 7f 20 e8 06 d6 a5 c0 48 8b 43 08 48 8b 13 48 89 df 48 89 42 08
>> > <48> 89 10 48 b8 00 01 10 00 00
>> > RIP [] ioeventfd_release+0x28/0x60 [kvm]
>> > RSP
>> >
>> > Cc: Gleb Natapov
>> > Cc: Paolo Bonzini
>> > Cc: Michael S. Tsirkin
>> > Signed-off-by: Jason Wang
>> > ---
>> > Changes from V2:
>> > - Tweak styles and comment suggested by Cornelia.
>> > Changes from v1:
>> > - change ioeventfd_bus_from_flags() to return KVM_FAST_MMIO_BUS when
>> > needed to save lots of unnecessary changes.
>> > ---
>> > virt/kvm/eventfd.c | 31 +--
>> > virt/kvm/kvm_main.c | 16 ++--
>> > 2 files changed, 23 insertions(+), 24 deletions(-)
>> >
>> > diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
>> > index 9ff4193..c3ffdc3 100644
>> > --- a/virt/kvm/eventfd.c
>> > +++ b/virt/kvm/eventfd.c
>> > @@ -762,13 +762,16 @@ ioeventfd_check_collision(struct kvm *kvm,
>> > struct _ioeventfd *p)
>> > return false;
>> > }
>> >
>> > -static enum kvm_bus ioeventfd_bus_from_flags(__u32 flags)
>> > +static enum kvm_bus ioeventfd_bus_from_args(struct kvm_ioeventfd
>> > *args)
>> > {
>> > - if (flags & KVM_IOEVENTFD_FLAG_PIO)
>> > + if (args->flags & KVM_IOEVENTFD_FLAG_PIO)
>> > return KVM_PIO_BUS;
>> > - if (flags & KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY)
>> > + if (args->flags & KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY)
>> > return KVM_VIRTIO_CCW_NOTIFY_BUS;
>> > -
Re: [RFC] watchdog: Add watchdog device control through sysfs attributes
On 29/08/2015:09:51:24 AM, Guenter Roeck wrote: > > * timeout - reads current timeout and writes to program a new timeout. Now, this is the only file which has write permission. I hope, that is fine. Pl let me know if you expected this to be as RO as well. ~Pratyush -- 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 1/3] vmx: allow ioeventfd for EPT violations
On 08/30/2015 05:12 PM, Michael S. Tsirkin wrote:
Even when we skip data decoding, MMIO is slightly slower
than port IO because it uses the page-tables, so the CPU
must do a pagewalk on each access.
This overhead is normally masked by using the TLB cache:
but not so for KVM MMIO, where PTEs are marked as reserved
and so are never cached.
As ioeventfd memory is never read, make it possible to use
RO pages on the host for ioeventfds, instead.
I like this idea.
The result is that TLBs are cached, which finally makes MMIO
as fast as port IO.
What does "TLBs are cached" mean? Even after applying the patch
no new TLB type can be cached.
Signed-off-by: Michael S. Tsirkin
---
arch/x86/kvm/vmx.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9d1bfd3..ed44026 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5745,6 +5745,11 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu)
vmcs_set_bits(GUEST_INTERRUPTIBILITY_INFO,
GUEST_INTR_STATE_NMI);
gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS);
+ if (!kvm_io_bus_write(vcpu, KVM_FAST_MMIO_BUS, gpa, 0, NULL)) {
+ skip_emulated_instruction(vcpu);
+ return 1;
+ }
+
I am afraid that the common page fault entry point is not a good place to do the
work. Would move it to kvm_handle_bad_page()? The different is the workload of
fast_page_fault() is included but it's light enough and MMIO-exit should not be
very frequent, so i think it's okay.
--
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/7] x86 vdso32 cleanups
On Sun, Aug 30, 2015 at 2:18 PM, Brian Gerst wrote: > On Sat, Aug 29, 2015 at 12:10 PM, Andy Lutomirski wrote: >> On Sat, Aug 29, 2015 at 8:20 AM, Brian Gerst wrote: >>> This patch set contains several cleanups to the 32-bit VDSO. The >>> main change is to only build one VDSO image, and select the syscall >>> entry point at runtime. >> >> Oh no, we have dueling patches! >> >> I have a 2/3 finished series that cleans up the AT_SYSINFO mess >> differently, as I outlined earlier. I've only done the compat and >> common bits (no 32-bit native support quite yet), and it enters >> successfully on Intel using SYSENTER and on (fake) AMD using SYSCALL. >> The SYSRET bit isn't there yet. >> >> Other than some ifdeffery, the final system_call.S looks like this: >> >> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/tree/arch/x86/entry/vdso/vdso32/system_call.S?h=x86/entry_compat >> >> The meat is (sorry for whitespace damage): >> >> .text >> .globl __kernel_vsyscall >> .type __kernel_vsyscall,@function >> ALIGN >> __kernel_vsyscall: >> CFI_STARTPROC >> /* >> * Reshuffle regs so that all of any of the entry instructions >> * will preserve enough state. >> */ >> pushl %edx >> CFI_ADJUST_CFA_OFFSET 4 >> CFI_REL_OFFSET edx, 0 >> pushl %ecx >> CFI_ADJUST_CFA_OFFSET 4 >> CFI_REL_OFFSET ecx, 0 >> movl %esp, %ecx >> >> #ifdef CONFIG_X86_64 >> /* If SYSENTER is available, use it. */ >> ALTERNATIVE_2 "", "sysenter", X86_FEATURE_SYSENTER32, \ >> "syscall", X86_FEATURE_SYSCALL32 >> #endif >> >> /* Enter using int $0x80 */ >> movl (%esp), %ecx >> int $0x80 >> GLOBAL(int80_landing_pad) >> >> /* Restore ECX and EDX in case they were clobbered. */ >> popl %ecx >> CFI_RESTORE ecx >> CFI_ADJUST_CFA_OFFSET -4 >> popl %edx >> CFI_RESTORE edx >> CFI_ADJUST_CFA_OFFSET -4 >> ret >> CFI_ENDPROC >> >> .size __kernel_vsyscall,.-__kernel_vsyscall >> .previous >> >> And that's it. >> >> What do you think? This comes with massively cleaned up kernel-side >> asm as well as a test case that actually validates the CFI directives. >> >> Certainly, a bunch of your patches make sense regardless, and I'll >> review them and add them to my queue soon. >> >> --Andy > > How does the performance compare to the original? Looking at the > disassembly, there are two added function calls, and it reloads the > args from the stack instead of just shuffling registers. The replacement is dramatically faster, which means I probably benchmarked it wrong. I'll try again in a day or two. --Andy -- 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 net-next] macvtap/macvlan: use IFF_NO_QUEUE
On 08/28/2015 08:25 PM, Vlad Yasevich wrote:
> On 08/27/2015 10:42 PM, Jason Wang wrote:
>> >
>> >
>> > On 08/27/2015 06:43 PM, Michael S. Tsirkin wrote:
>>> >> On Wed, Aug 26, 2015 at 01:45:30PM +0800, Jason Wang wrote:
>>>
>>> On 08/26/2015 12:32 AM, Vlad Yasevich wrote:
> On 08/25/2015 07:30 AM, Jason Wang wrote:
>> > On 08/25/2015 06:17 PM, Michael S. Tsirkin wrote:
>>> >> On Mon, Aug 24, 2015 at 04:33:12PM +0800, Jason Wang wrote:
> For macvlan, switch to use IFF_NO_QUEUE instead of
> tx_queue_len = 0.
>
> For macvtap, after commit
> 6acf54f1cf0a6747bac9fea26f34cfc5a9029523
> ("macvtap: Add support of packet capture on macvtap
> device."). Multiqueue macvtap suffers from single qdisc lock
> contention. This is because macvtap claims a non zero
> tx_queue_len and
> it reuses this value as it socket receive queue size.Thanks
> to
> IFF_NO_QUEUE, we can remove the lock contention without
> breaking
> existing socket receive queue length logic.
>
> Cc: Patrick McHardy
> Cc: Vladislav Yasevich
> Cc: Michael S. Tsirkin
> Signed-off-by: Jason Wang
>>> >> Seems to make sense. Give me a day or two to get over the jet lag
>>> >> (and get out from under the pile of mail accumulated while I was
>>> >> traveling),
>>> >> I'll review properly and ack.
>>> >>
>> > A note on this patch: only default qdisc were removed but we don't
>> > lose
>> > the ability to attach a qdisc to macvtap (though it may cause lock
>> > contention on multiqueue case).
>> >
> Wouldn't that lock contention be solved if we really had multiple
> queues
> for multi-queue macvtaps?
>
> -vlad
>>> Yes, but this introduce another layer of txq locks contention?
>>> >> I don't follow - why does it? Could you clarify please?
>> >
>> > I believe Vlad wants to remove NETIF_F_LLTX. If yes, core will do an
>> > extra tx lock at macvlan layer.
> No, I don't want to remove it. In a sense, it would function similar to
> how it works when fwd_priv is populated. I am still testing the code
> as it's showing some strange artifacts... could be due to keeping LLTX.
>
> -vlad
>
I see. I'm ok to wait for your code. But if a patch of just two lines
works, probably no need to try complex method.
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: [PATCH v3 0/14] Add Analogix Core Display Port Driver
Hi Romain, 在 08/30/2015 08:16 PM, Romain Perier 写道: Hi, Could you rebase your serie onto linux-next or 4.2-rc8 ? it does not apply here... Thanks for try to applied, and feel sorry for that failed. This v3 series was rebased on github.com/torvalds/linux.git, so I should rebase on kernel/next/linux-next.git when I'm preparing v4 series. Thanks, - Yakir Regards, Romain 2015-08-21 15:16 GMT+02:00 Thierry Reding : On Fri, Aug 21, 2015 at 08:24:16PM +0900, Jingoo Han wrote: On 2015. 8. 21., at PM 7:01, Yakir Yang wrote: Hi Jingoo, 在 2015/8/21 16:20, Jingoo Han 写道: On 2015. 8. 19., at PM 11:48, Yakir Yang wrote: . .../bindings/video/analogix_dp-rockchip.txt| 83 ++ .../devicetree/bindings/video/exynos_dp.txt| 51 +- arch/arm/boot/dts/exynos5250-arndale.dts | 10 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 10 +- arch/arm/boot/dts/exynos5250-snow.dts | 12 +- arch/arm/boot/dts/exynos5250-spring.dts| 12 +- arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 +- arch/arm/boot/dts/exynos5420-smdk5420.dts | 10 +- arch/arm/boot/dts/exynos5800-peach-pi.dts | 12 +- drivers/gpu/drm/bridge/Kconfig |5 + drivers/gpu/drm/bridge/Makefile|1 + drivers/gpu/drm/bridge/analogix_dp_core.c | 1382 +++ drivers/gpu/drm/bridge/analogix_dp_core.h | 286 drivers/gpu/drm/bridge/analogix_dp_reg.c | 1294 ++ .../exynos_dp_reg.h => bridge/analogix_dp_reg.h} | 270 ++-- drivers/gpu/drm/exynos/Kconfig |5 +- drivers/gpu/drm/exynos/Makefile|2 +- drivers/gpu/drm/exynos/analogix_dp-exynos.c| 347 + Would you change this file name to "exynos_dp.c"? Sorry, I don't think so ;( I think IP_name+Soc_name would be better in this re-use case. So? Is there the naming rule such as "IP_name+SoC_name"? Beside I see there are lots of driver named with this format in kernel, such as dw_hdmi & dw_mmc Please look at other dw cases. For example, look at dw_pcie. drivers/pci/host/ pcie-designware.c pci-spear13xx.c pci-exynos.c In this case, pci-spear13xx.c and pci-exynos.c do not use "IP_name+SoC_name", even though these are dw IPs. Also, naming consistency is more important. Now, Exynos DRM files are using "exynos_drm_" prefix. drivers/gpu/drm/exynos/ exynos_drm_buf.c exynos_drm_core.c However, "analogix_dp-exynos.c" looks very inconsistent. If there is no strict naming rule, please use "exynos_dp.c" or "exynos_drm_dp.c". Exynos DRM maintainers get to pick their filenames, so Yakir, please rename as Jingoo suggested. Even if you didn't the first thing that would go into the Exynos DRM driver tree after this is merged is a rename patch anyway. Thierry -- 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/
[BUG 4.2-rc8] Interrupt occurs while apply_alternatives() is patching the handler
This is from https://bugzilla.redhat.com/show_bug.cgi?id=1258223 [0.036000] BUG: unable to handle kernel paging request at 55501e06 [0.036000] IP: [] common_interrupt+0xb/0x38 [0.036000] *pde = [0.036000] Oops: [#1] SMP [0.036000] Modules linked in: [0.036000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-0.rc8.git3.1.fc24.i686 #1 [0.036000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.2-20150714_191134- 04/01/2014 [0.036000] task: c0d49ac0 ti: c0d42000 task.ti: c0d42000 [0.036000] EIP: 0060:[] EFLAGS: 00200046 CPU: 0 [0.036000] EIP is at common_interrupt+0xb/0x38 [0.036000] EAX: c0aae480 EBX: 008d ECX: c0ab1c83 EDX: e4af6810 [0.036000] ESI: 029a7802 EDI: 0003 EBP: c0d43e68 ESP: c0d43e44 [0.036000] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [0.036000] CR0: 8005003b CR2: 55501e06 CR3: 00ebd000 CR4: 0690 [0.036000] DR0: DR1: DR2: DR3: [0.036000] DR6: DR7: [0.036000] Stack: [0.036000] 004f c0409c80 0060 00200202 00200046 c0d43e60 c0ea150c 029a7802 [0.036000] c0d43fb8 c040a054 c07f1cf0 6c0a1000 0006 00200046 0043 [0.036000] c0ed0bc0 c0d43e98 c071a6fc c0d43ea8 c0d43ec4 c0ea4c73 c0ea4c7f [0.036000] Call Trace: [0.036000] [] ? add_nops+0x90/0xa0 [0.036000] [] apply_alternatives+0x274/0x630 [0.036000] [] ? wait_for_xmitr+0xa0/0xa0 [0.036000] [] ? sprintf+0x1c/0x20 [0.036000] [] ? irq_entries_start+0x698/0x698 [0.036000] [] ? memcpy+0xb/0x30 [0.036000] [] ? serial8250_set_termios+0x20/0x20 [0.036000] [] ? _raw_write_unlock_irqrestore+0x13/0x20 [0.036000] [] ? _raw_write_unlock_irqrestore+0x13/0x20 [0.036000] [] ? _raw_spin_unlock_irqrestore+0xd/0x10 [0.036000] [] ? console_unlock+0x2e9/0x610 [0.036000] [] ? log_store+0x1cd/0x210 [0.036000] [] ? vprintk_emit+0x29e/0x570 [0.036000] [] ? vprintk_default+0x41/0x60 [0.036000] [] ? printk+0x17/0x19 [0.036000] [] ? identify_boot_cpu+0x7b/0x80 [0.036000] [] alternative_instructions+0x17/0xc1 [0.036000] [] check_bugs+0x32/0x39 [0.036000] [] start_kernel+0x3ca/0x40a [0.036000] [] i386_start_kernel+0x91/0x95 [0.036000] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 8d 90 90 83 04 24 80 fc 0f a8 0f 06 1e 50 55 57 56 52 51 53 ba 7b 00 00 00 8e da 8e c2 ba d8 0: 8d 90 90 83 04 24 lea0x24048390(%eax),%edx 6: 80 fc 0fcmp$0xf,%ah 9: a8 0f test $0xf,%al >> b: a0 06 1e 50 55 mov0x55501e06,%al 10: 57 push %edi 11: 56 push %esi Interrupt 0x30 occurred while the alternatives code was replacing the initial 0x90,0x90,0x90 NOPs (from the ASM_CLAC macro) with the optimized version, 0x8d,0x76,0x00. Only the first byte has been replaced so far, and it makes a mess out of the insn decoding. I have no clue how to fix this. -- 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 2/5] ARM: NSP: add minimal Northstar Plus device tree
On Fri, Aug 28, 2015 at 05:20:20PM -0700, Ray Jui wrote:
>
>
> On 8/28/2015 4:47 PM, Jon Mason wrote:
> > Add a very minimalistic set of Northstar Plus Device Tree files which
> > describes the SoC and the BCM958625 implementation. The perpherials
> > described are:
> >
> > ARM Cortex A9 CPU
> > 2 8250 UARTs
> > ARM GIC
> > PL310 L2 Cache
> > ARM A9 Global timer
> >
> > Signed-off-by: Kapil Hali
> > Signed-off-by: Jon Mason
> > ---
> > arch/arm/boot/dts/Makefile | 2 +
> > arch/arm/boot/dts/bcm-nsp.dtsi | 120
> > +++
> > arch/arm/boot/dts/bcm958625k.dts | 57 +++
> > 3 files changed, 179 insertions(+)
> > create mode 100644 arch/arm/boot/dts/bcm-nsp.dtsi
> > create mode 100644 arch/arm/boot/dts/bcm958625k.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 246473a..adb5732 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -82,6 +82,8 @@ dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
> > dtb-$(CONFIG_ARCH_BCM_MOBILE) += \
> > bcm28155-ap.dtb \
> > bcm21664-garnet.dtb
> > +dtb-$(CONFIG_ARCH_BCM_NSP) += \
> > + bcm958625k.dtb
> > dtb-$(CONFIG_ARCH_BERLIN) += \
> > berlin2-sony-nsz-gs7.dtb \
> > berlin2cd-google-chromecast.dtb \
> > diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
> > new file mode 100644
> > index 000..f5f494f
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
> > @@ -0,0 +1,120 @@
> > +/*
> > + * BSD LICENSE
> > + *
> > + * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
> > + *
> > + * 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 Broadcom Corporation nor the names of its
> > + * contributors may be used to endorse or promote products derived
> > + * from this software without specific prior written permission.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> > + * "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 THE COPYRIGHT
> > + * OWNER OR CONTRIBUTORS 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 "skeleton.dtsi"
> > +
> > +/ {
> > + compatible = "brcm,nsp";
> > + model = "Broadcom Northstar Plus SoC";
> > + interrupt-parent = <>;
> > +
> > + mpcore {
> > + compatible = "simple-bus";
> > + ranges = <0x 0x1902 0x3000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu@0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a9";
> > + next-level-cache = <>;
> > + reg = <0x0>;
> > + };
> > + };
> > +
> > + L2: l2-cache {
> > + compatible = "arm,pl310-cache";
> > + reg = <0x2000 0x1000>;
> > + cache-unified;
> > + cache-level = <2>;
> > + };
> > +
> > + gic: interrupt-controller@19021000 {
> > + compatible = "arm,cortex-a9-gic";
> > + #interrupt-cells = <3>;
> > + #address-cells = <0>;
> > + interrupt-controller;
> > + reg = <0x1000 0x1000>,
> > + <0x0100 0x100>;
> > + };
> > +
> > + timer@19020200 {
> > + compatible = "arm,cortex-a9-global-timer";
> > + reg = <0x0200 0x100>;
> > + interrupts = ;
> > + clocks = <_clk>;
> > + };
> > +
~RE: [RESEND PATCH] mmc: core: fix race condition in mmc_wait_data_done
> [...]
>
Hi, ulf
We find this bug on Intel-C3230RK platform for very small probability.
Whereas I can easily reproduce this case if I add a mdelay(1) or
longer delay as Jialing did.
This patch seems useful to me. Should we push it forward? :)
>>>
>>>
>>> It seems like a very good idea!
>>>
>>> Should we add a fixes tag to it?
>>
>>
>> That's cool, but how to add a fixes tag?
>>
>> [Fixes] mmc: core: fix race condition in mmc_wait_data_done ? :)
>>
>
> A fixes tag points to an old commit which introduced the bug. If we can't
> find one, we can add a Cc tag to "stable". Just search the git log and you
> will find examples.
>
> Like add one line as below?
> Fixes: 2220eedfd7ae ("mmc: fix async request mechanism for sequential
> read scenarios")
>
That's it, Jialing. From my git blame, seems this bug has been introduced for a
long time, but I feel strange that no one had captured it before you did.
[Jialing Fu] Shawn,
Yes, this bug is very hard to duplicate in my experiment.
But it happens indeed, I had suffered this bug about 2 years before I fixed it.
Totally I got bug reports 3 times and about 3~4 Ramdump files.
At first, I failed to get useful clue and even through it was DDR stability
issue.
Below if my analysis:
As what I had commented in the fix patch, only the below "LineB" still gets
"wait" from "mrq" as the compiler's result, then this bug may be triggered.
If the compiler has some optimism which lineB doesn't need to fetch "wait" from
"mrq" again, the issue can't happen.
static void mmc_wait_data_done(struct mmc_request *mrq)
{
mrq->host->context_info.is_done_rcv = true;//LineA
// If below line still gets host from "mrq" as the result of
// compiler, the panic happens as we traced.
wake_up_interruptible(>host->context_info.wait); //LineB
}
Also, I suspect the bug may be triggered if "IRQ" or "ICache line missing" just
happen between LineA and LineB.
Especial the "Icache missing" case, it is easier to happens than IRQ.
I disassemble my code, and find LineA and LineB's assemble codes are located in
two different cache line in my fail case. If you are interesting, you can check
your assemble code too.
Anyway, I will add a fixes tag and send v2 ASAP. :)
>
> Kind regards
> Uffe
>
--
Best Regards
Shawn Lin
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
On Fri, Aug 28, 2015 at 09:42:56AM -0500, Nathan Sullivan wrote: > On Fri, Aug 28, 2015 at 09:30:12AM +0800, Peter Chen wrote: > > On Thu, Aug 27, 2015 at 09:33:07AM -0500, Nathan Sullivan wrote: > > > On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary kalluri wrote: > > > > Hi, > > > > > > > > On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen > > > > wrote: > > > > > On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote: > > > > >> Hi, > > > > >> > > > > >> > > > > >> On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan > > > > >> wrote: > > > > >> > The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING > > > > >> > flag, > > > > >> > unlike the default platform data. Add platform data specific to > > > > >> > the > > > > >> > Zynq udc. > > > > >> > > > > > >> > Based on a patch by the same name from the Xilinx vendor tree. > > > > >> > > > > >> I am that Xilinx guy who sent this patch :). It is in Xilinx tree as > > > > >> temporary fix and > > > > >> I did not debug further why UDC works only when streaming is enabled. > > > > >> Probably this is right time to post my question here. > > > > >> I was expecting like: > > > > >> Streaming disabled - both low bandwidth and high bandwidth systems > > > > >> should work fine > > > > >> Streaming enabled - only for high bandwidth systems > > > > >> but this is not the case, Zynq UDC works only when Streaming is > > > > >> enabled. > > > > >> Please correct me if I am wrong. > > > > > > > > > > You are right, stream mode disabled should work at anytime. > > > > > It is so strange why zynq UDC only works when stream mode is enabled. > > > > > > > > I am referring the section 8.5.2 in Synopsys usb 2.0 HS controllervDoc > > > > 2.20a, > > > > this is what it says about SDIS (streaming mode disable option) > > > > > > > > Before activating this mode, the user must check if the TX latency > > > > buffers per endpoint are able to > > > > accommodate at least one entire maximum size packet. The RX buffer > > > > size must, at least, double the TX > > > > buffer size per endpoint. To optimize the stream disable performance, > > > > system bus burst must be set as high > > > > as possible. > > > > When the stream disable mode is used, the burst size (VUSB_HS_RX_BURST > > > > and VUSB_HS_TX_BURST) > > > > must be a integer sub-multiple of the latency buffer size > > > > (VUSB_HS_RX_DEPTH for RX buffer and > > > > VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the > > > > controller will not work properly in stream > > > > disable mode. > > > > The stream disable mode should just be used in situations where the > > > > available system bandwidth is low or the > > > > system bus access latency is high, in order to avoid underruns and > > > > overruns in the latency buffers. This works > > > > for all types of endpoints, except for ISO endpoints. > > > > Such a system can't ensure the real time support that the ISO > > > > endpoints require, so the ISO endpoints are not > > > > supported when the SDIS bit is set. > > > > > > > > Definitely we need to root cause why disable streaming mode is not > > > > working for zynq but from controller spec > > > > point of view it is possible that controller not work properly in > > > > stream disable mode. > > > > > > > > Regards, > > > > Punnaiah > > > > > > > > > > Maybe the burst size isn't set correctly by default? It does say the > > > controller > > > won't work correctly with stream disable set and an invalid burst size. > > > Looks > > > like TX and RX burst both default to 16, per the Zynq manual. > > > > > > With the stream disable bit set, the behvior we see on our hardware is > > > that priming just stops, with an outstanding transfer in memory marked > > > active in the status field by the controller. This happens at random, > > > even > > > when doing single transfers at a time like with g_ether set to have a > > > queue > > > size of 1. With SDIS clear everything works great. Given that the Zynq > > > is not > > > bandwidth constrained, it seems like SDIS clear should be the default. > > > > > > > I suspect the possible reason is the tx buffer for each endpoint is > > small (<=512 bytes), so it can't copy one packet (assume max packet size > > for bulk) to tx buffer, then the prime can't be finished. > > > > Would you help to dump the registers HWTXBUF ($BASE + 0x10) and DCCPARAMS > > ($BASE + 124)? > > > > tx buffer size = ((2 ^ HWTXBUF.VUSB_HS_TX_ADD) / DCCPARAMS.DEN) * > > (DWORD_PER_BYTES) > > > > DWORD_PER_BYTES is 4 > > > > -- > > > > Best Regards, > > Peter Chen > > HWTXBUF is 0x80060A10, DCCPARAMS is 0xE0003124. Are you sure you read correct address? Your DCCPARAMS means it is host capable, but not device capable. -- Best Regards, Peter Chen -- 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
[PATCH] Input: elan_i2c - Recovery exception ic type
When driver get exception ic type (0xFF), maybe occurred from wrong I2C protocol communication, system crash or other unknown situation, we need to reset ic type from iap_version. --- drivers/input/mouse/elan_i2c_core.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c index 5b5f403..39d9929 100644 --- a/drivers/input/mouse/elan_i2c_core.c +++ b/drivers/input/mouse/elan_i2c_core.c @@ -4,7 +4,7 @@ * Copyright (c) 2013 ELAN Microelectronics Corp. * * Author: 林政維 (Duson Lin) - * Version: 1.5.9 + * Version: 1.6.0 * * Based on cyapa driver: * copyright (c) 2011-2012 Cypress Semiconductor, Inc. @@ -40,7 +40,7 @@ #include "elan_i2c.h" #define DRIVER_NAME"elan_i2c" -#define ELAN_DRIVER_VERSION"1.5.9" +#define ELAN_DRIVER_VERSION"1.6.0" #define ETP_MAX_PRESSURE 255 #define ETP_FWIDTH_REDUCE 90 #define ETP_FINGER_WIDTH 15 @@ -247,15 +247,19 @@ static int elan_query_device_info(struct elan_tp_data *data) if (error) return error; - error = data->ops->get_sm_version(data->client, >ic_type, - >sm_version); + error = data->ops->get_version(data->client, true, >iap_version); if (error) return error; - error = data->ops->get_version(data->client, true, >iap_version); + error = data->ops->get_sm_version(data->client, >ic_type, + >sm_version); if (error) return error; + /* exception type, need reset from iap_version */ + if (data->ic_type == 0xFF) + data->ic_type = data->iap_version; + error = data->ops->get_pressure_adjustment(data->client, >pressure_adjustment); if (error) -- 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] btrfs: Remove unneeded cast to s64 for qgroup rfer state
Alexandru Moise wrote on 2015/08/29 11:45 +:
This patch reverts commit: b4fcd6be6bbd702ae1a6545c9b413681850a9814
Wang Shilong added those casts as a workaround for a bug reproduced
using the following steps:
Steps to reproduce:
mkfs.btrfs
mount
dd if=/dev/zero of=//data bs=1M count=10
sync
btrfs quota enable
btrfs qgroup create 0/5
btrfs qgroup limit 5M 0/5
rm -f //data
sync
btrfs qgroup show
dd if=/dev/zero of=data bs=1M count=1
>From the perspective of users, qgroup's referenced or exclusive
is negative,but user can not continue to write data! a workaround
way is to cast u64 to s64 when doing qgroup reservation
I am unable to reproduce this problem without his modification.
I could be wrong in reverting this, so I'm gonna CC Wang as well so
he is aware of this patch.
The cast is a workaround for a quite old qgroup bug, which will cause
excl/rfer overflow to minus.
The remove of cast rfer/exel now is OK, as qgroup keeps maturing,
especially after 4.2-rc1 rfer/exel will keep sane under most case
(exception will be qgroup reassign and subvolume deletion, but will not
case minus value even under than case).
But I'm not a fan to remove it now.
As qgroup still has a known huge bug for the qg->reserved part, we are
aware of it and working on it actively.
So for such cleanup, I'd prefer to do it when we rework the accounting
part of qgroup.
Thanks,
Qu
Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
---
fs/btrfs/qgroup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index 8a82029..9c75e86 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -2077,14 +2077,14 @@ int btrfs_qgroup_reserve(struct btrfs_root *root, u64
num_bytes)
qg = u64_to_ptr(unode->aux);
if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_RFER) &&
- qg->reserved + (s64)qg->rfer + num_bytes >
+ qg->reserved + qg->rfer + num_bytes >
qg->max_rfer) {
ret = -EDQUOT;
goto out;
}
if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_EXCL) &&
- qg->reserved + (s64)qg->excl + num_bytes >
+ qg->reserved + qg->excl + num_bytes >
qg->max_excl) {
ret = -EDQUOT;
goto out;
--
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: timing of module MODULE_STATE_COMING notifier
"Frank Ch. Eigler" writes: > Hi, Rusty - > > We just [1] came across your patch [2] from last year (merged into > 3.17), wherein the RO/NX mapping settings for module sections were > moved to an earlier point in the module-loading sequence. > > That patch also moved the MODULE_STATE_COMING notifier call to > complete_formation(), which is relatively early to its former > do_init_module() call site. It now precedes the parse_args(), > mod_sysfs_setup(), and trace_module_load() steps. Yes, parse_args() can enter the module, so you really want it before then. > Was the latter part of the change intended & necessary? It is > negatively impacting systemtap, which was relying on > MODULE_STATE_COMING being called from a fairly complete module state - > just before the actual initializer function call. Notifiers suck for stuff like this :( Module state has many steps, so my preference has been to open-code explicit hooks. This would seem to reinforce that preference... Thanks, Rusty. -- 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: [PATCHv4 3/7] zsmalloc: use page->private instead of page->first_page
On (08/27/15 16:59), Kirill A. Shutemov wrote: > We are going to rework how compound_head() work. It will not use > page->first_page as we have it now. > > The only other user of page->first_page beyond compound pages is > zsmalloc. > > Let's use page->private instead of page->first_page here. It occupies > the same storage space. > > Signed-off-by: Kirill A. Shutemov > Acked-by: Vlastimil Babka Reviewed-by: Sergey Senozhatsky -ss -- 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: [15/15] MAINTAINERS: change the maintainer of fam15h_power driver
On Sat, Aug 29, 2015 at 09:33:54AM -0700, Guenter Roeck wrote: > On Thu, Aug 27, 2015 at 04:07:46PM +0800, Huang Rui wrote: > > Andreas Herrmann won't take the maintainer of fam15h_power driver. I > > will take it and appreciate him for the great contributions on this > > driver. > > > > Signed-off-by: Huang Rui > > Cc: Andreas Herrmann > > Please add Andreas to CREDITS. > OK. N: Andreas Herrmann E: herrmann.der.u...@gmail.com E: herrmann.der.u...@googlemail.com D: Key developer of x86/AMD64 D: Author of AMD family 15h processor power monintoring driver D: Maintainer of AMD Athlon 64 and Opteron processor frequency driver S: Germany Andreas, Boris, how about above description at CREDITS? Please let me know if I something is wrong or missed. BTW, could you give your snail-mail address? I just know Germany :) Thanks, Rui > Andreas, can you Ack this change ? > > Thanks, > Guenter > > > --- > > MAINTAINERS | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 941d7b7..241d45e 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -601,9 +601,9 @@ F: drivers/crypto/ccp/ > > F: include/linux/ccp.h > > > > AMD FAM15H PROCESSOR POWER MONITORING DRIVER > > -M: Andreas Herrmann > > +M: Huang Rui > > L: lm-sens...@lm-sensors.org > > -S: Maintained > > +S: Supported > > F: Documentation/hwmon/fam15h_power > > F: drivers/hwmon/fam15h_power.c > > -- 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: wake_up_process implied memory barrier clarification
Hi Oleg, On Sat, Aug 29, 2015 at 04:27:07PM +0200, Oleg Nesterov wrote: > Hello Boqun, > ... > > By this, I think you actually means the example below the added text, > > i.e. the example for "to repeat..", right? > > And above. Even > > The barrier occurs before the task state is cleared > > is not actually right. This is misleading. What is really important is that > we have a barrier before we _read_ the task state. And again, again, the > fact that we actually have the write barrier is just the implementation > detail. > Yes, agree with you. However, I didn't realize this problem before, I will see what I can do ;-) > > Subject: Documentation: call out conditional barriers of wait_*() and > > wake_up*() > > > > The memory barriers in some sleep and wakeup functions are conditional, > > there are several situations that there is no barriers: > > > > 1. If wait_event() and co. actually don't prepare to sleep, there > > may be no barrier in them. > > And thus (imo) we should not even try to document this. I mean, a user > should not make any assumptions about the barriers inside wait_event(). > Yep. > > 2. No matter whether a sleep occurs or not, there may be no barrier > > between a successful wait-condition checking(the result of which > > is true) in wait_event() and the following instructions. > > Yes, this is true in any case. Not sure this deserves addtionional > documentation, but see below. > > > 3. If wake_up() and co. actually wake up no one, there may be no > > write barrier in them. > > See above. > > > --- a/Documentation/memory-barriers.txt > > +++ b/Documentation/memory-barriers.txt > > @@ -1975,7 +1975,8 @@ set_current_state() may be wrapped by: > > > > which therefore also imply a general memory barrier after setting the > > state. > > The whole sequence above is available in various canned forms, all of which > > -interpolate the memory barrier in the right place: > > +imply a general barrier if and only if a sleep is at least about to happen, > > +i.e. prepare_to_wait*() is called. > > > > wait_event(); > > wait_event_interruptible(); > > @@ -1986,6 +1987,9 @@ interpolate the memory barrier in the right place: > > wait_on_bit(); > > wait_on_bit_lock(); > > > > +Further more, no barrier is guaranteed after the successful wait condition > > +checkings, whose results are true, in wait_*() and before the instructions > > +following wait_*(). > > Yes, perhaps this makes sense, but (to me) only because the explanation above > looks a bit confusing to me. I simply can't understand why memory-barriers.txt > mentions that barrier implied by set_current_state(). You need to know this > if you want to understand how wait_event() works. You do not need to know > about this barrier if you want to use wait_event(). If nothing else, because > you can never rely on this barrier. Anf your examples below shows this. > Fair enough, I went too far. How about just a single paragraph saying that: The wake_up(), wait_event() and their friends have proper barriers in them, but these implicity barriers are only for the correctness for sleep and wakeup. So don't rely on these barriers for things that are neither wait-conditons nor task states. Is that OK to you? Thank you for your comments ;-) Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH] x86/paravirt: remove unused operation
Juergen Gross writes:
> Ping?
Acked-by: Rusty Russell
Cheers,
Rusty.
> On 08/06/2015 01:55 PM, Juergen Gross wrote:
>> Remove the paravirt operation "get_tsc_khz" as it is used nowhere.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> arch/x86/include/asm/paravirt_types.h | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/x86/include/asm/paravirt_types.h
>> b/arch/x86/include/asm/paravirt_types.h
>> index a6b8f9f..5a18a66 100644
>> --- a/arch/x86/include/asm/paravirt_types.h
>> +++ b/arch/x86/include/asm/paravirt_types.h
>> @@ -97,7 +97,6 @@ struct pv_lazy_ops {
>> struct pv_time_ops {
>> unsigned long long (*sched_clock)(void);
>> unsigned long long (*steal_clock)(int cpu);
>> -unsigned long (*get_tsc_khz)(void);
>> };
>>
>> struct pv_cpu_ops {
>>
--
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/
timing of module MODULE_STATE_COMING notifier
Hi, Rusty - We just [1] came across your patch [2] from last year (merged into 3.17), wherein the RO/NX mapping settings for module sections were moved to an earlier point in the module-loading sequence. That patch also moved the MODULE_STATE_COMING notifier call to complete_formation(), which is relatively early to its former do_init_module() call site. It now precedes the parse_args(), mod_sysfs_setup(), and trace_module_load() steps. Was the latter part of the change intended & necessary? It is negatively impacting systemtap, which was relying on MODULE_STATE_COMING being called from a fairly complete module state - just before the actual initializer function call. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=18889 [2] commit 4982223e51e8ea9d09bb33c8323b5ec1877b2b51 Author: Rusty Russell Date: Wed May 14 10:54:19 2014 +0930 - FChE -- 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: [GIT PULL] TTY/Serial patches for 4.3-rc1
Hi Linus, On Fri, 21 Aug 2015 09:57:33 +1000 Stephen Rothwell wrote: > > On Thu, 20 Aug 2015 12:11:21 -0700 Greg KH wrote: > > > > All have been in linux-next with no reported issues. > > Except see below. > > > Eduardo Valentin (4): > > serial: imx: introduce serial_imx_enable_wakeup() > > I reported that this commit breaks the arm multi_v7_defconfig build and > I have seen no fix applied. > > I have been applying the following patch for a few days but do not know > if it is the correct resolution: Just a reminder that if you pull in Greg's tty tree before he returns from whereever he is, it need the patch below to fix the build. From: Stephen Rothwell Date: Tue, 18 Aug 2015 15:56:40 +1000 Subject: [PATCH] serial: imx: partial revert of "introduce serial_imx_enable_wakeup()" This reverts the part of commit 189550b8644e that affects arch/arm/boot/dts/Makefile Signed-off-by: Stephen Rothwell --- arch/arm/boot/dts/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index d3ee1f01ffc7..233159d2eaab 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -330,7 +330,6 @@ dtb-$(CONFIG_SOC_IMX6Q) += \ imx6q-wandboard-revb1.dtb dtb-$(CONFIG_SOC_IMX6SL) += \ imx6sl-evk.dtb \ - imx6sl-fox-p1.dtb \ imx6sl-warp.dtb dtb-$(CONFIG_SOC_IMX6SX) += \ imx6sx-sabreauto.dtb \ -- 2.5.0 -- Cheers, Stephen Rothwells...@canb.auug.org.au -- 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] power: Remove unnecessary MODULE_ALIAS() for I2C drivers
These drivers already have an I2C device id table that is used to create
module aliases and the used MODULE_ALIAS() was either already in the I2C
table so it was redundant or wasn't a valid I2C id so it was never used.
Signed-off-by: Javier Martinez Canillas
---
drivers/power/bq24190_charger.c | 1 -
drivers/power/bq27x00_battery.c | 4
drivers/power/pm2301_charger.c | 1 -
drivers/power/rt9455_charger.c | 1 -
drivers/power/smb347-charger.c | 1 -
5 files changed, 8 deletions(-)
diff --git a/drivers/power/bq24190_charger.c b/drivers/power/bq24190_charger.c
index 469a452cbe10..f5746b9f4e83 100644
--- a/drivers/power/bq24190_charger.c
+++ b/drivers/power/bq24190_charger.c
@@ -1543,5 +1543,4 @@ module_i2c_driver(bq24190_driver);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Mark A. Greer ");
-MODULE_ALIAS("i2c:bq24190-charger");
MODULE_DESCRIPTION("TI BQ24190 Charger Driver");
diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c
index 8287261fd978..d0b2f3b47b8f 100644
--- a/drivers/power/bq27x00_battery.c
+++ b/drivers/power/bq27x00_battery.c
@@ -1120,10 +1120,6 @@ module_exit(bq27x00_battery_exit);
MODULE_ALIAS("platform:bq27000-battery");
#endif
-#ifdef CONFIG_BATTERY_BQ27X00_I2C
-MODULE_ALIAS("i2c:bq27000-battery");
-#endif
-
MODULE_AUTHOR("Rodolfo Giometti ");
MODULE_DESCRIPTION("BQ27x00 battery monitor driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/power/pm2301_charger.c b/drivers/power/pm2301_charger.c
index 3a45cc0c4dce..8f9bd1d0eeb6 100644
--- a/drivers/power/pm2301_charger.c
+++ b/drivers/power/pm2301_charger.c
@@ -1264,5 +1264,4 @@ module_exit(pm2xxx_charger_exit);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Rajkumar kasirajan, Olivier Launay");
-MODULE_ALIAS("i2c:pm2xxx-charger");
MODULE_DESCRIPTION("PM2xxx charger management driver");
diff --git a/drivers/power/rt9455_charger.c b/drivers/power/rt9455_charger.c
index a49a9d44bdda..cfdbde9daf94 100644
--- a/drivers/power/rt9455_charger.c
+++ b/drivers/power/rt9455_charger.c
@@ -1760,5 +1760,4 @@ module_i2c_driver(rt9455_driver);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Anda-Maria Nicolae ");
-MODULE_ALIAS("i2c:rt9455-charger");
MODULE_DESCRIPTION("Richtek RT9455 Charger Driver");
diff --git a/drivers/power/smb347-charger.c b/drivers/power/smb347-charger.c
index 0b60a0b5878b..072c5189bd6d 100644
--- a/drivers/power/smb347-charger.c
+++ b/drivers/power/smb347-charger.c
@@ -1332,4 +1332,3 @@ MODULE_AUTHOR("Bruce E. Robertson
");
MODULE_AUTHOR("Mika Westerberg ");
MODULE_DESCRIPTION("SMB347 battery charger driver");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("i2c:smb347");
--
2.4.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 2/2] mfd: rt5033: Remove unnecessary MODULE_ALIAS()
The driver has a I2C device id table that is used to create the module
aliases which already contains a "rt5033". So the alias is not needed.
Signed-off-by: Javier Martinez Canillas
---
drivers/mfd/rt5033.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
index d60f91619c4a..110de2a583af 100644
--- a/drivers/mfd/rt5033.c
+++ b/drivers/mfd/rt5033.c
@@ -137,7 +137,6 @@ static struct i2c_driver rt5033_driver = {
};
module_i2c_driver(rt5033_driver);
-MODULE_ALIAS("i2c:rt5033");
MODULE_DESCRIPTION("Richtek RT5033 multi-function core driver");
MODULE_AUTHOR("Beomho Seo ");
MODULE_LICENSE("GPL");
--
2.4.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] mfd: bcm590xx: Remove unnecessary MODULE_ALIAS()
The driver has a I2C device id table that is used to create the module
aliases and also "bcm590xx" isn't a supported I2C id, so it's never used.
Signed-off-by: Javier Martinez Canillas
---
drivers/mfd/bcm590xx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
index da2af5b4f855..320aaefee718 100644
--- a/drivers/mfd/bcm590xx.c
+++ b/drivers/mfd/bcm590xx.c
@@ -128,4 +128,3 @@ module_i2c_driver(bcm590xx_i2c_driver);
MODULE_AUTHOR("Matt Porter ");
MODULE_DESCRIPTION("BCM590xx multi-function driver");
MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("i2c:bcm590xx");
--
2.4.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/
Re: Build regressions/improvements in v4.2
On Sun, Aug 30, 2015 at 11:05:23PM +0200, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v4.2[1] compared to v4.1[2]. > > Summarized: > - build errors: +8/-53 > - build warnings: +127/-265 > > JFYI, when comparing v4.2[1] to v4.2-rc8[3], the summaries are: > - build errors: +0/-3 > - build warnings: +27/-30 > Here are my results, from http://server.roeck-us.net:8010/builders: Build results: total: 145 pass: 145 fail: 0 Qemu test results: total: 85 pass: 84 fail: 1 Failed tests: mips:fuloong2e_defconfig [1] Guenter --- [1] https://patchwork.linux-mips.org/patch/10896/ -- 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/
[GIT PULL] hwmon updates for v4.3
Hi Linus,
Please pull hwmon updates for Linux v4.3 from signed tag:
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
hwmon-for-linus-v4.3
Thanks,
Guenter
--
The following changes since commit f7644cbfcdf03528f0f450f3940c4985b2291f49:
Linux 4.2-rc6 (2015-08-09 15:54:30 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
tags/hwmon-for-linus-v4.3
for you to fetch changes up to 1ed32160dba643e61504b334f45b002198c88254:
hwmon: (fam15h_power) Add ratio of Tsample to the PTSC period (2015-08-27
07:53:19 -0700)
hwmon updates for v4.3 commit window
Notable changes:
Added support for LTM4675, LTC3886, LTC2980, LTM2987, LTC2975,
LTC3887, LTC3882, MAX20751, ADM1293, and ADM1294 to PMBus drivers.
Added support for IT8732F to it87 driver.
Added support for AMD Carrizo to fam15h_power driver.
Added support for various new attributes to nct7802 driver.
Added support for F81866 and F71868 to f71882fg driver.
Axel Lin (2):
hwmon: (pmbus) Explicitly set regulator type for pmbus_regulator_ops
hwmon: (pmbus_core) Constify pmbus_regulator_ops
Constantine Shulyupin (5):
hwmon: (nct7802) add temperature sensor type attribute
hwmon: (nct7802) Add pwm control
hwmon: (nct7802) Add pwm mode attributes
hwmon: (nct7802) Add pwmX_enable attribute
hwmon: (nct7802) Add auto_point attributes
George Joseph (1):
hwmon: (f71882fg) Add support for f81768d
Guenter Roeck (24):
hwmon: (adm1275) Use BIT macro
hwmon: (adm1275) Introduce configuration data structure for coeffcients
hwmon: (adm1275) Introduce new feature flags
hwmon: (pmbus) Add support for lowest power value attributes
hwmon: (adm1275) Add support for ADM1293 and ADM1294
hwmon: (ltc2978) LTM4676 supports CLEAR_PEAKS
hwmon: (pmbus) Add support for VR12
hwmon: (pmbus) Add support for MAX20751
hwmon: (pmbus) Add device IDs for TPS544{B,C}2{0,5}
hwmon: (ltc2978) Move code to read chip ID into separate function
hwmon: (ltc2978) Add support for LTC3882
hwmon: (ltc2978) Add additional chip IDs for LTM4676 and LTM4676A
hwmon: (ltc2978) Add support for LTC3887
hwmon: (ltc2978) Add support for LTC2975
hwmon: (pmbus) Convert command register definitions to enum
hwmon: (ltc2978) Introduce feature flags
hwmon: (ltc2978) Introduce helper functions for min and max values
hwmon: (ltc2978) Use correct ID mask to detect all chips
hwmon: (ltc2978) Add missing chip IDs for LTC2978 and LTC3882
hwmon: (ltc2978) Add support for LTC2980 and LTM2987
hwmon: (ltc2978) Add support for LTC3886
hwmon: (pmbus) Use BIT macro
hwmon: (pmbus) Enable PEC if the controller supports it
hwmon: (ltc2978) Add support for LTM4675
Huang Rui (5):
hwmon: (fam15h_power) Add support for AMD Carrizo
hwmon: (fam15h_power) Rename fam15h_power_is_internal_node0 function
hwmon: (fam15h_power) Update running_avg_capture bit field to 28
hwmon: (fam15h_power) Add documentation for new processors support
hwmon: (fam15h_power) Add ratio of Tsample to the PTSC period
Justin Maggard (1):
hwmon: (it87) Add support for IT8732F
Krzysztof Kozlowski (1):
hwmon: (g762) Drop owner assignment from struct i2c_driver
Michael Jones (1):
hwmon: (ltc2978) Add polling for chips requiring it
Peter Hung (3):
hwmon: (f71882fg) Add support for F81866 and F71868
hwmon: (f71882fg) Fix f81866a temp/beep setting
hwmon:(f71882fg) Fix f81866a voltage protection
Rabin Vincent (1):
hwmon: (lm70) add device tree support
yalin wang (1):
hwmon:change sht15_reverse()
Documentation/devicetree/bindings/hwmon/lm70.txt | 21 +
.../devicetree/bindings/hwmon/ltc2978.txt | 12 +-
Documentation/hwmon/adm1275| 40 +-
Documentation/hwmon/fam15h_power | 10 +-
Documentation/hwmon/it87 | 35 +-
Documentation/hwmon/ltc2978| 132 --
Documentation/hwmon/max20751 | 77
Documentation/hwmon/nct7802| 3 +-
Documentation/hwmon/pmbus | 8 +-
MAINTAINERS| 7 +
drivers/hwmon/Kconfig | 4 +-
drivers/hwmon/f71882fg.c | 176 ++--
drivers/hwmon/fam15h_power.c | 36 +-
drivers/hwmon/g762.c | 1 -
drivers/hwmon/it87.c | 43 +-
drivers/hwmon/lm70.c | 34 +-
drivers/hwmon/nct7802.c| 317 +-
drivers/hwmon/pmbus/Kconfig
[PATCH v1] Documentation: add Device tree bindings for hwmon/nct7802
reg-init implementation is borowerd from
broadcom,c45-reg-init and marvell,reg-init.
Signed-off-by: Constantine Shulyupin
---
---
.../devicetree/bindings/hwmon/nct7802.txt | 27 ++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/nct7802.txt
diff --git a/Documentation/devicetree/bindings/hwmon/nct7802.txt
b/Documentation/devicetree/bindings/hwmon/nct7802.txt
new file mode 100644
index 000..fa83628
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/nct7802.txt
@@ -0,0 +1,27 @@
+Nuvoton NCT7802Y Hardware Monitoring IC
+
+Required node properties:
+
+ - "compatible": must be "nuvoton,nct7802"
+ - "reg": I2C bus address of the device
+
+Optional properties:
+
+Numeric registors initialiaztion:
+
+- nct7802,reg-init : one of more sets of 4 cells. The first cell
+ is the page address, the second a register address within the page,
+ the third cell contains a mask to be ANDed with the existing register
+ value, and the fourth cell is ORed with the result to yield the
+ new register value. If the third cell has a value of zero,
+ no read of the existing value is performed.
+
+Example nct7802 node:
+
+nct7802 {
+ compatible = "nuvoton,nct7802";
+ reg = <0x2a>;
+ nct7802,reg-init =
+ <0 0x21 0 0x01 > // START = 1
+ <0 0x22 0x03 0x02>; // RTD1_MD = 2
+};
--
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] misc: ad525x_dpot: Remove unnecessary MODULE_ALIAS()
The driver has a I2C device id table that is used to create the module
aliases and also "ad_dpot" isn't a supported I2C id, so it's never used.
Signed-off-by: Javier Martinez Canillas
---
drivers/misc/ad525x_dpot-i2c.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/misc/ad525x_dpot-i2c.c b/drivers/misc/ad525x_dpot-i2c.c
index d11187d36ddd..4f832002d116 100644
--- a/drivers/misc/ad525x_dpot-i2c.c
+++ b/drivers/misc/ad525x_dpot-i2c.c
@@ -117,4 +117,3 @@ module_i2c_driver(ad_dpot_i2c_driver);
MODULE_AUTHOR("Michael Hennerich ");
MODULE_DESCRIPTION("digital potentiometer I2C bus driver");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("i2c:ad_dpot");
--
2.4.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] gpio: sx150x: Remove unnecessary MODULE_ALIAS()
The driver has a I2C device id table that is used to create the module
aliases and also "sx150x" isn't a supported I2C id, so it's never used.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpio/gpio-sx150x.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpio/gpio-sx150x.c b/drivers/gpio/gpio-sx150x.c
index 458d9d7952b8..9c6b96707c9f 100644
--- a/drivers/gpio/gpio-sx150x.c
+++ b/drivers/gpio/gpio-sx150x.c
@@ -706,4 +706,3 @@ module_exit(sx150x_exit);
MODULE_AUTHOR("Gregory Bean ");
MODULE_DESCRIPTION("Driver for Semtech SX150X I2C GPIO Expanders");
MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("i2c:sx150x");
--
2.4.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] Staging: ste_rmi4: Remove unnecessary MODULE_ALIAS()
The driver has a I2C device id table that is used to create the modaliases
which already contains "synaptics_rmi4_ts". So the alias is not needed.
Signed-off-by: Javier Martinez Canillas
---
drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
index 1f9ba8beb061..824d460911ec 100644
--- a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
+++ b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
@@ -1138,4 +1138,3 @@ module_i2c_driver(synaptics_rmi4_driver);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("naveen.gaddip...@stericsson.com, js...@stericsson.com");
MODULE_DESCRIPTION("synaptics rmi4 i2c touch Driver");
-MODULE_ALIAS("i2c:synaptics_rmi4_ts");
--
2.4.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/
Re: [PATCH] lib: Make _find_next_bit helper function inline
I've lost track of what's up and down in this, but now that I look at this again let me throw in my two observations of stupid gcc behaviour: For the current code, both debian's gcc (4.7) and 5.1 partially inlines _find_next_bit, namely the "if (!nbits || start >= nbits)" test. I know it does it to avoid a function call, but in this case the early return condition is unlikely, so there's not much to gain. Moreover, it fails to optimize the test to simply "if (start >= nbits)" - everything being unsigned, these are obviously equivalent. Rasmus -- 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/
linux-next: bad base of the h8300 tree
Hi Yoshinori, The h8300 tree today has been based on linux-next. This cannto work. Please rebase this onto Linus' tree (or some other stable base). I cannot use your tree in this state, so it will be dropped from linux-next until it is fixed. Also, Linus cannot pull it in this state. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- 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] serial: sc16is7xx: Remove unnecessary MODULE_ALIAS()
The driver has a I2C device id table that is used to create the modaliases
and also "sc16is7xx" is not a supported I2C id, so it's never used.
Signed-off-by: Javier Martinez Canillas
---
drivers/tty/serial/sc16is7xx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 72ffd0dcab78..c4abd7557b35 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1420,7 +1420,6 @@ static struct i2c_driver sc16is7xx_i2c_uart_driver = {
.id_table = sc16is7xx_i2c_id_table,
};
-MODULE_ALIAS("i2c:sc16is7xx");
#endif
static int __init sc16is7xx_init(void)
--
2.4.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] backlight: adp8860: Remove unnecessary MODULE_ALIAS()
The driver has a I2C device id table that is used to create the modaliases
and also "adp8860-backlight" is not a supported I2C id, so it's never used.
Signed-off-by: Javier Martinez Canillas
---
drivers/video/backlight/adp8860_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/adp8860_bl.c
b/drivers/video/backlight/adp8860_bl.c
index 71147f4461b8..98ffe71e8af2 100644
--- a/drivers/video/backlight/adp8860_bl.c
+++ b/drivers/video/backlight/adp8860_bl.c
@@ -819,4 +819,3 @@ module_i2c_driver(adp8860_driver);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Michael Hennerich ");
MODULE_DESCRIPTION("ADP8860 Backlight driver");
-MODULE_ALIAS("i2c:adp8860-backlight");
--
2.4.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 2/2] backlight: adp8870: Remove unnecessary MODULE_ALIAS()
The driver has a I2C device id table that is used to create the modaliases
and also "adp8870-backlight" is not a supported I2C id, so it's never used.
Signed-off-by: Javier Martinez Canillas
---
drivers/video/backlight/adp8870_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/adp8870_bl.c
b/drivers/video/backlight/adp8870_bl.c
index 037e43083343..9d738352d7d4 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -992,4 +992,3 @@ module_i2c_driver(adp8870_driver);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Michael Hennerich ");
MODULE_DESCRIPTION("ADP8870 Backlight driver");
-MODULE_ALIAS("i2c:adp8870-backlight");
--
2.4.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/
Re: [2/2] cxl: Fix force unmapping mmaps of contexts allocated through the kernel api
On Thu, 2015-27-08 at 09:50:19 UTC, Ian Munsie wrote: > From: Ian Munsie > > The cxl user api uses the address_space associated with the file when we > need to force unmap all cxl mmap regions (e.g. on eeh, driver detach, > etc). Currently, contexts allocated through the kernel api do not do > this and instead skip the mmap invalidation, potentially allowing them > to poke at the hardware after such an event, which may cause all sorts > of trouble. > > This patch allocates an address_space for cxl contexts allocated through > the kernel api so that the same invalidate path will for these contexts > as well. We don't use the anonymous inode's address_space, as doing so > could invalidate any mmaps of completely unrelated drivers using > anonymous file descriptors. > > This patch also introduces a kernelapi flag, so we know when freeing the > context if the address_space was allocated by us and needs to be freed. > > Signed-off-by: Ian Munsie Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/55e07668fbba9466e6a9ef76 cheers -- 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: [1/2] cxl: Fix + cleanup error paths in cxl_dev_context_init
On Thu, 2015-27-08 at 09:50:18 UTC, Ian Munsie wrote: > From: Ian Munsie > > If the cxl_context_alloc() call fails, we return immediately without > releasing the reference on the AFU device, allowing it to leak. > > This patch switches to using goto style error handling so that the > device is released in common code for both error paths, and will also > simplify things if we add additional initialisation in this function in > the future. > > Signed-off-by: Ian Munsie Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/af2a50bb0ce1ca7a9c478481 cheers -- 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/7] x86 vdso32 cleanups
On Sat, Aug 29, 2015 at 12:10 PM, Andy Lutomirski wrote: > On Sat, Aug 29, 2015 at 8:20 AM, Brian Gerst wrote: >> This patch set contains several cleanups to the 32-bit VDSO. The >> main change is to only build one VDSO image, and select the syscall >> entry point at runtime. > > Oh no, we have dueling patches! > > I have a 2/3 finished series that cleans up the AT_SYSINFO mess > differently, as I outlined earlier. I've only done the compat and > common bits (no 32-bit native support quite yet), and it enters > successfully on Intel using SYSENTER and on (fake) AMD using SYSCALL. > The SYSRET bit isn't there yet. > > Other than some ifdeffery, the final system_call.S looks like this: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/tree/arch/x86/entry/vdso/vdso32/system_call.S?h=x86/entry_compat > > The meat is (sorry for whitespace damage): > > .text > .globl __kernel_vsyscall > .type __kernel_vsyscall,@function > ALIGN > __kernel_vsyscall: > CFI_STARTPROC > /* > * Reshuffle regs so that all of any of the entry instructions > * will preserve enough state. > */ > pushl %edx > CFI_ADJUST_CFA_OFFSET 4 > CFI_REL_OFFSET edx, 0 > pushl %ecx > CFI_ADJUST_CFA_OFFSET 4 > CFI_REL_OFFSET ecx, 0 > movl %esp, %ecx > > #ifdef CONFIG_X86_64 > /* If SYSENTER is available, use it. */ > ALTERNATIVE_2 "", "sysenter", X86_FEATURE_SYSENTER32, \ > "syscall", X86_FEATURE_SYSCALL32 > #endif > > /* Enter using int $0x80 */ > movl (%esp), %ecx > int $0x80 > GLOBAL(int80_landing_pad) > > /* Restore ECX and EDX in case they were clobbered. */ > popl %ecx > CFI_RESTORE ecx > CFI_ADJUST_CFA_OFFSET -4 > popl %edx > CFI_RESTORE edx > CFI_ADJUST_CFA_OFFSET -4 > ret > CFI_ENDPROC > > .size __kernel_vsyscall,.-__kernel_vsyscall > .previous > > And that's it. > > What do you think? This comes with massively cleaned up kernel-side > asm as well as a test case that actually validates the CFI directives. > > Certainly, a bunch of your patches make sense regardless, and I'll > review them and add them to my queue soon. > > --Andy How does the performance compare to the original? Looking at the disassembly, there are two added function calls, and it reloads the args from the stack instead of just shuffling registers. -- Brian Gerst -- 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: Build regressions/improvements in v4.2
On Sun, Aug 30, 2015 at 11:05 PM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v4.2[1] to v4.2-rc8[3], the summaries are:
> - build errors: +0/-3
Nice!
> [1] http://kisskb.ellerman.id.au/kisskb/head/9309/ (all 254 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/9289/ (252 out of 254 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/
Build regressions/improvements in v4.2
Below is the list of build error/warning regressions/improvements in v4.2[1] compared to v4.1[2]. Summarized: - build errors: +8/-53 - build warnings: +127/-265 JFYI, when comparing v4.2[1] to v4.2-rc8[3], the summaries are: - build errors: +0/-3 - build warnings: +27/-30 Note that there may be false regressions, as some logs are incomplete. Still, they're build errors/warnings. As I haven't mastered kup yet, there's no verbose summary at http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.2.summary.gz Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/head/9309/ (all 254 configs) [2] http://kisskb.ellerman.id.au/kisskb/head/9038/ (all 254 configs) [3] http://kisskb.ellerman.id.au/kisskb/head/9289/ (252 out of 254 configs) *** ERRORS *** 8 regressions: + /home/kisskb/slave/src/drivers/net/ethernet/via/via-rhine.c: error: implicit declaration of function 'pci_iomap' [-Werror=implicit-function-declaration]: => 1098:2 + /home/kisskb/slave/src/drivers/net/ethernet/via/via-rhine.c: error: implicit declaration of function 'pci_iounmap' [-Werror=implicit-function-declaration]: => 1119:2 + error: igb_main.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.__alloc_pages_nodemask' defined in .text section in mm/built-in.o: => (.text+0x1ff7748) + error: igb_main.c: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o: => (.text+0x1ff8018), (.text+0x1ff820c), (.text+0x1ff8370) + error: igb_main.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.queue_work_on' defined in .text section in kernel/built-in.o: => (.text+0x1ff7038), (.text+0x1ff6f40) + error: igb_main.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_23' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: => (.text+0x1ff8690) + error: igb_main.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_25' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: => (.text+0x1ff7934), (.text+0x1ff7c20) + error: igb_main.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_26' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: => (.text+0x1ff6e14) 53 improvements: - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_BUFFERABLE' undeclared here (not in a function): 81:10 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_DEV_CACHED' undeclared here (not in a function): 117:10 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_DEV_NONSHARED' undeclared here (not in a function): 108:10 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_DEV_SHARED' undeclared here (not in a function): 103:10 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_DEV_WC' undeclared here (not in a function): 113:10 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_MASK' undeclared here (not in a function): 76:11 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_MINICACHE' undeclared here (not in a function): 94:10 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_UNCACHED' undeclared here (not in a function): 77:10 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_WRITEALLOC' undeclared here (not in a function): 99:10 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_WRITEBACK' undeclared here (not in a function): 89:10 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_WRITETHROUGH' undeclared here (not in a function): 85:10 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_RDONLY' undeclared here (not in a function): 61:11 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_SHARED' undeclared here (not in a function): 71:11 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_USER' undeclared here (not in a function): 56:11 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_XN' undeclared here (not in a function): 66:11 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PMD_SECT_AP_READ' undeclared here (not in a function): 153:13 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PMD_SECT_AP_WRITE' undeclared here (not in a function): 153:32 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PMD_SECT_S' undeclared here (not in a function): 175:11 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PMD_SECT_XN' undeclared here (not in a function): 170:11 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PMD_SIZE' undeclared (first use in this function): 276:22 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PTRS_PER_PGD' undeclared (first use in this function): 314:18 => - /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PTRS_PER_PMD'
[git pull] m68k updates for 4.3
Hi Linus,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus
for you to fetch changes up to 1ecb40643a9af05683b7a898d7141884bcb28a82:
m68k/bootinfo: Use kmemdup rather than duplicating its implementation
(2015-08-10 10:26:33 +0200)
Andrzej Hajda (1):
m68k/bootinfo: Use kmemdup rather than duplicating its implementation
Geert Uytterhoeven (2):
m68k/defconfig: Disable experimental CONFIG_DM_CACHE
m68k/defconfig: Update defconfigs for v4.2-rc1
arch/m68k/configs/amiga_defconfig| 16 +++-
arch/m68k/configs/apollo_defconfig | 16 +++-
arch/m68k/configs/atari_defconfig| 16 +++-
arch/m68k/configs/bvme6000_defconfig | 16 +++-
arch/m68k/configs/hp300_defconfig| 16 +++-
arch/m68k/configs/mac_defconfig | 16 +++-
arch/m68k/configs/multi_defconfig| 16 +++-
arch/m68k/configs/mvme147_defconfig | 16 +++-
arch/m68k/configs/mvme16x_defconfig | 16 +++-
arch/m68k/configs/q40_defconfig | 16 +++-
arch/m68k/configs/sun3_defconfig | 16 +++-
arch/m68k/configs/sun3x_defconfig| 16 +++-
arch/m68k/kernel/bootinfo_proc.c | 4 +---
13 files changed, 133 insertions(+), 63 deletions(-)
Thanks for pulling!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] coccinelle: tests: improve odd_ptr_err.cocci
The original version only considered the case where the then branch
contains only one call to PTR_ERR. Reimplement the whole thing to allow
multiple calls, with potentially different arguments.
Signed-off-by: Julia Lawall
---
scripts/coccinelle/tests/odd_ptr_err.cocci | 120 -
1 file changed, 86 insertions(+), 34 deletions(-)
diff --git a/scripts/coccinelle/tests/odd_ptr_err.cocci
b/scripts/coccinelle/tests/odd_ptr_err.cocci
index cfe0a35..dfc6b40 100644
--- a/scripts/coccinelle/tests/odd_ptr_err.cocci
+++ b/scripts/coccinelle/tests/odd_ptr_err.cocci
@@ -1,12 +1,11 @@
/// PTR_ERR should access the value just tested by IS_ERR
-//# There can be false positives in the patch case, where it is the call
+//# There can be false positives in the patch case, where it is the call to
//# IS_ERR that is wrong.
///
// Confidence: High
-// Copyright: (C) 2012 Julia Lawall, INRIA. GPLv2.
-// Copyright: (C) 2012 Gilles Muller, INRIA. GPLv2.
+// Copyright: (C) 2012, 2015 Julia Lawall, INRIA. GPLv2.
+// Copyright: (C) 2012, 2015 Gilles Muller, INRIA. GPLv2.
// URL: http://coccinelle.lip6.fr/
-// Comments:
// Options: --no-includes --include-headers
virtual patch
@@ -14,52 +13,105 @@ virtual context
virtual org
virtual report
-@depends on patch@
-expression e,e1;
+@ok1 exists@
+expression x,e;
+position p;
@@
+if (IS_ERR(x=e) || ...) {
+ <...
+ PTR_ERR@p(x)
+ ...>
+}
+
+@ok2 exists@
+expression x,e1,e2;
+position p;
+@@
+
+if (IS_ERR(x) || ...) {
+ <...
(
-if (IS_ERR(e)) { ... PTR_ERR(e) ... }
+ PTR_ERR@p(\(e1 ? e2 : x\|e1 ? x : e2\))
|
-if (IS_ERR(e=e1)) { ... PTR_ERR(e) ... }
+ PTR_ERR@p(x)
+)
+ ...>
+}
+
+@r1 depends on patch && !context && !org && !report exists@
+expression x,y;
+position p != {ok1.p,ok2.p};
+@@
+
+if (IS_ERR(x) || ...) {
+ ... when any
+ when != IS_ERR(...)
+(
+ PTR_ERR(x)
|
-if (IS_ERR(e))
- { ...
- PTR_ERR(
-- e1
-+ e
+ PTR_ERR@p(
+- y
++ x
)
- ... }
)
+ ... when any
+}
+
+//
-@r depends on !patch@
-expression e,e1;
-position p1,p2;
+@r1_context depends on !patch && (context || org || report) exists@
+position p != {ok1.p,ok2.p};
+expression x, y;
+position j0, j1;
@@
+if (IS_ERR@j0(x) || ...) {
+ ... when any
+ when != IS_ERR(...)
(
-if (IS_ERR(e)) { ... PTR_ERR(e) ... }
+ PTR_ERR(x)
|
-if (IS_ERR(e=e1)) { ... PTR_ERR(e) ... }
-|
-*if (IS_ERR@p1(e))
- { ...
-* PTR_ERR@p2(e1)
- ... }
+ PTR_ERR@j1@p(
+ y
+ )
)
+ ... when any
+}
-@script:python depends on org@
-p1 << r.p1;
-p2 << r.p2;
+@r1_disj depends on !patch && (context || org || report) exists@
+position p != {ok1.p,ok2.p};
+expression x, y;
+position r1_context.j0, r1_context.j1;
@@
-cocci.print_main("inconsistent IS_ERR and PTR_ERR",p1)
-cocci.print_secs("PTR_ERR",p2)
+* if (IS_ERR@j0(x) || ...) {
+ ... when any
+ when != IS_ERR(...)
+* PTR_ERR@j1@p(
+ y
+ )
+ ... when any
+}
-@script:python depends on report@
-p1 << r.p1;
-p2 << r.p2;
+//
+
+@script:python r1_org depends on org@
+j0 << r1_context.j0;
+j1 << r1_context.j1;
@@
-msg = "inconsistent IS_ERR and PTR_ERR, PTR_ERR on line %s" % (p2[0].line)
-coccilib.report.print_report(p1[0],msg)
+msg = "inconsistent IS_ERR and PTR_ERR"
+coccilib.org.print_todo(j0[0], msg)
+coccilib.org.print_link(j1[0], "")
+
+//
+
+@script:python r1_report depends on report@
+j0 << r1_context.j0;
+j1 << r1_context.j1;
+@@
+
+msg = "inconsistent IS_ERR and PTR_ERR on line %s." % (j1[0].line)
+coccilib.report.print_report(j0[0], msg)
+
--
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 v2] spi: spi-ep93xx: fix PTR_ERR problem
Move initialization of msg->status up over the call to dev_err, in both
calls to ep93xx_spi_dma_prepare, and change the reference in the call to
dev_err to msg->status, to both fix the wrong argument to PTR_ERR in the
second case and to make the dev_err line a little shorter. This required
furthermore replacing %ld by %d, since msg->status is an integer.
The semantic match that finds the PTR_ERR problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression x,y;
@@
if (IS_ERR(x) || ...) {
... when any
when != IS_ERR(...)
(
PTR_ERR(x)
|
* PTR_ERR(y)
)
... when any
}
//
Reorganizations at the suggestion of Walter Harms.
Signed-off-by: Julia Lawall
---
v2: Reorganize the code, to solve the problem in a way that makes the
resulting code simpler.
drivers/spi/spi-ep93xx.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-ep93xx.c b/drivers/spi/spi-ep93xx.c
index bb00be8..73d0df6 100644
--- a/drivers/spi/spi-ep93xx.c
+++ b/drivers/spi/spi-ep93xx.c
@@ -559,16 +559,16 @@ static void ep93xx_spi_dma_transfer(struct ep93xx_spi
*espi)
rxd = ep93xx_spi_dma_prepare(espi, DMA_DEV_TO_MEM);
if (IS_ERR(rxd)) {
- dev_err(>pdev->dev, "DMA RX failed: %ld\n", PTR_ERR(rxd));
msg->status = PTR_ERR(rxd);
+ dev_err(>pdev->dev, "DMA RX failed: %d\n", msg->status);
return;
}
txd = ep93xx_spi_dma_prepare(espi, DMA_MEM_TO_DEV);
if (IS_ERR(txd)) {
ep93xx_spi_dma_finish(espi, DMA_DEV_TO_MEM);
- dev_err(>pdev->dev, "DMA TX failed: %ld\n", PTR_ERR(rxd));
msg->status = PTR_ERR(txd);
+ dev_err(>pdev->dev, "DMA TX failed: %d\n", msg->status);
return;
}
--
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] ASoC: qcom: change PTR_ERR argument
On Sun, 30 Aug 2015, walter harms wrote:
>
>
> Am 30.08.2015 20:05, schrieb Julia Lawall:
> > Apply PTR_ERR to the value that was recently assigned.
> >
> > The semantic match that finds this problem is as follows:
> > (http://coccinelle.lip6.fr/)
> >
> > //
> > @@
> > expression x,y;
> > @@
> >
> > if (IS_ERR(x) || ...) {
> > ... when any
> > when != IS_ERR(...)
> > (
> >PTR_ERR(x)
> > |
> > * PTR_ERR(y)
> > )
> > ... when any
> > }
> > //
> >
> > Signed-off-by: Julia Lawall
> >
> > ---
> > sound/soc/qcom/lpass-cpu.c |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
> > index 23f3d59..94beb99 100644
> > --- a/sound/soc/qcom/lpass-cpu.c
> > +++ b/sound/soc/qcom/lpass-cpu.c
> > @@ -438,7 +438,8 @@ int asoc_qcom_lpass_cpu_platform_probe(struct
> > platform_device *pdev)
> > if (IS_ERR(drvdata->mi2s_bit_clk[dai_id])) {
> > dev_err(>dev,
> > "%s() error getting mi2s-bit-clk: %ld\n",
> > - __func__, PTR_ERR(drvdata->mi2s_bit_clk[i]));
> > + __func__,
> > + PTR_ERR(drvdata->mi2s_bit_clk[dai_id]));
> > return PTR_ERR(drvdata->mi2s_bit_clk[dai_id]);
> > }
> > }
> >
>
> just a note:
> using a shorter name instead of drvdata->mi2s_bit_clk[dai_id] whould help to
> make the code
> more readable (yes, the other code is alike). something like:
>
> struct clk *tmp = devm_clk_get(>dev,clk_name);
Where do you suggest to put this?
Maybe it would be reasonable to declare a variable struct clk *clk; at the
top of the function, and then use that as a temporary variable for all
three calls.
However, now I see that the first call, unlike the other two doesn't cause
a return from the function.
if (IS_ERR(drvdata->mi2s_osr_clk[dai_id])) {
dev_warn(>dev,
"%s() error getting mi2s-osr-clk: %ld\n",
__func__,
PTR_ERR(drvdata->mi2s_osr_clk[dai_id]));
}
Is that intentional?
thanks,
julia
> if (IS_ERR(tmp)) {
> dev_err(>dev,"%s() error getting mi2s-bit-clk: %ld\n",__func__,
> PTR_ERR(tmp));
> return PTR_ERR(tmp);
> }
> drvdata->mi2s_bit_clk[dai_id]=tmp;
>
>
> just one minor:
> the dev_warn() just before says: " error getting mi2s-osr-clk" may be it
> should be "warnig ..."
> That will make it more easy to rep for real error in a log.
>
> re,
> wh
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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/
[PATCH] mtd: nand: pxa3xx: add optional dma for pxa architecture
The PXA architecture provides a DMA to pump data from the nand controller to memory and the other way around. Add it to the binding description. Signed-off-by: Robert Jarzmik --- Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt index 4f833e3c4f51..d9b655f11048 100644 --- a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt +++ b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt @@ -11,6 +11,7 @@ Required properties: Optional properties: + - dmas: dma data channel, see dma.txt binding doc - marvell,nand-enable-arbiter:Set to enable the bus arbiter - marvell,nand-keep-config: Set to keep the NAND controller config as set by the bootloader @@ -32,6 +33,8 @@ Example: compatible = "marvell,pxa3xx-nand"; reg = <0x4310 90>; interrupts = <45>; + dmas = < 97 0>; + dma-names = "data"; #address-cells = <1>; marvell,nand-enable-arbiter; -- 2.1.4 -- 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 4/4] media: pxa_camera: conversion to dmaengine
Guennadi Liakhovetski writes:
>> +last_buf = list_entry(pcdev->capture.prev,
>> + struct pxa_buffer, vb.queue);
>
> You can use list_last_entry()
Ok.
>> +last_status = dma_async_is_tx_complete(pcdev->dma_chans[chan],
>> + last_buf->cookie[chan],
>> + NULL, _issued);
>> +if (camera_status & overrun &&
>> +last_status != DMA_COMPLETE) {
>> +dev_dbg(dev, "FIFO overrun! CISR: %x\n",
>> +camera_status);
>> +pxa_camera_stop_capture(pcdev);
>> +list_for_each_entry(buf, >capture, vb.queue)
>> +pxa_dma_add_tail_buf(pcdev, buf);
>
> Why have you added this loop? Is it a bug in the current implementation or
> is it only needed with the switch to dmaengine?
It's a consequence of the switch.
With dmaengine, a dmaengine_terminate_all() removes all queued txs. It is
therefore necessary to requeue them. In the previous implementation, the
chaining was still good, and it was "enough" to just queue the first
videobuffer : the other buffers would follow by chaining.
Cheers.
--
Robert
--
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] asm-generic/pci_iomap.h: make custom PCI BAR requirements explicit
On Friday 28 August 2015 17:17:27 Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > The S390 architecture requires a custom pci_iomap() implementation > as the asm-generic implementation assumes there are disjunctions > between PCI BARs, and on S390 PCI BAR are not disjunctive, S390 requires > the bar parameter in order to find the corresponding device and create > the mapping cookie. > > This clash with the asm-generic pci_iomap() implementation is implicit, > there are no current semantics to make this incompatability explicit. > Make the S390 PCI BAR non-disjunction incompatibility explicit, and > also pave the way for alternative incompatibilities to be defined. I don't think we really need to spell it out here. s390 PCI is different from everybody else's in a lot of ways, so a simple 'depends on PCI && !S390' for CONFIG_PCI_IOMAP seems simpler and more intuitive. > While at it, as with the ioremap*() variants, since we have no clear > semantics yet well defined provide a solution for them that returns > NULL. This allows architectures to move forward by defining pci_ioremap*() > variants without requiring immediate changes to all architectures. Each > architecture then can implement their own solution as needed and > when they get to it. Which architectures are you thinking about here? > Build tested with allyesconfig on: > > * S390 > * x86_64 > > Signed-off-by: Luis R. Rodriguez It's not really clear to me what the purpose of the patch is, is this meant as a cleanup, or are you trying to avoid some real-life bugs you ran into? > This came up as an idea after noting that S390 has no way to be > explicit about its requirements, this also means we don't have a > quick easy way to ensure that other architectures might have a > conflict as well. This provides an easy way to do that by having > the architectures define their incompatibilities and allowing those > then to negate GENERIC_PCI_IOMAP on lib/Kconfig. PCI_IOMAP seems much simpler than ioport_map here, as a lot of architectures can have overlapping port numbers across PCI host bridges. > I think a next cleanup could be the move of the pci_iounmap() out to > pci_iomap.h to avoid having each arch having to declare it. That's > a separate atomic change though so should go in separately. pci_iounmap() is rather tricky, and I think some architectures currently get it wrong and will actually unmap parts of the I/O port ranges from the PCI host controller mapping. It might be rare enough that it never caused problems (that got reported), but it might be nice to actually provide an implementation that has a chance of working. The version from lib/iomap.c seems correct for uses of CONFIG_GENERIC_IOMAP, but most architectures can do better without that option. Arnd -- 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 3/4] media: pxa_camera: trivial move of dma irq functions
Guennadi Liakhovetski writes: > This still seems to break compilation to me. Could you compile-test after > each your patch, please? Ah yes. Ill timing, I had sent the v4 before having these comments, so I'll have to fix it in v5. Cheers. -- Robert -- 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 1/4] media: pxa_camera: fix the buffer free path
From: Robert Jarzmik
Fix the error path where the video buffer wasn't allocated nor
mapped. In this case, in the driver free path don't try to unmap memory
which was not mapped in the first place.
Signed-off-by: Robert Jarzmik
---
drivers/media/platform/soc_camera/pxa_camera.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index fcb942de0c7f..aa304950bb98 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -272,8 +272,8 @@ static void free_buffer(struct videobuf_queue *vq, struct
pxa_buffer *buf)
* longer in STATE_QUEUED or STATE_ACTIVE
*/
videobuf_waiton(vq, >vb, 0, 0);
- videobuf_dma_unmap(vq->dev, dma);
- videobuf_dma_free(dma);
+ if (buf->vb.state == VIDEOBUF_NEEDS_INIT)
+ return;
for (i = 0; i < ARRAY_SIZE(buf->dmas); i++) {
if (buf->dmas[i].sg_cpu)
@@ -283,6 +283,8 @@ static void free_buffer(struct videobuf_queue *vq, struct
pxa_buffer *buf)
buf->dmas[i].sg_dma);
buf->dmas[i].sg_cpu = NULL;
}
+ videobuf_dma_unmap(vq->dev, dma);
+ videobuf_dma_free(dma);
buf->vb.state = VIDEOBUF_NEEDS_INIT;
}
--
2.1.4
--
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/4] media: pxa_camera: trivial move of dma irq functions
From: Robert Jarzmik
This moves the dma irq handling functions up in the source file, so that
they are available before DMA preparation functions. It prepares the
conversion to DMA engine, where the descriptors are populated with these
functions as callbacks.
Signed-off-by: Robert Jarzmik
---
Since v1: fixed prototypes change
---
drivers/media/platform/soc_camera/pxa_camera.c | 42 +++---
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 39c7e7519b3c..cdfb93aaee43 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -313,6 +313,30 @@ static int calculate_dma_sglen(struct scatterlist *sglist,
int sglen,
return i + 1;
}
+static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
+ enum pxa_camera_active_dma act_dma);
+
+static void pxa_camera_dma_irq_y(int channel, void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+
+ pxa_camera_dma_irq(pcdev, DMA_Y);
+}
+
+static void pxa_camera_dma_irq_u(int channel, void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+
+ pxa_camera_dma_irq(pcdev, DMA_U);
+}
+
+static void pxa_camera_dma_irq_v(int channel, void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+
+ pxa_camera_dma_irq(pcdev, DMA_V);
+}
+
/**
* pxa_init_dma_channel - init dma descriptors
* @pcdev: pxa camera device
@@ -810,24 +834,6 @@ out:
spin_unlock_irqrestore(>lock, flags);
}
-static void pxa_camera_dma_irq_y(int channel, void *data)
-{
- struct pxa_camera_dev *pcdev = data;
- pxa_camera_dma_irq(channel, pcdev, DMA_Y);
-}
-
-static void pxa_camera_dma_irq_u(int channel, void *data)
-{
- struct pxa_camera_dev *pcdev = data;
- pxa_camera_dma_irq(channel, pcdev, DMA_U);
-}
-
-static void pxa_camera_dma_irq_v(int channel, void *data)
-{
- struct pxa_camera_dev *pcdev = data;
- pxa_camera_dma_irq(channel, pcdev, DMA_V);
-}
-
static struct videobuf_queue_ops pxa_videobuf_ops = {
.buf_setup = pxa_videobuf_setup,
.buf_prepare= pxa_videobuf_prepare,
--
2.1.4
--
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 4/4] media: pxa_camera: conversion to dmaengine
Convert pxa_camera to dmaengine. This removes all DMA registers
manipulation in favor of the more generic dmaengine API.
The functional level should be the same as before. The biggest change is
in the videobuf_sg_splice() function, which splits a videobuf-dma into
several scatterlists for 3 planes captures (Y, U, V).
Signed-off-by: Robert Jarzmik
---
Since v1: Guennadi's fixes
dma tasklet functions prototypes change (trivial move)
Since v2: sglist cut revamped with Guennadi's comments
Since v3: sglist split removed after Andrew's merge in -mm tree in lib/
taken into account Vinod's change to DMA_CTRL_REUSE
---
drivers/media/platform/soc_camera/Kconfig | 1 +
drivers/media/platform/soc_camera/pxa_camera.c | 404 +++--
2 files changed, 172 insertions(+), 233 deletions(-)
diff --git a/drivers/media/platform/soc_camera/Kconfig
b/drivers/media/platform/soc_camera/Kconfig
index f2776cd415ca..e5e2d6cf6638 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -30,6 +30,7 @@ config VIDEO_PXA27x
tristate "PXA27x Quick Capture Interface driver"
depends on VIDEO_DEV && PXA27x && SOC_CAMERA
select VIDEOBUF_DMA_SG
+ select SG_SPLIT
---help---
This is a v4l2 driver for the PXA27x Quick Capture Interface
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index cdfb93aaee43..969140634f3d 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -28,6 +28,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -38,7 +41,6 @@
#include
-#include
#include
#define PXA_CAM_VERSION "0.0.6"
@@ -175,21 +177,16 @@ enum pxa_camera_active_dma {
DMA_V = 0x4,
};
-/* descriptor needed for the PXA DMA engine */
-struct pxa_cam_dma {
- dma_addr_t sg_dma;
- struct pxa_dma_desc *sg_cpu;
- size_t sg_size;
- int sglen;
-};
-
/* buffer for one video frame */
struct pxa_buffer {
/* common v4l buffer stuff -- must be first */
struct videobuf_buffer vb;
u32 code;
/* our descriptor lists for Y, U and V channels */
- struct pxa_cam_dma dmas[3];
+ struct dma_async_tx_descriptor *descs[3];
+ dma_cookie_tcookie[3];
+ struct scatterlist *sg[3];
+ int sg_len[3];
int inwork;
enum pxa_camera_active_dma active_dma;
};
@@ -207,7 +204,7 @@ struct pxa_camera_dev {
void __iomem*base;
int channels;
- unsigned intdma_chans[3];
+ struct dma_chan *dma_chans[3];
struct pxacamera_platform_data *pdata;
struct resource *res;
@@ -222,7 +219,6 @@ struct pxa_camera_dev {
spinlock_t lock;
struct pxa_buffer *active;
- struct pxa_dma_desc *sg_tail[3];
struct tasklet_struct task_eof;
u32 save_cicr[5];
@@ -259,7 +255,6 @@ static int pxa_videobuf_setup(struct videobuf_queue *vq,
unsigned int *count,
static void free_buffer(struct videobuf_queue *vq, struct pxa_buffer *buf)
{
struct soc_camera_device *icd = vq->priv_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct videobuf_dmabuf *dma = videobuf_to_dma(>vb);
int i;
@@ -276,61 +271,40 @@ static void free_buffer(struct videobuf_queue *vq, struct
pxa_buffer *buf)
if (buf->vb.state == VIDEOBUF_NEEDS_INIT)
return;
- for (i = 0; i < ARRAY_SIZE(buf->dmas); i++) {
- if (buf->dmas[i].sg_cpu)
- dma_free_coherent(ici->v4l2_dev.dev,
- buf->dmas[i].sg_size,
- buf->dmas[i].sg_cpu,
- buf->dmas[i].sg_dma);
- buf->dmas[i].sg_cpu = NULL;
+ for (i = 0; i < 3 && buf->descs[i]; i++) {
+ dmaengine_desc_free(buf->descs[i]);
+ kfree(buf->sg[i]);
+ buf->descs[i] = NULL;
+ buf->sg[i] = NULL;
+ buf->sg_len[i] = 0;
}
videobuf_dma_unmap(vq->dev, dma);
videobuf_dma_free(dma);
buf->vb.state = VIDEOBUF_NEEDS_INIT;
-}
-
-static int calculate_dma_sglen(struct scatterlist *sglist, int sglen,
- int sg_first_ofs, int size)
-{
- int i, offset, dma_len, xfer_len;
- struct scatterlist *sg;
-
- offset = sg_first_ofs;
- for_each_sg(sglist, sg, sglen, i) {
- dma_len = sg_dma_len(sg);
-
- /* PXA27x Developer's Manual
[PATCH v4 0/4] media: pxa_camera: conversion to dmaengine
Hi Guennadi, This is the forth round. This time sg_split() was a consequence of (a) and (b), ie. sg_split() move into kernel's lib/ directory, and following dmaengine "reuse" flag introduction, change pxa_camera accordingly. Happy review. Cheers. Robert Jarzmik (4): media: pxa_camera: fix the buffer free path media: pxa_camera: move interrupt to tasklet media: pxa_camera: trivial move of dma irq functions media: pxa_camera: conversion to dmaengine drivers/media/platform/soc_camera/Kconfig | 1 + drivers/media/platform/soc_camera/pxa_camera.c | 478 +++-- 2 files changed, 220 insertions(+), 259 deletions(-) -- 2.1.4 -- 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] mtd: nand: pxa3xx-nand: prevent DFI bus lockup on removal
After the conversion of pxa architecture to common clock framework, the NAND clock can be disabled on driver exit. In this case, it happens that if the driver used the NAND and set the DFI arbitration bit, the next access to a static memory controller area, such as an ethernet card, will stall the system bus, and the core will be stalled forever. This is especially true on pxa31x SoCs, where the NDCR was augmented with a new bit to prevent this lockups by giving full ownership of the DFI arbiter to the SMC, in change SCr#6. Fix this by clearing the DFI arbritration bit in driver exit. This effectively prevents a lockup on zylonite when removing pxa3xx-nand module, and using ethernet afterwards. Signed-off-by: Robert Jarzmik --- Since v1: add comment, switch to NFCV1/NCFV2 registers naming --- drivers/mtd/nand/pxa3xx_nand.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c index 718097414b9c..2f39bfe34584 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c +++ b/drivers/mtd/nand/pxa3xx_nand.c @@ -75,7 +75,8 @@ #define NDCR_ND_MODE (0x3 << 21) #define NDCR_NAND_MODE (0x0) #define NDCR_CLR_PG_CNT(0x1 << 20) -#define NDCR_STOP_ON_UNCOR (0x1 << 19) +#define NFCV1_NDCR_ARB_CNTL(0x1 << 19) +#define NFCV2_NDCR_STOP_ON_UNCOR (0x1 << 19) #define NDCR_RD_ID_CNT_MASK(0x7 << 16) #define NDCR_RD_ID_CNT(x) (((x) << 16) & NDCR_RD_ID_CNT_MASK) @@ -1305,7 +1306,8 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info) } /* Set an initial chunk size */ - info->reg_ndcr = ndcr & ~NDCR_INT_MASK; + info->reg_ndcr = ndcr & + ~(NDCR_INT_MASK | NDCR_ND_ARB_EN | NFCV1_NDCR_ARB_CNTL); info->ndtr0cs0 = nand_readl(info, NDTR0CS0); info->ndtr1cs0 = nand_readl(info, NDTR1CS0); return 0; @@ -1542,6 +1544,7 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd) pxa3xx_flash_ids[1].name = NULL; def = pxa3xx_flash_ids; KEEP_CONFIG: + info->reg_ndcr |= (pdata->enable_arbiter) ? NDCR_ND_ARB_EN : 0; if (info->reg_ndcr & NDCR_DWIDTH_M) chip->options |= NAND_BUSWIDTH_16; @@ -1768,6 +1771,16 @@ static int pxa3xx_nand_remove(struct platform_device *pdev) free_irq(irq, info); pxa3xx_nand_free_buff(info); + /* +* In the pxa3xx case, the DFI bus is shared between the SMC and NFC. +* In order to prevent a lockup of the system bus, the DFI bus +* arbitration is granted to SMC upon driver removal. This is done by +* setting the x_ARB_CNTL bit, which also prevents the NAND to have +* access to the bus anymore. +*/ + nand_writel(info, NDCR, + (nand_readl(info, NDCR) & ~NDCR_ND_ARB_EN) | + NFCV1_NDCR_ARB_CNTL); clk_disable_unprepare(info->clk); for (cs = 0; cs < pdata->num_cs; cs++) -- 2.1.4 -- 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 2/4] media: pxa_camera: move interrupt to tasklet
From: Robert Jarzmik
In preparation for dmaengine conversion, move the camera interrupt
handling into a tasklet. This won't change the global flow, as this
interrupt is only used to detect the end of frame and activate DMA fifos
handling.
Signed-off-by: Robert Jarzmik
---
drivers/media/platform/soc_camera/pxa_camera.c | 44 +-
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index aa304950bb98..39c7e7519b3c 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -223,6 +223,7 @@ struct pxa_camera_dev {
struct pxa_buffer *active;
struct pxa_dma_desc *sg_tail[3];
+ struct tasklet_struct task_eof;
u32 save_cicr[5];
};
@@ -605,6 +606,7 @@ static void pxa_camera_start_capture(struct pxa_camera_dev
*pcdev)
unsigned long cicr0;
dev_dbg(pcdev->soc_host.v4l2_dev.dev, "%s\n", __func__);
+ __raw_writel(__raw_readl(pcdev->base + CISR), pcdev->base + CISR);
/* Enable End-Of-Frame Interrupt */
cicr0 = __raw_readl(pcdev->base + CICR0) | CICR0_ENB;
cicr0 &= ~CICR0_EOFM;
@@ -922,13 +924,35 @@ static void pxa_camera_deactivate(struct pxa_camera_dev
*pcdev)
clk_disable_unprepare(pcdev->clk);
}
-static irqreturn_t pxa_camera_irq(int irq, void *data)
+static void pxa_camera_eof(unsigned long arg)
{
- struct pxa_camera_dev *pcdev = data;
- unsigned long status, cifr, cicr0;
+ struct pxa_camera_dev *pcdev = (struct pxa_camera_dev *)arg;
+ unsigned long cifr;
struct pxa_buffer *buf;
struct videobuf_buffer *vb;
+ dev_dbg(pcdev->soc_host.v4l2_dev.dev,
+ "Camera interrupt status 0x%x\n",
+ __raw_readl(pcdev->base + CISR));
+
+ /* Reset the FIFOs */
+ cifr = __raw_readl(pcdev->base + CIFR) | CIFR_RESET_F;
+ __raw_writel(cifr, pcdev->base + CIFR);
+
+ pcdev->active = list_first_entry(>capture,
+struct pxa_buffer, vb.queue);
+ vb = >active->vb;
+ buf = container_of(vb, struct pxa_buffer, vb);
+ pxa_videobuf_set_actdma(pcdev, buf);
+
+ pxa_dma_start_channels(pcdev);
+}
+
+static irqreturn_t pxa_camera_irq(int irq, void *data)
+{
+ struct pxa_camera_dev *pcdev = data;
+ unsigned long status, cicr0;
+
status = __raw_readl(pcdev->base + CISR);
dev_dbg(pcdev->soc_host.v4l2_dev.dev,
"Camera interrupt status 0x%lx\n", status);
@@ -939,20 +963,9 @@ static irqreturn_t pxa_camera_irq(int irq, void *data)
__raw_writel(status, pcdev->base + CISR);
if (status & CISR_EOF) {
- /* Reset the FIFOs */
- cifr = __raw_readl(pcdev->base + CIFR) | CIFR_RESET_F;
- __raw_writel(cifr, pcdev->base + CIFR);
-
- pcdev->active = list_first_entry(>capture,
- struct pxa_buffer, vb.queue);
- vb = >active->vb;
- buf = container_of(vb, struct pxa_buffer, vb);
- pxa_videobuf_set_actdma(pcdev, buf);
-
- pxa_dma_start_channels(pcdev);
-
cicr0 = __raw_readl(pcdev->base + CICR0) | CICR0_EOFM;
__raw_writel(cicr0, pcdev->base + CICR0);
+ tasklet_schedule(>task_eof);
}
return IRQ_HANDLED;
@@ -1847,6 +1860,7 @@ static int pxa_camera_probe(struct platform_device *pdev)
pcdev->soc_host.priv= pcdev;
pcdev->soc_host.v4l2_dev.dev= >dev;
pcdev->soc_host.nr = pdev->id;
+ tasklet_init(>task_eof, pxa_camera_eof, (unsigned long)pcdev);
err = soc_camera_host_register(>soc_host);
if (err)
--
2.1.4
--
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] mm/slab: skip memcg reclaim only if in atomic context
SLAB's implementation of kmem_cache_alloc() works as follows:
1. First, it tries to allocate from the preferred NUMA node without
issuing reclaim.
2. If step 1 fails, it tries all nodes in the order of preference,
again without invoking reclaimer
3. Only if steps 1 and 2 fails, it falls back on allocation from any
allowed node with reclaim enabled.
Before commit 4167e9b2cf10f ("mm: remove GFP_THISNODE"), GFP_THISNODE
combination, which equaled __GFP_THISNODE|__GFP_NOWARN|__GFP_NORETRY on
NUMA enabled builds, was used in order to avoid reclaim during steps 1
and 2. If __alloc_pages_slowpath() saw this combination in gfp flags, it
aborted immediately even if __GFP_WAIT flag was set. So there was no
need in clearing __GFP_WAIT flag while performing steps 1 and 2 and
hence we could invoke memcg reclaim when allocating a slab page if the
context allowed.
Commit 4167e9b2cf10f zapped GFP_THISNODE combination. Instead of OR-ing
the gfp mask with GFP_THISNODE, gfp_exact_node() helper should now be
used. The latter sets __GFP_THISNODE and __GFP_NOWARN flags and clears
__GFP_WAIT on the current gfp mask. As a result, it effectively
prohibits invoking memcg reclaim on steps 1 and 2. This breaks
memcg/memory.high logic when kmem accounting is enabled. The memory.high
threshold is supposed to work as a soft limit, i.e. it does not fail an
allocation on breaching it, but it still forces the caller to invoke
direct reclaim to compensate for the excess. Without __GFP_WAIT flag
direct reclaim is impossible so the caller will go on without being
pushed back to the threshold.
To fix this issue, we get rid of gfp_exact_node() helper and move gfp
flags filtering to kmem_getpages() after memcg_charge_slab() is called.
To understand the patch, note that:
- In fallback_alloc() the only effect of using gfp_exact_node() is
preventing recursion fallback_alloc() -> cache_alloc_node() ->
fallback_alloc().
- Aside from fallback_alloc(), gfp_exact_node() is only used along with
cache_grow(). Moreover, the only place where cache_grow() is used
without it is fallback_alloc(), which, in contrast to other
cache_grow() users, preallocates a page and passes it to cache_grow()
so that the latter does not need to invoke kmem_getpages() by itself.
Reported-by: Tejun Heo
Signed-off-by: Vladimir Davydov
---
mm/slab.c | 32 +++-
1 file changed, 11 insertions(+), 21 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index d890750ec31e..9ee809d2ed8b 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -857,11 +857,6 @@ static inline void *cache_alloc_node(struct kmem_cache
*cachep,
return NULL;
}
-static inline gfp_t gfp_exact_node(gfp_t flags)
-{
- return flags;
-}
-
#else /* CONFIG_NUMA */
static void *cache_alloc_node(struct kmem_cache *, gfp_t, int);
@@ -1028,15 +1023,6 @@ static inline int cache_free_alien(struct kmem_cache
*cachep, void *objp)
return __cache_free_alien(cachep, objp, node, page_node);
}
-
-/*
- * Construct gfp mask to allocate from a specific node but do not invoke
reclaim
- * or warn about failures.
- */
-static inline gfp_t gfp_exact_node(gfp_t flags)
-{
- return (flags | __GFP_THISNODE | __GFP_NOWARN) & ~__GFP_WAIT;
-}
#endif
/*
@@ -1583,7 +1569,7 @@ slab_out_of_memory(struct kmem_cache *cachep, gfp_t
gfpflags, int nodeid)
* would be relatively rare and ignorable.
*/
static struct page *kmem_getpages(struct kmem_cache *cachep, gfp_t flags,
- int nodeid)
+ int nodeid, bool fallback)
{
struct page *page;
int nr_pages;
@@ -1595,6 +1581,9 @@ static struct page *kmem_getpages(struct kmem_cache
*cachep, gfp_t flags,
if (memcg_charge_slab(cachep, flags, cachep->gfporder))
return NULL;
+ if (!fallback)
+ flags = (flags | __GFP_THISNODE | __GFP_NOWARN) & ~__GFP_WAIT;
+
page = __alloc_pages_node(nodeid, flags | __GFP_NOTRACK,
cachep->gfporder);
if (!page) {
memcg_uncharge_slab(cachep, cachep->gfporder);
@@ -2641,7 +2630,8 @@ static int cache_grow(struct kmem_cache *cachep,
* 'nodeid'.
*/
if (!page)
- page = kmem_getpages(cachep, local_flags, nodeid);
+ page = kmem_getpages(cachep, local_flags, nodeid,
+!IS_ENABLED(CONFIG_NUMA));
if (!page)
goto failed;
@@ -2840,7 +2830,7 @@ alloc_done:
if (unlikely(!ac->avail)) {
int x;
force_grow:
- x = cache_grow(cachep, gfp_exact_node(flags), node, NULL);
+ x = cache_grow(cachep, flags, node, NULL);
/* cache_grow can reenable interrupts, then ac could change. */
ac = cpu_cache_get(cachep);
@@ -3034,7 +3024,7 @@ retry:
get_node(cache, nid) &&
[PATCH 2/2] mm/slub: do not bypass memcg reclaim for high-order page allocation
Commit 6af3142bed1f52 ("mm/slub: don't wait for high-order page
allocation") made allocate_slab() try to allocate high order slab pages
without __GFP_WAIT in order to avoid invoking reclaim/compaction when we
can fall back on low order pages. However, it broke memcg/memory.high
logic in case kmem accounting is enabled. The memory.high threshold
works as a soft limit: an allocation does not fail if it is breached,
but we call direct reclaim to compensate for the excess. Without
__GFP_WAIT we cannot invoke reclaimer and therefore we will go on
exceeding memory.high more and more until a normal __GFP_WAIT allocation
is issued.
Since memcg reclaim never triggers compaction, we can pass __GFP_WAIT to
memcg_charge_slab() even on high order page allocations w/o any
performance impact. So let us fix this problem by excluding __GFP_WAIT
only from alloc_pages() while still forwarding it to memcg_charge_slab()
if the context allows.
Reported-by: Tejun Heo
Signed-off-by: Vladimir Davydov
---
mm/slub.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index e180f8dcd06d..416a332277cb 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1333,6 +1333,14 @@ static inline struct page *alloc_slab_page(struct
kmem_cache *s,
if (memcg_charge_slab(s, flags, order))
return NULL;
+ /*
+* Let the initial higher-order allocation fail under memory pressure
+* so we fall-back to the minimum order allocation.
+*/
+ if (oo_order(oo) > oo_order(s->min))
+ flags = (flags | __GFP_NOWARN | __GFP_NOMEMALLOC) &
+ ~(__GFP_NOFAIL | __GFP_WAIT);
+
if (node == NUMA_NO_NODE)
page = alloc_pages(flags, order);
else
@@ -1348,7 +1356,6 @@ static struct page *allocate_slab(struct kmem_cache *s,
gfp_t flags, int node)
{
struct page *page;
struct kmem_cache_order_objects oo = s->oo;
- gfp_t alloc_gfp;
void *start, *p;
int idx, order;
@@ -1359,23 +1366,14 @@ static struct page *allocate_slab(struct kmem_cache *s,
gfp_t flags, int node)
flags |= s->allocflags;
- /*
-* Let the initial higher-order allocation fail under memory pressure
-* so we fall-back to the minimum order allocation.
-*/
- alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL;
- if ((alloc_gfp & __GFP_WAIT) && oo_order(oo) > oo_order(s->min))
- alloc_gfp = (alloc_gfp | __GFP_NOMEMALLOC) & ~__GFP_WAIT;
-
- page = alloc_slab_page(s, alloc_gfp, node, oo);
+ page = alloc_slab_page(s, flags, node, oo);
if (unlikely(!page)) {
oo = s->min;
- alloc_gfp = flags;
/*
* Allocation may have failed due to fragmentation.
* Try a lower order alloc if possible
*/
- page = alloc_slab_page(s, alloc_gfp, node, oo);
+ page = alloc_slab_page(s, flags, node, oo);
if (unlikely(!page))
goto out;
stat(s, ORDER_FALLBACK);
@@ -1385,7 +1383,7 @@ static struct page *allocate_slab(struct kmem_cache *s,
gfp_t flags, int node)
!(s->flags & (SLAB_NOTRACK | DEBUG_DEFAULT_FLAGS))) {
int pages = 1 << oo_order(oo);
- kmemcheck_alloc_shadow(page, oo_order(oo), alloc_gfp, node);
+ kmemcheck_alloc_shadow(page, oo_order(oo), flags, node);
/*
* Objects from caches that have a constructor don't get
--
2.1.4
--
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 0/2] Fix memcg/memory.high in case kmem accounting is enabled
Hi, Tejun reported that sometimes memcg/memory.high threshold seems to be silently ignored if kmem accounting is enabled: http://www.spinics.net/lists/linux-mm/msg93613.html It turned out that both SLAB and SLUB try to allocate without __GFP_WAIT first. As a result, if there is enough free pages, memcg reclaim will not get invoked on kmem allocations, which will lead to uncontrollable growth of memory usage no matter what memory.high is set to. This patch set attempts to fix this issue. For more details please see comments to individual patches. Thanks, Vladimir Davydov (2): mm/slab: skip memcg reclaim only if in atomic context mm/slub: do not bypass memcg reclaim for high-order page allocation mm/slab.c | 32 +++- mm/slub.c | 24 +++- 2 files changed, 22 insertions(+), 34 deletions(-) -- 2.1.4 -- 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] ASoC: qcom: change PTR_ERR argument
Am 30.08.2015 20:05, schrieb Julia Lawall:
> Apply PTR_ERR to the value that was recently assigned.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> expression x,y;
> @@
>
> if (IS_ERR(x) || ...) {
> ... when any
> when != IS_ERR(...)
> (
>PTR_ERR(x)
> |
> * PTR_ERR(y)
> )
> ... when any
> }
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> sound/soc/qcom/lpass-cpu.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
> index 23f3d59..94beb99 100644
> --- a/sound/soc/qcom/lpass-cpu.c
> +++ b/sound/soc/qcom/lpass-cpu.c
> @@ -438,7 +438,8 @@ int asoc_qcom_lpass_cpu_platform_probe(struct
> platform_device *pdev)
> if (IS_ERR(drvdata->mi2s_bit_clk[dai_id])) {
> dev_err(>dev,
> "%s() error getting mi2s-bit-clk: %ld\n",
> - __func__, PTR_ERR(drvdata->mi2s_bit_clk[i]));
> + __func__,
> + PTR_ERR(drvdata->mi2s_bit_clk[dai_id]));
> return PTR_ERR(drvdata->mi2s_bit_clk[dai_id]);
> }
> }
>
just a note:
using a shorter name instead of drvdata->mi2s_bit_clk[dai_id] whould help to
make the code
more readable (yes, the other code is alike). something like:
struct clk *tmp = devm_clk_get(>dev,clk_name);
if (IS_ERR(tmp)) {
dev_err(>dev,"%s() error getting mi2s-bit-clk: %ld\n",__func__,
PTR_ERR(tmp));
return PTR_ERR(tmp);
}
drvdata->mi2s_bit_clk[dai_id]=tmp;
just one minor:
the dev_warn() just before says: " error getting mi2s-osr-clk" may be it should
be "warnig ..."
That will make it more easy to rep for real error in a log.
re,
wh
--
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/
Linux 4.2 is out
So judging by how little happened this week, it wouldn't have been a mistake to release 4.2 last week after all, but hey, there's certainly a few fixes here, and it's not like delaying 4.2 for a week should have caused any problems either. So here it is, and the merge window for 4.3 is now open. I already have a few pending early pull requests, but as usual I'll start processing them tomorrow and give the release some time to actually sit. The shortlog from rc8 is tiny, and appended. The patch is pretty tiny too. Go get it, Linus --- Bert Kenward (1): sfc: only use vadaptor stats if firmware is capable David Ahern (1): net: Fix RCU splat in af_key David Daney (1): phylib: Make PHYs children of their MDIO bus, not the bus' parent. David Henningsson (1): ALSA: hda - Shutdown CX20722 on reboot/free to avoid spurious noises Eugene Shatokhin (1): usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared Florian Fainelli (1): net: bcmgenet: Avoid sleeping in bcmgenet_timeout Guilherme G. Piccoli (2): PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case Guillermo A. Amaral (1): Add factory recertified Crucial M500s to blacklist Iyappan Subramanian (1): drivers: net: xgene: fix: Oops in linkwatch_fire_event J. Bruce Fields (1): nfsd: Add Jeff Layton as co-maintainer Jaedon Shin (1): net: bcmgenet: fix uncleaned dma flags Jan Beulich (1): LSM: restore certain default error codes Javi Merino (1): thermal: power_allocator: allocate with kcalloc what you free with kfree Jeff Moyer (1): mtip32x: fix regression introduced by blk-mq per-hctx flush Jurgen Kramer (1): ALSA: usb: Add native DSD support for Gustard DAC-X20U Kazuya Mizuguchi (1): net: compile renesas directory if NET_VENDOR_RENESAS is configured Ken-ichirou MATSUZAWA (1): netlink: mmap: fix tx type check Linus Torvalds (1): Linux 4.2 Madalin Bucur (1): net: phy: fixed: propagate fixed link values to struct Marc Kleine-Budde (1): can: pcan_usb: don't provide CAN FD bittimings by non-FD adapters Marc Zyngier (1): arm64: KVM: Fix host crash when injecting a fault into a 32bit guest Marcelo Ricardo Leitner (1): vxlan: re-ignore EADDRINUSE from igmp_join Markus Osterhoff (1): ALSA: hda: fix possible NULL dereference Ross Zwisler (1): nfit, nd_blk: BLK status register is only 32 bits Russell King (2): net: phy: add locking to phy_read_mmd_indirect()/phy_write_mmd_indirect() net: fec: use reinit_completion() in mdio accessor functions Takashi Iwai (2): ALSA: hda - Check all inputs for is_active_nid_for_any() ALSA: hda - Fix path power activation Tejun Heo (1): writeback: sync_inodes_sb() must write out I_DIRTY_TIME inodes and always call wait_sb_inodes() Thomas Gleixner (1): x86/apic: Fix fallout from x2apic cleanup Toshi Kani (1): nfit: Clarify memory device state flags strings WANG Cong (1): cls_u32: complete the check for non-forced case in u32_destroy() huaibin Wang (1): ip6_gre: release cached dst on tunnel removal lucien (2): sctp: asconf's process should verify address parameter is in the beginning sctp: donot reset the overall_error_count in SHUTDOWN_RECEIVE state -- 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] btrfs: cleanup btrfs_balance profile validity checks
Improve readability by generalizing the profile validity checks,
I had to read through those if statements half a dozen times on my
first try just to get an idea of what's happening there.
Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
---
fs/btrfs/volumes.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index fbe7c10..d23bc26 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3454,6 +3454,15 @@ static void __cancel_balance(struct btrfs_fs_info
*fs_info)
atomic_set(_info->mutually_exclusive_operation_running, 0);
}
+/* Non-zero return value signifies invalidity */
+static inline int balance_relocate_invalid(struct btrfs_balance_args *bctl_arg,
+ u64 allowed)
+{
+ return ((bctl_arg->flags & BTRFS_BALANCE_ARGS_CONVERT) &&
+ (!alloc_profile_is_valid(bctl_arg->target, 1) ||
+(bctl_arg->target & ~allowed)));
+}
+
/*
* Should be called with both balance and volume mutexes held
*/
@@ -3511,27 +3520,21 @@ int btrfs_balance(struct btrfs_balance_control *bctl,
if (num_devices > 3)
allowed |= (BTRFS_BLOCK_GROUP_RAID10 |
BTRFS_BLOCK_GROUP_RAID6);
- if ((bctl->data.flags & BTRFS_BALANCE_ARGS_CONVERT) &&
- (!alloc_profile_is_valid(bctl->data.target, 1) ||
-(bctl->data.target & ~allowed))) {
+ if (balance_relocate_invalid(>data, allowed)) {
btrfs_err(fs_info, "unable to start balance with target "
"data profile %llu",
bctl->data.target);
ret = -EINVAL;
goto out;
}
- if ((bctl->meta.flags & BTRFS_BALANCE_ARGS_CONVERT) &&
- (!alloc_profile_is_valid(bctl->meta.target, 1) ||
-(bctl->meta.target & ~allowed))) {
+ if (balance_relocate_invalid(>meta, allowed)) {
btrfs_err(fs_info,
"unable to start balance with target metadata
profile %llu",
bctl->meta.target);
ret = -EINVAL;
goto out;
}
- if ((bctl->sys.flags & BTRFS_BALANCE_ARGS_CONVERT) &&
- (!alloc_profile_is_valid(bctl->sys.target, 1) ||
-(bctl->sys.target & ~allowed))) {
+ if (balance_relocate_invalid(>sys, allowed)) {
btrfs_err(fs_info,
"unable to start balance with target system profile
%llu",
bctl->sys.target);
--
2.5.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 2/2] spi: spi-ep93xx: change PTR_ERR argument
Am 30.08.2015 20:05, schrieb Julia Lawall:
> Apply PTR_ERR to the value that was recently assigned.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> expression x,y;
> @@
>
> if (IS_ERR(x) || ...) {
> ... when any
> when != IS_ERR(...)
> (
>PTR_ERR(x)
> |
> * PTR_ERR(y)
> )
> ... when any
> }
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/spi/spi-ep93xx.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-ep93xx.c b/drivers/spi/spi-ep93xx.c
> index bb00be8..1a7696c 100644
> --- a/drivers/spi/spi-ep93xx.c
> +++ b/drivers/spi/spi-ep93xx.c
> @@ -567,7 +567,8 @@ static void ep93xx_spi_dma_transfer(struct ep93xx_spi
> *espi)
> txd = ep93xx_spi_dma_prepare(espi, DMA_MEM_TO_DEV);
> if (IS_ERR(txd)) {
> ep93xx_spi_dma_finish(espi, DMA_DEV_TO_MEM);
> - dev_err(>pdev->dev, "DMA TX failed: %ld\n", PTR_ERR(rxd));
> + dev_err(>pdev->dev, "DMA TX failed: %ld\n",
> + PTR_ERR(txd));
> msg->status = PTR_ERR(txd);
> return;
> }
>
I improve readability i would suggest:
ep93xx_spi_dma_finish(espi, DMA_DEV_TO_MEM);
msg->status = PTR_ERR(txd);
dev_err(>pdev->dev, "DMA TX failed: %ld\n",msg->status):
return;
just my 2 cents,
re,
wh
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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/
[PATCH 0/2] change PTR_ERR argument
Apply PTR_ERR to the value that was recently assigned. --- var/julia/linuxcopy/drivers/spi/spi-ep93xx.c |3 ++- var/julia/linuxcopy/sound/soc/qcom/lpass-cpu.c |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) -- 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] spi: spi-ep93xx: change PTR_ERR argument
Apply PTR_ERR to the value that was recently assigned.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression x,y;
@@
if (IS_ERR(x) || ...) {
... when any
when != IS_ERR(...)
(
PTR_ERR(x)
|
* PTR_ERR(y)
)
... when any
}
//
Signed-off-by: Julia Lawall
---
drivers/spi/spi-ep93xx.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-ep93xx.c b/drivers/spi/spi-ep93xx.c
index bb00be8..1a7696c 100644
--- a/drivers/spi/spi-ep93xx.c
+++ b/drivers/spi/spi-ep93xx.c
@@ -567,7 +567,8 @@ static void ep93xx_spi_dma_transfer(struct ep93xx_spi *espi)
txd = ep93xx_spi_dma_prepare(espi, DMA_MEM_TO_DEV);
if (IS_ERR(txd)) {
ep93xx_spi_dma_finish(espi, DMA_DEV_TO_MEM);
- dev_err(>pdev->dev, "DMA TX failed: %ld\n", PTR_ERR(rxd));
+ dev_err(>pdev->dev, "DMA TX failed: %ld\n",
+ PTR_ERR(txd));
msg->status = PTR_ERR(txd);
return;
}
--
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] ASoC: qcom: change PTR_ERR argument
Apply PTR_ERR to the value that was recently assigned.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression x,y;
@@
if (IS_ERR(x) || ...) {
... when any
when != IS_ERR(...)
(
PTR_ERR(x)
|
* PTR_ERR(y)
)
... when any
}
//
Signed-off-by: Julia Lawall
---
sound/soc/qcom/lpass-cpu.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 23f3d59..94beb99 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -438,7 +438,8 @@ int asoc_qcom_lpass_cpu_platform_probe(struct
platform_device *pdev)
if (IS_ERR(drvdata->mi2s_bit_clk[dai_id])) {
dev_err(>dev,
"%s() error getting mi2s-bit-clk: %ld\n",
- __func__, PTR_ERR(drvdata->mi2s_bit_clk[i]));
+ __func__,
+ PTR_ERR(drvdata->mi2s_bit_clk[dai_id]));
return PTR_ERR(drvdata->mi2s_bit_clk[dai_id]);
}
}
--
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: Problems loading firmware using built-in drivers with kernels that use initramfs.
On Sun, Aug 30, 2015 at 1:25 AM, Arend van Spriel wrote: > On 08/29/2015 12:38 PM, Ming Lei wrote: > > Does this mean a built-in driver can not get firmware from initramfs or > built in the kernel early. Seems a bit too aggressive. Yeah, that seems wrong. Loading firmware from initramfs is required for some things, like disk drivers. Of course, depending on how it's done, it's all after the SYSTEM_BOOTING phase, but .. What we *might* do is to not allow it for the user-mode helper fallback, but I think it's more likely that we'll just deprecate the usermode helper fw loader entirely, so adding new error cases for it seems pointless. Linus -- 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: __blkg_lookup oops with 4.2-rcX
On Sun, Aug 30, 2015 at 08:30:41AM -0400, Josh Boyer wrote: > Hi Tejun, > > Mike and Jeff suggested you be informed of the oops one of our > community members is hitting in Fedora with 4.2-rcX. I thought they > had already sent this upstream to you, but apparently they didn't. > > The latest oops is below. That is with 4.2-rc8. I believe the first > report was against a merge window 4.2 kernel. The full bug report is > here: https://bugzilla.redhat.com/show_bug.cgi?id=1237136 > > I believe Mike and Jeff suspected the cgroup writeback patches. Thanks Josh. Also, I can test potential patches if you CC me on them. Rich. > josh > > lvm vgchange -a n > /run/lvm/lvmetad.socket: connect failed: No such file or directory > WARNING: Failed to connect to lvmetad. Falling back to internal scanning. > [ 36.157672] BUG: unable to handle kernel NULL pointer dereference > at 0558 > [ 36.157672] IP: [] __blkg_lookup+0x26/0x70 > [ 36.157672] PGD 0 > [ 36.157672] Oops: [#1] SMP > [ 36.157672] Modules linked in: kvm_amd kvm snd_pcsp snd_pcm > snd_timer snd soundcore serio_raw ata_generic pata_acpi libcrc32c crc8 > crc_itu_t crc_ccitt virtio_pci virtio_mmio virtio_input virtio_balloon > virtio_scsi sym53c8xx scsi_transport_spi megaraid_sas megaraid_mbox > megaraid_mm megaraid ideapad_laptop rfkill sparse_keymap video > virtio_net virtio_gpu ttm drm_kms_helper drm virtio_console virtio_rng > virtio_blk virtio_ring virtio crc32 > [ 36.157672] CPU: 0 PID: 248 Comm: lvm Not tainted > 4.2.0-0.rc8.git0.1.fc23.x86_64 #1 > [ 36.157672] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > BIOS 1.8.2-20150714_191134- 04/01/2014 > [ 36.157672] task: 88001b4e2580 ti: 88001ac0c000 task.ti: > 88001ac0c000 > [ 36.157672] RIP: 0010:[] [] > __blkg_lookup+0x26/0x70 > [ 36.157672] RSP: 0018:88001ac0fa58 EFLAGS: 0046 > [ 36.157672] RAX: RBX: RCX: > > [ 36.157672] RDX: RSI: RDI: > 820176a0 > [ 36.157672] RBP: 88001ac0fa78 R08: 88001ac0c000 R09: > 88001ce6e800 > [ 36.157672] R10: 0002 R11: 0001eaa5 R12: > 88001cc57000 > [ 36.157672] R13: 88001ccf99c8 R14: 88001ccf9f38 R15: > 88001ccba8d8 > [ 36.157672] FS: 7f9a21711880() GS:88001f00() > knlGS: > [ 36.157672] CS: 0010 DS: ES: CR0: 8005003b > [ 36.157672] CR2: 0558 CR3: 1b41d000 CR4: > 06f0 > [ 36.157672] DR0: DR1: DR2: > > [ 36.157672] DR3: DR6: DR7: > > [ 36.157672] Stack: > [ 36.157672] 82017700 820176a0 88001cc57000 > 88001ccf99c8 > [ 36.157672] 88001ac0faa8 8138d14a 88001cc570b8 > 88001ccf99c8 > [ 36.157672] 81cb1c20 88001ac0fab8 > 8138a108 > [ 36.157672] Call Trace: > [ 36.157672] [] blk_throtl_drain+0x5a/0x110 > [ 36.157672] [] blkcg_drain_queue+0x18/0x20 > [ 36.157672] [] __blk_drain_queue+0xc0/0x170 > [ 36.157672] [] blk_queue_bypass_start+0x61/0x80 > [ 36.157672] [] blkcg_deactivate_policy+0x39/0x100 > [ 36.157672] [] blk_throtl_exit+0x38/0x50 > [ 36.157672] [] blkcg_exit_queue+0x3e/0x50 > [ 36.157672] [] blk_release_queue+0x1e/0xc0 > [ 36.157672] [] kobject_release+0x7a/0x190 > [ 36.157672] [] kobject_put+0x2f/0x60 > [ 36.157672] [] blk_cleanup_queue+0x111/0x140 > [ 36.157672] [] cleanup_mapped_device+0xdc/0x100 > [ 36.157672] [] __dm_destroy+0x161/0x260 > [ 36.157672] [] dm_destroy+0x13/0x20 > [ 36.157672] [] dev_remove+0x10d/0x170 > [ 36.157672] [] ? dev_suspend+0x280/0x280 > [ 36.157672] [] ctl_ioctl+0x232/0x4d0 > [ 36.157672] [] ? SYSC_semtimedop+0x2b0/0xeb0 > [ 36.157672] [] ? __switch_to+0x261/0x4b0 > [ 36.157672] [] dm_ctl_ioctl+0x13/0x20 > [ 36.157672] [] do_vfs_ioctl+0x295/0x470 > [ 36.157672] [] ? sem_security+0x9/0x10 > [ 36.157672] [] SyS_ioctl+0x79/0x90 > [ 36.157672] [] entry_SYSCALL_64_fastpath+0x12/0x71 > [ 36.157672] Code: eb bf 0f 1f 00 66 66 66 66 90 55 48 89 e5 41 55 > 41 54 53 48 83 ec 08 48 8b 87 c8 00 00 00 48 85 c0 74 05 48 39 30 74 > 45 48 89 f3 <48> 63 b6 58 05 00 00 49 89 fd 48 8d bf b8 00 00 00 41 89 > d4 e8 > [ 36.157672] RIP [] __blkg_lookup+0x26/0x70 > [ 36.157672] RSP > [ 36.157672] CR2: 0558 > [ 36.157672] ---[ end trace a6310b2924d6c01e ]--- -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
Re: [PATCH] mei, make modules.alias UUID information easier to read
On 08/29/2015 05:21 PM, Winkler, Tomas wrote: >> >> Hi Prarit, >> >> On Fri, Aug 28, 2015 at 07:50:52AM -0400, Prarit Bhargava wrote: >>> Heikki, Tomas? >> >> I'm afraid I don't know much about Intel's Management Engine >> Interface. Looks like the driver is from Samuel (CC'd) so I'm guessing >> he is the person you wanted comments from and not me. >> > > The patch was done against the master branch instead of char-misc-next so it > doesn't apply. Anyhow I've rebased it already and I'm testing it. > I will probably re-post it, with your permission with my other mei bus fixes. Tomas, can you send me a link to your tree? > > BTW, I took the inspiration from vmbus in regards to uuid representation so > it if the uuid sting hurts you, you may fix vmbus as well. I don't have any > vmbus setup and I try not to fix things I cannot check. > I'll find a system that I can test vmbus on. P. > Thanks > Tomas > -- 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 8/8] staging: lustre: put constant on the right of binary operator
On Sat, 29 Aug 2015, Joe Perches wrote: > On Sat, 2015-08-29 at 19:30 +0200, Julia Lawall wrote: > > Move constants to the right of binary operators. > [] > > diff --git a/drivers/staging/lustre/lustre/ptlrpc/client.c > > b/drivers/staging/lustre/lustre/ptlrpc/client.c > [] > > @@ -2954,7 +2954,7 @@ void ptlrpc_init_xid(void) > > } > > > > /* Always need to be aligned to a power-of-two for multi-bulk BRW */ > > - CLASSERT((PTLRPC_BULK_OPS_COUNT & (PTLRPC_BULK_OPS_COUNT - 1)) == 0); > > + CLASSERT(((PTLRPC_BULK_OPS_COUNT - 1) & PTLRPC_BULK_OPS_COUNT) == 0); > > This one would probably be better as > > CLASSERT(is_power_of_2(PTLRPC_BULK_OPS_COUNT)); Actually not. CLASSERT requires that the expression is considered to be a constant by the compiler, such that there will be a compiler error, and the result of is_power_of_2 is not constant enough. julia -- 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: [scsi 5/7 RESEND] scsi_debug: schedule_resp fix input variable check
On Sun, 2015-08-30 at 10:36 +, Winkler, Tomas wrote: > > > > > > > > > > > > I'm just not sure why the patches are not merged or even rejected. > > > > > > Because ideally I want a Maintainer ack. That's Doug Gilbert. > > James > The patches were discussed and the ACked by Doug in February 7/7 wasn't. > and reviewed again after resend by Martin Petersen Yes, that's why I'm willing to override the lack of maintainer ack. I'll give Doug until Monday first. James -- 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 3/7] x86/vdso32: Remove unused vdso-fakesections.c
On Sat, Aug 29, 2015 at 8:20 AM, Brian Gerst wrote: > Signed-off-by: Brian Gerst Acked-by: Andy Lutomirski --Andy -- 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] spi: omap2-mcspi: add runtime PM to set_cs()
On Sun, Aug 30, 2015 at 05:45:21PM +0300, Jarkko Nikula wrote: > Hi > > On 07/24/2015 07:39 PM, Mark Brown wrote: > > On Wed, Jul 22, 2015 at 08:46:09PM +0200, Sebastian Reichel wrote: > >> Since commit ddcad7e9068eb omap2_mcspi_set_cs() is called without > >> runtime power management requested. Thus the below kernel oops may be > >> generated if a device is accessed after the runtime power management > >> timeout. This patch fixes the problem by requesting runtime power > >> management in omap2_mcspi_set_cs(). > >> > >> [ 13.933959] Unhandled fault: external abort on non-linefetch (0x1028) > >> at 0xfa09802c > >> [ 13.940490] pgd = cfb38000 > >> [ 13.946594] [fa09802c] *pgd=48011452(bad) > >> [ 13.952758] Internal error: : 1028 [#1] PREEMPT ARM > >> [ 13.958862] Modules linked in: tsc2005(+) omap_sham twl4030_wdt omap_wdt > >> [ 13.965332] CPU: 0 PID: 183 Comm: modprobe Not tainted 4.2.0-rc1+ #363 > >> [ 13.971801] Hardware name: Nokia RX-51 board > >> [ 13.978302] task: cf572300 ti: cb1f2000 task.ti: cb1f2000 > >> [ 13.984924] PC is at omap2_mcspi_set_cs+0x44/0x4c > >> [ 13.991485] LR is at spi_set_cs+0x5c/0x60 > > > > Please don't paste entire backtraces into commit messages, they are very > > large and almost entirely noise (for example in this case the entire > > explanation is in the commit message itself). If you feel a backtrace > > helps clarify things then please present an *edited* highlight of the > > relevant sections. > > present > > > Is there update to this patch? I don't see such in 4.2.0-rc8+. I hit > this same issue on Nokia N900 WLAN (CONFIG_WL1251=m and > CONFIG_WL1251_SPI=m) and googling lead to this patch which made the WLAN > working. > > If you are going to resend this, please feel free to add my tested by: > > Tested-by: Jarkko Nikula The patch is currently sitting in linux-next. Not sure why it wasn't merged with 4.2.0-rc8. -- 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 net-next 6/8] net: thunderx: Rework interrupt handler
On Sun, Aug 30, 2015 at 2:50 PM, Aleksey Makarov wrote:
> On 29.08.2015 04:44, Alexey Klimov wrote:
>
>>> -static irqreturn_t nicvf_intr_handler(int irq, void *nicvf_irq)
>>> +static irqreturn_t nicvf_intr_handler(int irq, void *cq_irq)
>>> +{
>>> + struct nicvf_cq_poll *cq_poll = (struct nicvf_cq_poll *)cq_irq;
>>> + struct nicvf *nic = cq_poll->nicvf;
>>> + int qidx = cq_poll->cq_idx;
>>> +
>>> + nicvf_dump_intr_status(nic);
>>> +
>>> + /* Disable interrupts */
>>> + nicvf_disable_intr(nic, NICVF_INTR_CQ, qidx);
>>> +
>>> + /* Schedule NAPI */
>>> + napi_schedule(_poll->napi);
>>> +
>>> + /* Clear interrupt */
>>> + nicvf_clear_intr(nic, NICVF_INTR_CQ, qidx);
>>> +
>>> + return IRQ_HANDLED;
>>> +}
>>
>>
>> You're not considering spurious irqs in all new irq handlers here and
>> below and schedule napi/tasklets unconditionally. Is it correct?
>> For me it looks like previous implementation relied on reading of
>> NIC_VF_INT to understand irq type and what actions should be
>> performed. It generally had idea that no interrupt might occur.
>
>
> 1. The previous version of the handler did not handle spurious interrupts
> either. Probably that means that the author of the patch knows for sure
> that they do not happen.
Yes, no spurious interrupts are expected from hardware.
Even if it does the NAPI poll routine will handle it as valid
descriptor count would be zero.
Don't think it makes sense to check for spurious interrupt upon every interrupt.
>
> 2. Instead of reading the status register new version registers different
> handlers for different irqs. I don't see why it can be wrong.
Previous implementation results on scheduling multiple NAPI poll handlers
on the same CPU even if IRQ's affinities are set to different CPUs.
Hence they are seperated now.
>
> I am going to address your other suggestions in the next version of the
> patchset.
>
> Thank you
> Aleksey Makarov
>
--
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/2] mpt3sas: Reference counting fixes from in-flight mpt2sas
On Sun, 2015-08-30 at 00:22 -0700, Nicholas A. Bellinger wrote: > On Fri, 2015-08-28 at 13:25 -0700, James Bottomley wrote: > > On Thu, 2015-08-27 at 12:15 -0700, Nicholas A. Bellinger wrote: > > > On Thu, 2015-08-27 at 07:40 -0700, James Bottomley wrote: > > > > On Thu, 2015-08-27 at 10:37 +0530, Sreekanth Reddy wrote: > > > > > HI Nicholas & Calvin, > > > > > > > > > > Thanks for the patchset. Sure We will review and we do some unit > > > > > testing on this patch series. Currently my bandwidth is occupied with > > > > > some internal activity, so by end of next week I will acknowledge this > > > > > series if all the thing are fine with this patch series. > > > > > > > > Calvin responded to your review feedback and that series has been > > > > outstanding for a while, so I'm not going to drop it from the misc tree. > > > > However, I will reorder to make it ready for the second push. You have > > > > until Friday week to find a problem with it. > > > > > > > > > > James, as mentioned this series is functionally identical to Calvin's > > > mpt2sas series. > > > > > > Please consider merging it to scsi.git/for-next, so both series are > > > together and in-sync. > > > > Unfortunately, the driver isn't, thanks to drift between v2 and v3 of > > the mpt_sas code bases. This patch is also dangerous: the early > > versions left unremoved objects lying around, so getting some stress > > testing from avago is very useful. At this point in the cycle, the risk > > vs reward of doing a blind upport to mpt3_sas is just too great and the > > time for review and stress testing too limited within the merge window. > > To clarify, this series is Calvin's latest -v4 mpt2sas changes that > you've already merged into for-next, and that have been applied (by > hand) to v4.2-rc1 mpt3sas code. > > If you look closer, this series is an obvious bug-fix for a class of > long-standing bugs within mpt*sas, and I don't see how keeping the > broken list_head dereferences in one LLD, but not the other makes any > sense at this point. Look, Nic, the original patches went through four reviews with issues uncovered and fixed at most of them. They're now sitting at the head of the misc tree while they get stress tested so they can easily be ejected without affecting the rest of the tree should anything fail. They're hardly "an obvious bug fix" they actually introduce a separated lifetime for _sas_device and fw_event_work. Separated lifetime patches should always be a last resort because they introduce a whole new set of lifetime handling rules for the objects. Get one of them wrong and either you free it too early (oops) or pin it forever. The general rule of thumb is never do separated lifetime objects unless you really really have to. Ideally pin them to existing core objects. The only reason I'm considering this is because no one can see how to pin _sas_device to the natural core object (scsi_device). The firmware event one doesn't make sense to me at all so I'm relying on the reviewers. Ideally a fw event is allocated in the event setup and freed in the event fire (or cancel) I really don't see we need a separated lifetime object here. you have a callback to mediate exactly whether the event fired or not in the cancel, so there's no ambiguity about ownership. Simply because of this, your upport to mp3sas can't go in without the same level of review and testing. > Unfortunately, the mpt3sas patches you've merged this week add yet more > bogus mpt3sas_scsih_sas_device_find_by_sas_address() usage. Really, > adding more broken code to mpt3sas can't possibly be better than just > merging this bug-fix series. Well, it had two reviewers per patch, one of whom was Martin Petersen who doesn't give reviewed by lightly. Funnily enough it seems the list lost your review feedback for this patch set. James -- 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] PKCS#7: Add OIDs for sha224, sha284 and sha512 hash algos and use them
Add OIDs for sha224, sha284 and sha512 hash algos and use them to select
the hashing algorithm. Without this, something like the following error
might get written to dmesg:
[ 31.829322] PKCS7: Unknown OID: [32] 2.16.840.1.101.3.4.2.3
[ 31.829328] PKCS7: Unknown OID: [180] 2.16.840.1.101.3.4.2.3
[ 31.829330] Unsupported digest algo: 55
Where the 55 on the third line is OID__NR indicating an unknown OID.
Reported-by: Valdis Kletnieks
Signed-off-by: David Howells
Tested-By: Valdis Kletnieks
---
crypto/asymmetric_keys/mscode_parser.c |9 +
crypto/asymmetric_keys/pkcs7_parser.c |8
include/linux/oid_registry.h |3 +++
3 files changed, 20 insertions(+)
diff --git a/crypto/asymmetric_keys/mscode_parser.c
b/crypto/asymmetric_keys/mscode_parser.c
index 214a992123cd..adcef59eec0b 100644
--- a/crypto/asymmetric_keys/mscode_parser.c
+++ b/crypto/asymmetric_keys/mscode_parser.c
@@ -97,6 +97,15 @@ int mscode_note_digest_algo(void *context, size_t hdrlen,
case OID_sha256:
ctx->digest_algo = HASH_ALGO_SHA256;
break;
+ case OID_sha384:
+ ctx->digest_algo = HASH_ALGO_SHA384;
+ break;
+ case OID_sha512:
+ ctx->digest_algo = HASH_ALGO_SHA512;
+ break;
+ case OID_sha224:
+ ctx->digest_algo = HASH_ALGO_SHA224;
+ break;
case OID__NR:
sprint_oid(value, vlen, buffer, sizeof(buffer));
diff --git a/crypto/asymmetric_keys/pkcs7_parser.c
b/crypto/asymmetric_keys/pkcs7_parser.c
index e6298b7a945a..758acabf2d81 100644
--- a/crypto/asymmetric_keys/pkcs7_parser.c
+++ b/crypto/asymmetric_keys/pkcs7_parser.c
@@ -229,6 +229,14 @@ int pkcs7_sig_note_digest_algo(void *context, size_t
hdrlen,
case OID_sha256:
ctx->sinfo->sig.pkey_hash_algo = HASH_ALGO_SHA256;
break;
+ case OID_sha384:
+ ctx->sinfo->sig.pkey_hash_algo = HASH_ALGO_SHA384;
+ break;
+ case OID_sha512:
+ ctx->sinfo->sig.pkey_hash_algo = HASH_ALGO_SHA512;
+ break;
+ case OID_sha224:
+ ctx->sinfo->sig.pkey_hash_algo = HASH_ALGO_SHA224;
default:
printk("Unsupported digest algo: %u\n", ctx->last_oid);
return -ENOPKG;
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index 93e0ff92fb9b..d2fa9ca42e9a 100644
--- a/include/linux/oid_registry.h
+++ b/include/linux/oid_registry.h
@@ -63,6 +63,9 @@ enum OID {
OID_certAuthInfoAccess, /* 1.3.6.1.5.5.7.1.1 */
OID_sha1, /* 1.3.14.3.2.26 */
OID_sha256, /* 2.16.840.1.101.3.4.2.1 */
+ OID_sha384, /* 2.16.840.1.101.3.4.2.2 */
+ OID_sha512, /* 2.16.840.1.101.3.4.2.3 */
+ OID_sha224, /* 2.16.840.1.101.3.4.2.4 */
/* Distinguished Name attribute IDs [RFC 2256] */
OID_commonName, /* 2.5.4.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/
Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote: > So let me withdraw my ack: the much more important question that I > missed first time around, why is this reporting feature living in > hwmon, not in perf? We have energy reporting facilities in perf that > this should be synced to. Because there's already fam15h_power driver which is exactly for that. Making it part of perf is then a question of cat-ting the same sysfs file twice, at the beginning and at the end of the trace, which is trivial. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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 V4 2/2] net: Optimize snmp stat aggregation by walking all the percpu data at once
On Sun, 2015-08-30 at 11:29 +0530, Raghavendra K T wrote: > Docker container creation linearly increased from around 1.6 sec to 7.5 sec > (at 1000 containers) and perf data showed 50% ovehead in snmp_fold_field. > > reason: currently __snmp6_fill_stats64 calls snmp_fold_field that walks > through per cpu data of an item (iteratively for around 36 items). > > idea: This patch tries to aggregate the statistics by going through > all the items of each cpu sequentially which is reducing cache > misses. > > Docker creation got faster by more than 2x after the patch. > > Result: >Before After > Docker creation time 6.836s 3.25s > cache miss 2.7% 1.41% > > perf before: > 50.73% docker [kernel.kallsyms] [k] snmp_fold_field > 9.07% swapper [kernel.kallsyms] [k] snooze_loop > 3.49% docker [kernel.kallsyms] [k] veth_stats_one > 2.85% swapper [kernel.kallsyms] [k] _raw_spin_lock > > perf after: > 10.57% docker docker[.] scanblock > 8.37% swapper [kernel.kallsyms] [k] snooze_loop > 6.91% docker [kernel.kallsyms] [k] snmp_get_cpu_field > 6.67% docker [kernel.kallsyms] [k] veth_stats_one > > changes/ideas suggested: > Using buffer in stack (Eric), Usage of memset (David), Using memcpy in > place of unaligned_put (Joe). > > Signed-off-by: Raghavendra K T > --- Acked-by: Eric Dumazet 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/
[PATCH v4 1/8] phy: qcom-ufs: fix build error when the component is built as a module
Export the following functions in order to avoid build errors
when the component PHY_QCOM_UFS is compiled as a module:
ERROR: "ufs_qcom_phy_disable_ref_clk"
[drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_enable_ref_clk"
[drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_is_pcs_ready"
[drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_disable_iface_clk"
[drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_start_serdes"
[drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_calibrate_phy"
[drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_enable_dev_ref_clk"
[drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_set_tx_lane_enable"
[drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_disable_dev_ref_clk"
[drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_save_controller_version"
[drivers/scsi/ufs/ufs-qcom.ko] undefined!
ERROR: "ufs_qcom_phy_enable_iface_clk"
[drivers/scsi/ufs/ufs-qcom.ko] undefined!
make[1]: *** [__modpost] Error 1
Signed-off-by: Yaniv Gardi
---
drivers/phy/phy-qcom-ufs.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/phy/phy-qcom-ufs.c b/drivers/phy/phy-qcom-ufs.c
index f9c618f..6140a8b 100644
--- a/drivers/phy/phy-qcom-ufs.c
+++ b/drivers/phy/phy-qcom-ufs.c
@@ -432,6 +432,7 @@ out_disable_src:
out:
return ret;
}
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_enable_ref_clk);
static
int ufs_qcom_phy_disable_vreg(struct phy *phy,
@@ -474,6 +475,7 @@ void ufs_qcom_phy_disable_ref_clk(struct phy *generic_phy)
phy->is_ref_clk_enabled = false;
}
}
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_disable_ref_clk);
#define UFS_REF_CLK_EN (1 << 5)
@@ -517,11 +519,13 @@ void ufs_qcom_phy_enable_dev_ref_clk(struct phy
*generic_phy)
{
ufs_qcom_phy_dev_ref_clk_ctrl(generic_phy, true);
}
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_enable_dev_ref_clk);
void ufs_qcom_phy_disable_dev_ref_clk(struct phy *generic_phy)
{
ufs_qcom_phy_dev_ref_clk_ctrl(generic_phy, false);
}
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_disable_dev_ref_clk);
/* Turn ON M-PHY RMMI interface clocks */
int ufs_qcom_phy_enable_iface_clk(struct phy *generic_phy)
@@ -550,6 +554,7 @@ int ufs_qcom_phy_enable_iface_clk(struct phy *generic_phy)
out:
return ret;
}
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_enable_iface_clk);
/* Turn OFF M-PHY RMMI interface clocks */
void ufs_qcom_phy_disable_iface_clk(struct phy *generic_phy)
@@ -562,6 +567,7 @@ void ufs_qcom_phy_disable_iface_clk(struct phy *generic_phy)
phy->is_iface_clk_enabled = false;
}
}
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_disable_iface_clk);
int ufs_qcom_phy_start_serdes(struct phy *generic_phy)
{
@@ -578,6 +584,7 @@ int ufs_qcom_phy_start_serdes(struct phy *generic_phy)
return ret;
}
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_start_serdes);
int ufs_qcom_phy_set_tx_lane_enable(struct phy *generic_phy, u32 tx_lanes)
{
@@ -595,6 +602,7 @@ int ufs_qcom_phy_set_tx_lane_enable(struct phy
*generic_phy, u32 tx_lanes)
return ret;
}
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_set_tx_lane_enable);
void ufs_qcom_phy_save_controller_version(struct phy *generic_phy,
u8 major, u16 minor, u16 step)
@@ -605,6 +613,7 @@ void ufs_qcom_phy_save_controller_version(struct phy
*generic_phy,
ufs_qcom_phy->host_ctrl_rev_minor = minor;
ufs_qcom_phy->host_ctrl_rev_step = step;
}
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_save_controller_version);
int ufs_qcom_phy_calibrate_phy(struct phy *generic_phy, bool is_rate_B)
{
@@ -625,6 +634,7 @@ int ufs_qcom_phy_calibrate_phy(struct phy *generic_phy,
bool is_rate_B)
return ret;
}
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_calibrate_phy);
int ufs_qcom_phy_remove(struct phy *generic_phy,
struct ufs_qcom_phy *ufs_qcom_phy)
@@ -662,6 +672,7 @@ int ufs_qcom_phy_is_pcs_ready(struct phy *generic_phy)
return ufs_qcom_phy->phy_spec_ops->
is_physical_coding_sublayer_ready(ufs_qcom_phy);
}
+EXPORT_SYMBOL_GPL(ufs_qcom_phy_is_pcs_ready);
int ufs_qcom_phy_power_on(struct phy *generic_phy)
{
--
1.8.5.2
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
--
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/
