* [Buildroot] [PATCH 1/4] configs: atmel: at91sam9260eknf: update defconfig
From: Ludovic Desroches @ 2016-11-09 10:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109073638.ozgbr5vy6gglznlx@tarshish>
On Wed, Nov 09, 2016 at 09:36:38AM +0200, Baruch Siach wrote:
> Hi Ludovic,
>
> On Wed, Nov 09, 2016 at 07:59:45AM +0100, Ludovic Desroches wrote:
> > Bump to a recent version of AT91bootstrap and use mainline version of
> > U-Boot and Linux.
> >
> > Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> > ---
> > configs/at91sam9260eknf_defconfig | 22 ++++++++++++----------
> > 1 file changed, 12 insertions(+), 10 deletions(-)
> >
> > diff --git a/configs/at91sam9260eknf_defconfig b/configs/at91sam9260eknf_defconfig
> > index 92bb071..4c17cb6 100644
> > --- a/configs/at91sam9260eknf_defconfig
> > +++ b/configs/at91sam9260eknf_defconfig
> > @@ -2,9 +2,6 @@
> > BR2_arm=y
> > BR2_arm926t=y
> >
> > -# Linux headers same as kernel, a 3.9 series
> > -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_9=y
> > -
> > # Packages
> > BR2_PACKAGE_HOST_SAM_BA=y
> >
> > @@ -13,15 +10,20 @@ BR2_TARGET_ROOTFS_UBIFS=y
> > BR2_TARGET_ROOTFS_UBI=y
> >
> > # Bootloaders
> > -BR2_TARGET_AT91BOOTSTRAP=y
> > -BR2_TARGET_AT91BOOTSTRAP_BOARD="at91sam9260ek"
> > -BR2_TARGET_AT91BOOTSTRAP_NANDFLASH=y
> > +BR2_TARGET_AT91BOOTSTRAP3=y
> > +BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_GIT=y
> > +BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_REPO_URL="https://github.com/linux4sam/at91bootstrap.git"
> > +BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_REPO_VERSION="v3.8.7"
> > +BR2_TARGET_AT91BOOTSTRAP3_DEFCONFIG="at91sam9260eknf_uboot"
> > BR2_TARGET_BAREBOX=y
> > BR2_TARGET_BAREBOX_BOARD_DEFCONFIG="at91sam9260ek"
> > +BR2_TARGET_UBOOT=y
> > +BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
> > +BR2_TARGET_UBOOT_BOARD_DEFCONFIG="at91sam9260ek_nandflash"
>
> Why enable both U-Boot and Barebox?
>
I don't know why Barebox was selected but the 'official' bootloader is
U-Boot for all our products that's why I add it. I kept Barebox because
it was already selected and I don't know if someone is still using it or
not.
> > # Kernel
> > BR2_LINUX_KERNEL=y
> > -BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.9.1"
>
> For the sake of reproducibility you should set this to the version you tested,
> say, 4.8.6. The same goes for other patches in this series.
>
As Alexandre said, we don't want to spend time for the maintainance of these
old boards so sticking to the mainline seems to be the way to go. Giving a
version is a kind of commitment but we no longer perform tests on these
boards excepting kernel boot with kernelci.
> > -BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
> > -BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/atmel/at91sam9260ek/linux-3.9.config"
>
> You can now drop this file.
Ok.
>
> > +BR2_LINUX_KERNEL_DEFCONFIG="at91_dt"
> > +BR2_LINUX_KERNEL_DTS_SUPPORT=y
> > +BR2_LINUX_KERNEL_INTREE_DTS_NAME="at91sam9260ek"
>
> baruch
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* Re: Lots of radosgw-admin commands fail after upgrade
From: Orit Wasserman @ 2016-11-09 10:11 UTC (permalink / raw)
To: Mustafa Muhammad; +Cc: ceph-devel
In-Reply-To: <CAFehDbDDF0cMiHre0DnbSD2-sxc6cFubLVHSOs2HMTtLbkeKJA@mail.gmail.com>
On Wed, Nov 9, 2016 at 6:45 AM, Mustafa Muhammad <mustafa1024m@gmail.com> wrote:
> On Tue, Nov 8, 2016 at 3:16 PM, Orit Wasserman <owasserm@redhat.com> wrote:
>> On Tue, Nov 8, 2016 at 1:11 PM, Mustafa Muhammad <mustafa1024m@gmail.com> wrote:
>>> On Tue, Nov 8, 2016 at 2:21 PM, Orit Wasserman <owasserm@redhat.com> wrote:
>>>> On Mon, Nov 7, 2016 at 10:05 AM, Mustafa Muhammad
>>>> <mustafa1024m@gmail.com> wrote:
>>>>> I understood the script and applied it, "zone get" works fine now with
>>>>> realm, but "radosgw-admin zonegroup get" gives "master_zone":
>>>>> "default" and realm id with value, then after a minute it goes back to
>>>>> empty master_zone and realm id.
>>>>
>>>> Hi,
>>>> Is it possible you have an old radosgw-admin running (from hammer)?
>>>> if so you encountered http://tracker.ceph.com/issues/17371, it will be
>>>> fixed in 10.2.4.
>>>
>>> I found I have one Infernalis 9.2.1
>>>
>>
>> that explains it ...
>>
>>>> Can you provides logs?
>>>
>>> What logs exactly?
>>>
>> rgw logs but it looks like we know the cause so it is not important.
>>
>>>>
>>>> Try the procedure again and this time also run in the end:
>>>> radosgw-admin period update --commit
>>>
>>> After updating that RGW?
>>>
>> yes after doing all the steps
>>
> All RGWs now on 10.2.2, can't make them 10.2.3 because they won't start.
> Stopped them all and run the script again with "radosgw-admin period
> update --commit" at the end, still getting:
> "zonegroup default missing zone for master_zone="
> If I wait till 10.2.4, should it be fixed?
>
yes it was fixed in 10.2.4
> Regards
> Mustafa
>
>>>>
>>>> Orit
>>>>
>>>
>>> Thanks a lot :)
>>>
>>> Regards
>>> Mustafa
>>>
>>>>> So I still get:
>>>>> radosgw-admin bucket stats
>>>>> 2016-11-07 12:04:13.680779 7f7a88e929c0 0 zonegroup default missing
>>>>> zone for master_zone=
>>>>> couldn't init storage provider
>>>>> What should I do?
>>>>>
>>>>> Thanks
>>>>> Mustafa
>>>>>
>>>>> On Wed, Nov 2, 2016 at 12:39 PM, Orit Wasserman <owasserm@redhat.com> wrote:
>>>>>> Hi,
>>>>>> You have hit the master zone issue.
>>>>>> Here is a fix I prefer:
>>>>>> http://lists.ceph.com/pipermail/ceph-users-ceph.com/2016-July/011157.html
>>>>>> It is very important notice to run the fix when the radosgw is down.
>>>>>>
>>>>>> Good luck,
>>>>>> Orit
>>>>>>
>>>>>> On Tue, Nov 1, 2016 at 10:07 PM, Mustafa Muhammad
>>>>>> <mustafa1024m@gmail.com> wrote:
>>>>>>> On Tue, Nov 1, 2016 at 5:04 PM, Orit Wasserman <owasserm@redhat.com> wrote:
>>>>>>>> Hi,
>>>>>>>> what version of jewel are you using?
>>>>>>>> can you try raodsgw-admin zone get --rgw-zone default and
>>>>>>>> radosgw-admin zonegroup get --rgw-zonegroup default?
>>>>>>>>
>>>>>>> Hello, I am using 10.2.3
>>>>>>> #radosgw-admin zone get --rgw-zone default
>>>>>>> {
>>>>>>> "id": "default",
>>>>>>> "name": "default",
>>>>>>> "domain_root": ".rgw",
>>>>>>> "control_pool": ".rgw.control",
>>>>>>> "gc_pool": ".rgw.gc",
>>>>>>> "log_pool": ".log",
>>>>>>> "intent_log_pool": ".intent-log",
>>>>>>> "usage_log_pool": ".usage",
>>>>>>> "user_keys_pool": ".users",
>>>>>>> "user_email_pool": ".users.email",
>>>>>>> "user_swift_pool": ".users.swift",
>>>>>>> "user_uid_pool": ".users.uid",
>>>>>>> "system_key": {
>>>>>>> "access_key": "",
>>>>>>> "secret_key": ""
>>>>>>> },
>>>>>>> "placement_pools": [],
>>>>>>> "metadata_heap": ".rgw.meta",
>>>>>>> "realm_id": ""
>>>>>>> }
>>>>>>>
>>>>>>> # radosgw-admin zonegroup get --rgw-zonegroup default
>>>>>>> {
>>>>>>> "id": "default",
>>>>>>> "name": "default",
>>>>>>> "api_name": "",
>>>>>>> "is_master": "true",
>>>>>>> "endpoints": [],
>>>>>>> "hostnames": [],
>>>>>>> "hostnames_s3website": [],
>>>>>>> "master_zone": "",
>>>>>>> "zones": [
>>>>>>> {
>>>>>>> "id": "default",
>>>>>>> "name": "default",
>>>>>>> "endpoints": [],
>>>>>>> "log_meta": "false",
>>>>>>> "log_data": "false",
>>>>>>> "bucket_index_max_shards": 0,
>>>>>>> "read_only": "false"
>>>>>>> }
>>>>>>> ],
>>>>>>> "placement_targets": [
>>>>>>> {
>>>>>>> "name": "cinema-placement",
>>>>>>> "tags": []
>>>>>>> },
>>>>>>> {
>>>>>>> "name": "cinema-source-placement",
>>>>>>> "tags": []
>>>>>>> },
>>>>>>> {
>>>>>>> "name": "default-placement",
>>>>>>> "tags": []
>>>>>>> },
>>>>>>> {
>>>>>>> "name": "erasure-placement",
>>>>>>> "tags": []
>>>>>>> },
>>>>>>> {
>>>>>>> "name": "share-placement",
>>>>>>> "tags": []
>>>>>>> },
>>>>>>> {
>>>>>>> "name": "share2016-placement",
>>>>>>> "tags": []
>>>>>>> },
>>>>>>> {
>>>>>>> "name": "test-placement",
>>>>>>> "tags": []
>>>>>>> }
>>>>>>> ],
>>>>>>> "default_placement": "default-placement",
>>>>>>> "realm_id": ""
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Mustafa
>>>>>>>
>>>>>>>> Orit
>>>>>>>>
>>>>>>>> On Tue, Nov 1, 2016 at 2:13 PM, Mustafa Muhammad <mustafa1024m@gmail.com> wrote:
>>>>>>>>> Hello,
>>>>>>>>> I have production cluster configured with multiple placement pools according to:
>>>>>>>>>
>>>>>>>>> http://cephnotes.ksperis.com/blog/2014/11/28/placement-pools-on-rados-gw
>>>>>>>>>
>>>>>>>>> After upgrading to Jewel, most radosgw-admin are failing, probably
>>>>>>>>> because there is no realm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # radosgw-admin realm list
>>>>>>>>> {
>>>>>>>>> "default_info": "",
>>>>>>>>> "realms": []
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # radosgw-admin zone get
>>>>>>>>> unable to initialize zone: (2) No such file or directory
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # radosgw-admin regionmap get
>>>>>>>>> failed to read current period info: 2016-11-01 16:08:14.099948
>>>>>>>>> 7f21b55ee9c0 0 RGWPeriod::init failed to init realm id : (2) No
>>>>>>>>> such file or directory(2) No such file or directory
>>>>>>>>> {
>>>>>>>>> "zonegroups": [],
>>>>>>>>> "master_zonegroup": "",
>>>>>>>>> "bucket_quota": {
>>>>>>>>> "enabled": false,
>>>>>>>>> "max_size_kb": -1,
>>>>>>>>> "max_objects": -1
>>>>>>>>> },
>>>>>>>>> "user_quota": {
>>>>>>>>> "enabled": false,
>>>>>>>>> "max_size_kb": -1,
>>>>>>>>> "max_objects": -1
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # radosgw-admin bucket stats
>>>>>>>>> 2016-11-01 16:07:55.860053 7f6e747f89c0 0 zonegroup default missing
>>>>>>>>> zone for master_zone=
>>>>>>>>> couldn't init storage provider
>>>>>>>>>
>>>>>>>>> I have previous region.conf.json and zone.conf.json, how can I make
>>>>>>>>> everything work again? Will creating new realm fix this?
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Mustafa Muhammad
>>>>>>>>> --
>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: module: Ensure a module's state is set accordingly during module coming cleanup code
From: Jessica Yu @ 2016-11-09 10:12 UTC (permalink / raw)
To: Rusty Russell; +Cc: Aaron Tomlin, linux-kernel, rostedt
In-Reply-To: <87funk3p6f.fsf@rustcorp.com.au>
+++ Rusty Russell [26/10/16 11:24 +1030]:
>Aaron Tomlin <atomlin@redhat.com> writes:
>> In load_module() in the event of an error, for e.g. unknown module
>> parameter(s) specified we go to perform some module coming clean up
>> operations. At this point the module is still in a "formed" state
>> when it is actually going away.
>>
>> This patch updates the module's state accordingly to ensure anyone on the
>> module_notify_list waiting for a module going away notification will be
>> notified accordingly.
>
>I recall a similar proposal before.
>
>I've audited all the subscribers to check they didn't look at
>mod->state; they seem OK.
>
>We actually do this in the init-failed path, so this should be OK.
We did discuss a similar proposal before:
https://lkml.kernel.org/r/87a8m7ko6j.fsf@rustcorp.com.au
The complaint back then was that we need to be in the COMING state for
strong_try_module_get() to fail. But it will also correctly fail for GOING
modules in the module_is_live() check in the subsequent call to
try_module_get(), so I believe we are still OK here.
Jessica
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: Intel: atom: Add sysfs entry in order to store FW version
From: Vinod Koul @ 2016-11-09 10:21 UTC (permalink / raw)
To: Sebastien Guiriec; +Cc: liam.r.girdwood, alsa-devel, pierre-louis.bossart
In-Reply-To: <51eb5a2d-94e0-56d8-817f-eedf632935eb@intel.com>
On Tue, Nov 08, 2016 at 09:29:15AM +0100, Sebastien Guiriec wrote:
> >we should do this only after FW load, can you add that bit please. ALso
> >check we dont leak kernel memory when this is not set
> >
>
> Ok in case of v00.00.00.00 I will return "FW not yet Loaded".
> Is it ok for you?
Yes sounds good to me :)
--
~Vinod
^ permalink raw reply
* [Buildroot] [PATCH 1/4] configs: atmel: at91sam9260eknf: update defconfig
From: Alexandre Belloni @ 2016-11-09 10:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109100027.yqe6ilsxofi2t4ey@tarshish>
On 09/11/2016 at 12:00:27 +0200, Baruch Siach wrote :
> Hi Alexandre,
>
> On Wed, Nov 09, 2016 at 10:52:49AM +0100, Alexandre Belloni wrote:
> > On 09/11/2016 at 09:36:38 +0200, Baruch Siach wrote :
> > > On Wed, Nov 09, 2016 at 07:59:45AM +0100, Ludovic Desroches wrote:
> > > > # Kernel
> > > > BR2_LINUX_KERNEL=y
> > > > -BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > > > -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.9.1"
> > >
> > > For the sake of reproducibility you should set this to the version you tested,
> > > say, 4.8.6. The same goes for other patches in this series.
> >
> > I'm not sure this is actually useful because the amount of testing is
> > minimal and it just increases the maintenance burden.
>
> I don't understand. How would locking a specific kernel version in the
> defconfig increase maintenance burden? Any tested kernel version would do. We
> just want to ensure consistent user experience. Otherwise the built kernel
> will change with the default value of BR2_LINUX_KERNEL_VERSION.
>
Yeah, that's my point. Any kernel version will do and that avoids having
to update it in the defconfig all the time, hence less maintenance. The
previous defconfig has not been building for a while (basically, since
the switch to gcc5).
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [Qemu-devel] [Bug 1639394] Re: Unable to boot Solaris 8/9 x86 under Fedora 24
From: xtrondo @ 2016-11-09 10:00 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20161108231359.15987.62478.malone@chaenomeles.canonical.com>
yes, 10/11/12 beta work without a problem(and really fast), 8/9 have been
reported to work at least since 0.6.0. with the "ide" fix committed to that
version.
The problem seems related with "ide" emulation and real mode drivers, so I
don't think an older BSD can reproduce.
I will test if an older BSD is also affected by this, I can also provide
you a place for you to get the versions 8/9 x86 iso, if that is ok
in any way.
Many thanks for the time on checking this one.
On Tue, Nov 8, 2016 at 11:13 PM, John Snow <1639394@bugs.launchpad.net>
wrote:
> So, if I'm reading you right, Solaris10/11 work just fine, but 8/9 don't
> -- and have not since qemu version 0.6.0!? From 2004?
>
> I don't have a copy of Solaris9 to test with, so I doubt I can work on
> trying to reproduce this. Is there any possibility to reproduce a
> problem on an older, freely available BSD?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1639394
>
> Title:
> Unable to boot Solaris 8/9 x86 under Fedora 24
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1639394/+subscriptions
>
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1639394
Title:
Unable to boot Solaris 8/9 x86 under Fedora 24
Status in QEMU:
New
Bug description:
qemu-system-x86_64 -version
QEMU emulator version 2.6.2 (qemu-2.6.2-4.fc24), Copyright (c) 2003-2008 Fabrice Bellard
Try several ways without success, I think it was a regression because problem seems to be related with ide fixed on 0.6.0:
- int13 CDROM BIOS fix (aka Solaris x86 install CD fix)
- int15, ah=86 BIOS fix (aka Solaris x86 hardware probe hang up fix)
Solaris 10/11 works without a problem, also booting with "scsi" will
circumvent initial problem, but later found problems related with
"scsi" cdrom boot and also will not found the "ide" disk device.
qemu-system-i386 -m 712 -drive file=/dev/Virtual_hdd/beryllium0,format=raw -cdrom /repo/Isos/sol-9_905_x86.iso
SunOS Secondary Boot version 3.00
prom_panic: Could not mount filesystem.
Entering boot debugger:
[136419]
Regards,
\\CA,
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1639394/+subscriptions
^ permalink raw reply
* [PATCH v3 0/3] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: linux-arm-kernel
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (3):
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++--
5 files changed, 47 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v3 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161109101349.18722-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
Changes in v3:
- Replaced the type of hm_mask and fm_mask by unsigned int,
instead of unsigned long.
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..09619db 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -55,6 +55,7 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
/*
@@ -91,6 +92,13 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -98,6 +106,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -122,7 +131,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
#define ICR_SADIE (1 << 13) /* slave address detected int enable */
#define ICR_UR (1 << 14) /* unit reset */
#define ICR_FM (1 << 15) /* fast mode */
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
#define ICR_HS (1 << 16) /* High Speed mode */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
#define ICR_GPIOEN (1 << 19) /* enable GPIO mode for SCL in HS */
#define ISR_RWM (1 << 0) /* read/write mode */
@@ -193,6 +204,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ unsigned int fm_mask;
+ unsigned int hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +516,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1137,6 +1150,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1158,6 +1172,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
i2c->use_pio = 1;
if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
i2c->fast_mode = 1;
+ if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
+ i2c->fm_mask = ICR_BUSMODE_FM;
+ i2c->hs_mask = ICR_BUSMODE_HS;
+ } else {
+ i2c->fm_mask = ICR_FM;
+ i2c->hs_mask = ICR_HS;
+ }
*i2c_types = (enum pxa_i2c_types)(of_id->data);
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109101349.18722-1-romain.perier@free-electrons.com>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Changes in v3:
- Replaced the type of hm_mask and fm_mask by unsigned int,
instead of unsigned long.
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..09619db 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -55,6 +55,7 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
/*
@@ -91,6 +92,13 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -98,6 +106,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -122,7 +131,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
#define ICR_SADIE (1 << 13) /* slave address detected int enable */
#define ICR_UR (1 << 14) /* unit reset */
#define ICR_FM (1 << 15) /* fast mode */
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
#define ICR_HS (1 << 16) /* High Speed mode */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
#define ICR_GPIOEN (1 << 19) /* enable GPIO mode for SCL in HS */
#define ISR_RWM (1 << 0) /* read/write mode */
@@ -193,6 +204,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ unsigned int fm_mask;
+ unsigned int hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +516,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1137,6 +1150,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1158,6 +1172,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
i2c->use_pio = 1;
if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
i2c->fast_mode = 1;
+ if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
+ i2c->fm_mask = ICR_BUSMODE_FM;
+ i2c->hs_mask = ICR_BUSMODE_HS;
+ } else {
+ i2c->fm_mask = ICR_FM;
+ i2c->hs_mask = ICR_HS;
+ }
*i2c_types = (enum pxa_i2c_types)(of_id->data);
--
2.9.3
^ permalink raw reply related
* [PATCH v3 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161109101349.18722-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c476253..bf2d73d 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c@11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_perih_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c@11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_perih_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial@12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109101349.18722-1-romain.perier@free-electrons.com>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c476253..bf2d73d 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c at 11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_perih_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_perih_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial at 12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
^ permalink raw reply related
* [PATCH v3 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109101349.18722-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* [PATCH v3 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, linux-arm-kernel, Thomas Petazzoni, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas <mw>
In-Reply-To: <20161109101349.18722-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* [PATCH v3 0/3] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, linux-arm-kernel, Thomas Petazzoni, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas <mw>
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (3):
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++--
5 files changed, 47 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: gcc-4.6.3, was Re: Debian on mac68k
From: John Paul Adrian Glaubitz @ 2016-11-09 10:14 UTC (permalink / raw)
To: Michael Schmitz, Finn Thain; +Cc: debian-68k, linux-m68k
In-Reply-To: <b731fd59-03b7-a443-650b-c023c1190385@gmail.com>
On 11/09/2016 07:50 AM, Michael Schmitz wrote:
> Having something like ARAnyM for Mac or Amiga would increase coverage,
> but the varied and quirky Mac hardware out there makes that almost
> pointless again.
Current versions of WinUAE or fs-uae (available in Debian) should actually
be able to boot Linux now as they include MMU support now. Haven't tried
it yet though.
Adrian
^ permalink raw reply
* [bug report] iio: adc: ti-adc161s626: add regulator support
From: Dan Carpenter @ 2016-11-09 10:14 UTC (permalink / raw)
To: mranostay
Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio
Hello Matt Ranostay,
The patch 92f0afb5b2be: "iio: adc: ti-adc161s626: add regulator
support" from Sep 18, 2016, leads to the following static checker
warning:
drivers/iio/adc/ti-adc161s626.c:237 ti_adc_probe()
error: 'data->ref' dereferencing possible ERR_PTR()
drivers/iio/adc/ti-adc161s626.c
214
215 data->ref = devm_regulator_get(&spi->dev, "vdda");
216 if (!IS_ERR(data->ref)) {
217 ret = regulator_enable(data->ref);
218 if (ret < 0)
219 return ret;
220 }
This code assumes that devm_regulator_get() can fail and we continue
with what we have, but none of the rest of the driver assumes that.
221
222 ret = iio_triggered_buffer_setup(indio_dev, NULL,
223 ti_adc_trigger_handler, NULL);
224 if (ret)
225 goto error_regulator_disable;
226
227 ret = iio_device_register(indio_dev);
228 if (ret)
229 goto error_unreg_buffer;
230
231 return 0;
232
233 error_unreg_buffer:
234 iio_triggered_buffer_cleanup(indio_dev);
235
236 error_regulator_disable:
237 regulator_disable(data->ref);
Every reference to "data->ref" needs to be updated to wrapped in
"if (!IS_ERR(data->ref)) " otherwise it will oops.
238
239 return ret;
240 }
regards,
dan carpenter
^ permalink raw reply
* [Buildroot] [PATCH 1/4] configs: atmel: at91sam9260eknf: update defconfig
From: Ludovic Desroches @ 2016-11-09 10:15 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109100027.yqe6ilsxofi2t4ey@tarshish>
On Wed, Nov 09, 2016 at 12:00:27PM +0200, Baruch Siach wrote:
> Hi Alexandre,
>
> On Wed, Nov 09, 2016 at 10:52:49AM +0100, Alexandre Belloni wrote:
> > On 09/11/2016 at 09:36:38 +0200, Baruch Siach wrote :
> > > On Wed, Nov 09, 2016 at 07:59:45AM +0100, Ludovic Desroches wrote:
> > > > # Kernel
> > > > BR2_LINUX_KERNEL=y
> > > > -BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > > > -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.9.1"
> > >
> > > For the sake of reproducibility you should set this to the version you tested,
> > > say, 4.8.6. The same goes for other patches in this series.
> >
> > I'm not sure this is actually useful because the amount of testing is
> > minimal and it just increases the maintenance burden.
>
> I don't understand. How would locking a specific kernel version in the
> defconfig increase maintenance burden? Any tested kernel version would do. We
> just want to ensure consistent user experience. Otherwise the built kernel
> will change with the default value of BR2_LINUX_KERNEL_VERSION.
>
That's the goal. Kernel was no longer compiling because it was too old
to be used with gcc5. We may have the same situation in the future and
we'll simply choose the latest kernel release for the update as I do today.
That's why Alexandre says that it will increase the maintenance.
Ludovic
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
From: Sergey Smolov @ 2016-11-09 10:15 UTC (permalink / raw)
To: Cornelia Huck
Cc: Samuel Thibault, Peter Maydell, Michal Suchanek, QEMU Developers
In-Reply-To: <20161109110400.118d4750.cornelia.huck@de.ibm.com>
On 09.11.2016 13:04, Cornelia Huck wrote:
> On Wed, 9 Nov 2016 10:52:38 +0100
> Samuel Thibault <samuel.thibault@gnu.org> wrote:
>
>> Hello,
>>
>> Cornelia Huck, on Wed 09 Nov 2016 10:40:28 +0100, wrote:
>>> Still curses=no... log attached.
>> Oops, sorry, I misplaced my code, and it somehow worked in my case.
>> Could you give a try at the attached patch instead?
> Works for me on SLES, Fedora, Ubuntu.
>
> Tested-by: Cornelia Huck <cornelia.huck@de.ibm.com>
>
> Sergey, could you test whether the patch works for you as well?
> (Inserted for convenience.)
>
> commit cc8965eb848f53599895a650a6e062319189be1f
> Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
> Date: Tue Nov 8 20:57:27 2016 +0100
>
> Fix cursesw detection
>
> On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
> does not include wide support, we should not only try with no -I, i.e.
> /usr/include, but also with -I/usr/include/ncursesw.
>
> To properly detect for wide support with and without -Werror, we need to
> check for the presence of e.g. the WACS_DEGREE macro.
>
> We also want to stop at the first curses_inc_list configuration which works,
> and make sure to set IFS to : at each new loop.
>
> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>
> diff --git a/configure b/configure
> index fd6f898..7d2a34e 100755
> --- a/configure
> +++ b/configure
> @@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
> curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
> curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
> else
> - curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
> + curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):-I/usr/include/ncursesw:"
> curses_lib_list="$($pkg_config --libs ncursesw 2>/dev/null):-lncursesw:-lcursesw"
> fi
> curses_found=no
> @@ -2941,11 +2941,13 @@ int main(void) {
> resize_term(0, 0);
> addwstr(L"wide chars\n");
> addnwstr(&wch, 1);
> + add_wch(WACS_DEGREE);
> return s != 0;
> }
> EOF
> IFS=:
> for curses_inc in $curses_inc_list; do
> + IFS=:
> for curses_lib in $curses_lib_list; do
> unset IFS
> if compile_prog "$curses_inc" "$curses_lib" ; then
> @@ -2955,6 +2957,9 @@ EOF
> break
> fi
> done
> + if test "$curses_found" = yes ; then
> + break
> + fi
> done
> unset IFS
> if test "$curses_found" = "yes" ; then
>
It works, thank you!
Is it planned to publish this patch into master?
--
Thanks,
Sergey Smolov
^ permalink raw reply
* [ovmf test] 102050: all pass - PUSHED
From: osstest service owner @ 2016-11-09 10:15 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 102050 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102050/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 008e2ccf02e7be65b3a1b48a925f005115027d1c
baseline version:
ovmf fef15ecd20dd8db5bf0c33b00908fc59491dba8a
Last test of basis 102036 2016-11-08 12:14:46 Z 0 days
Testing same since 102050 2016-11-08 20:54:26 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Jiewen Yao <jiewen.yao@intel.com>
Michael Kinney <michael.d.kinney@intel.com>
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=008e2ccf02e7be65b3a1b48a925f005115027d1c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 008e2ccf02e7be65b3a1b48a925f005115027d1c
+ branch=ovmf
+ revision=008e2ccf02e7be65b3a1b48a925f005115027d1c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x008e2ccf02e7be65b3a1b48a925f005115027d1c = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osstest@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osstest@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/qemu-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
++ : daily-cron.ovmf
++ : git://xenbits.xen.org/qemu-xen.git
++ : git://git.qemu.org/qemu.git
+ TREE_LINUX=osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
+ TREE_XEN=osstest@xenbits.xen.org:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xen.org:/home/xen/git/libvirt.git
+ TREE_RUMPRUN=osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
+ TREE_SEABIOS=osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
+ TREE_OVMF=osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
+ TREE_XTF=osstest@xenbits.xen.org:/home/xen/git/xtf.git
+ info_linux_tree ovmf
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /home/osstest/repos/ovmf
+ git push osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git 008e2ccf02e7be65b3a1b48a925f005115027d1c:refs/heads/xen-tested-master
To osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
fef15ec..008e2cc 008e2ccf02e7be65b3a1b48a925f005115027d1c -> xen-tested-master
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [Ocfs2-devel] ocfs2: A race about mle is unlinked and freed for the dead node, BUG
From: Zhangguanghui @ 2016-11-09 10:17 UTC (permalink / raw)
To: ocfs2-devel
In-Reply-To: <mailman.3.1478635201.364.ocfs2-devel@oss.oracle.com>
Hi All,
when the mle have been used in dlm_get_lock_resouce, other nodes dead at the same time,
the mle that is block type may be unlinked and freed repeatedly for dead nodes.
so it is a BUG about mle->mle_refs.refcount in __dlm_put_mle in dlm_get_lock_resouce.
Finally, any feedback about this process (positive or negative) would be greatly appreciated.
*** linux-4.1.35/fs/ocfs2/dlm/dlmmaster.c 2016-11-09 17:39:02.230163503 +0800
--- dlmmaster.c.update 2016-11-09 17:41:39.210166752 +0800
***************
*** 3229,3248 ****
--- 3229,3261 ----
struct dlm_master_list_entry *mle, u8 dead_node)
{
int bit;
+ int next_bit = O2NM_MAX_NODES;
BUG_ON(mle->type != DLM_MLE_BLOCK);
spin_lock(&mle->spinlock);
bit = find_next_bit(mle->maybe_map, O2NM_MAX_NODES, 0);
+ if (bit != O2NM_MAX_NODES)
+ next_bit = find_next_bit(mle->maybe_map, O2NM_MAX_NODES, bit+1);
+
if (bit != dead_node) {
mlog(0, "mle found, but dead node %u would not have been "
"master\n", dead_node);
spin_unlock(&mle->spinlock);
+ } else if (mle->inuse && next_bit != O2NM_MAX_NODES) {
+ /*Ignore it, the mle is used, other nodes dead now.
+ *as it is unlinked and freed for the dead node, it's a BUG*/
+ mlog(ML_ERROR, "the mle is used, but inuse %d, dead node %u, "
+ "master %u\n", mle->inuse, dead_node, mle->master);
+ clear_bit(bit, mle->maybe_map);
+ spin_unlock(&mle->spinlock);
+
} else {
/* Must drop the refcount by one since the assert_master will
* never arrive. This may result in the mle being unlinked and
* freed, but there may still be a process waiting in the
* dlmlock path which is fine. */
mlog(0, "node %u was expected master\n", dead_node);
+ clear_bit(bit, mle->maybe_map);
atomic_set(&mle->woken, 1);
spin_unlock(&mle->spinlock);
wake_up(&mle->wq);
________________________________
All the best wishes for you.
zhangguanghui
-------------------------------------------------------------------------------------------------------------------------------------
????????????????????????????????????????
????????????????????????????????????????
????????????????????????????????????????
???
This e-mail and its attachments contain confidential information from H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20161109/e75bd6a6/attachment-0001.html
^ permalink raw reply
* Re: [PATCH v7 00/21] Introduce SoC device/driver framework for EAL
From: Thomas Monjalon @ 2016-11-09 10:17 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: dev, viktorin, david.marchand
In-Reply-To: <1477657598-826-1-git-send-email-shreyansh.jain@nxp.com>
Hi Shreyansh,
I realize that we had a lot of off-list discussions on this topic
and there was no public explanation of the status of this series.
2016-10-28 17:56, Shreyansh Jain:
[...]
> As of now EAL is primarly focused on PCI initialization/probing.
Right. DPDK was PCI centric.
We must give PCI its right role: a bus as other ones.
A first step was done in 16.11 (thanks to you Shreyansh, Jan and David)
to have a better device model.
The next step is to rework the bus abstraction.
It seems a bus can be defined with the properties scan/match/notify,
leading to initialize the devices.
More comments below your technical presentation.
[...]
> This patchset introduces SoC framework which would enable SoC drivers and
> drivers to be plugged into EAL, very similar to how PCI drivers/devices are
> done today.
>
> This is a stripped down version of PCI framework which allows the SoC PMDs
> to implement their own routines for detecting devices and linking devices to
> drivers.
>
> 1) Changes to EAL
> rte_eal_init()
> |- rte_eal_pci_init(): Find PCI devices from sysfs
> |- rte_eal_soc_init(): Calls PMDs->scan_fn
> |- ...
> |- rte_eal_memzone_init()
> |- ...
> |- rte_eal_pci_probe(): Driver<=>Device initialization, PMD->devinit()
> `- rte_eal_soc_probe(): Calls PMDs->match_fn and PMDs->devinit();
>
> 2) New device/driver structures:
> - rte_soc_driver (inheriting rte_driver)
> - rte_soc_device (inheriting rte_device)
> - rte_eth_dev and eth_driver embedded rte_soc_device and rte_soc_driver,
> respectively.
>
> 3) The SoC PMDs need to:
> - define rte_soc_driver with necessary scan and match callbacks
> - Register themselves using DRIVER_REGISTER_SOC()
> - Implement respective bus scanning in the scan callbacks to add necessary
> devices to SoC device list
> - Implement necessary eth_dev_init/uninint for ethernet instances
These callbacks are not specific to a SoC.
By the way a SoC defines nothing specific. You are using the SoC word
as an equivalent of non-PCI.
We must have a bus abstraction like the one you are defining for the SoC
but it must be generic and defined on top of PCI, so we can plug any
bus in it: PCI, vdev (as a software bus), any other well-defined bus,
and some driver-specific bus which can be implemented directly in the
driver (the NXP case AFAIK).
> 4) Design considerations that are same as PCI:
> - SoC initialization is being done through rte_eal_init(), just after PCI
> initialization is done.
> - As in case of PCI, probe is done after rte_eal_pci_probe() to link the
> devices detected with the drivers registered.
> - Device attach/detach functions are available and have been designed on
> the lines of PCI framework.
> - PMDs register using DRIVER_REGISTER_SOC, very similar to
> DRIVER_REGISTER_PCI for PCI devices.
> - Linked list of SoC driver and devices exists independent of the other
> driver/device list, but inheriting rte_driver/rte_driver, these are
> also part of a global list.
>
> 5) Design considerations that are different from PCI:
> - Each driver implements its own scan and match function. PCI uses the BDF
> format to read the device from sysfs, but this _may_not_ be a case for a
> SoC ethernet device.
> = This is an important change from initial proposal by Jan in [2].
> Unlike his attempt to use /sys/bus/platform, this patch relies on the
> PMD to detect the devices. This is because SoC may require specific or
> additional info for device detection. Further, SoC may have embedded
> devices/MACs which require initialization which cannot be covered
> through sysfs parsing.
> `-> Point (6) below is a side note to above.
> = PCI based PMDs rely on EAL's capability to detect devices. This
> proposal puts the onus on PMD to detect devices, add to soc_device_list
> and wait for Probe. Matching, of device<=>driver is again PMD's
> callback.
These PCI considerations can be described as a PCI bus implementation in EAL.
> 6) Adding default scan and match helpers for PMDs
> - The design warrrants the PMDs implement their own scan of devices
> on bus, and match routines for probe implementation.
> This patch introduces helpers which can be used by PMDs for scan of
> the platform bus and matching devices against the compatible string
> extracted from the scan.
> - Intention is to make it easier to integrate known SoC which expose
> platform bus compliant information (compat, sys/bus/platform...).
> - PMDs which have deviations from this standard model can implement and
> hook their bus scanning and probe match callbacks while registering
> driver.
Yes we can have EAL helpers to scan sys/bus/platform or other common formats.
Then the PMD can use them to implement its specific bus.
I know that David, you and me are on the same page to agree on this generic
design. I hope you will be able to achieve this work soon.
The goal is to be able to plug a SoC driver in DPDK 17.02 with a clean design.
My advice to make reviews and contributions easier, is to split the work in
few steps:
- clean PCI code (generalize non-PCI stuff)
- add generic bus functions
- plug PCI in generic bus abstraction
- plug vdev in generic bus abstraction
- plug the new NXP driver
Thanks
^ permalink raw reply
* Re: [PATCH v4 0/4] MIPS: Remote processor driver
From: Thomas Gleixner @ 2016-11-09 10:15 UTC (permalink / raw)
To: Matt Redfearn
Cc: Ralf Baechle, Bjorn Andersson, Ohad Ben-Cohen, linux-mips,
linux-remoteproc, Lisa Parratt, LKML, Qais Yousef,
Masahiro Yamada, Lisa Parratt, Paul Gortmaker, Jason Cooper,
James Hogan, Marc Zyngier, Paul Burton, Peter Zijlstra
In-Reply-To: <1478103063-17653-1-git-send-email-matt.redfearn@imgtec.com>
On Wed, 2 Nov 2016, Matt Redfearn wrote:
> The MIPS remote processor driver allows non-Linux firmware to take
> control of and execute on one of the systems VPEs. The CPU must be
> offlined from Linux first. A sysfs interface is created which allows
> firmware to be loaded and changed at runtime. A full description is
> available at [1]. An example firmware that can be used with this driver
> is available at [2].
>
> This is useful to allow running bare metal code, or an RTOS, on one or
> more CPUs while allowing Linux to continue running on those remaining.
And how is actually guaranteed that these two things are properly seperated
(memory, devices, interrupts etc.) ?
We have rejected attempts to do exactly the same thing on x86 in the
past. There is virtualization and NOHZ_FULL to do it proper and not just
with a horrible hackery.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v7 3/3] drm/fence: add out-fences support
From: Daniel Vetter @ 2016-11-09 10:18 UTC (permalink / raw)
To: Gustavo Padovan, dri-devel, linux-kernel, Daniel Stone, Rob Clark,
Greg Hackmann, John Harrison, laurent.pinchart, seanpaul, marcheu,
m.chehab, Sumit Semwal, Maarten Lankhorst, Brian Starkey,
Gustavo Padovan
In-Reply-To: <20161109023911.GO3327@joana>
On Wed, Nov 09, 2016 at 11:39:11AM +0900, Gustavo Padovan wrote:
> > On Tue, Nov 08, 2016 at 03:54:50PM +0900, Gustavo Padovan wrote:
> > > + if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr)))
> > > + return -EFAULT;
> >
> > Same comment about igt coverage I made for patch 1, but with
> > s/in-fence/out-fence/, and s/~0ULL/8/. I picked 8 as an invalid address !=
> > NULL.
> >
> > And the testcase need to cover all possible combinations of output event
> > generation, i.e. out-fence, event and out-fence+event. So 3x3=9 testcases
> > for this I think.
>
> out-fence and event. so 2x2=4 ;)
3 different igt modes I've counted:
- wrong prop after correct fence prop (early failure)
- atomic_check fails (late failure)
- success
With 3 kinds of events:
- fence only
- event only
- both - which might show up some bug if you bail out after e.g. handling
fences, but before handling events and then leak.
Hence 3x3 ;-) But if some of these aren't reasonable I'm ok with leaving
them out, too.
> > > +static void unprepare_crtc_signaling(struct drm_device *dev,
> > > + struct drm_atomic_state *state,
> > > + struct drm_out_fence_state *fence_state)
> > > +{
> > > + struct drm_crtc *crtc;
> > > + struct drm_crtc_state *crtc_state;
> > > + int i;
> > > +
> > > + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > + /*
> > > + * TEST_ONLY and PAGE_FLIP_EVENT are mutually
> > > + * exclusive, if they weren't, this code should be
> > > + * called on success for TEST_ONLY too.
> > > + */
> > > + if (crtc_state->event)
> > > + drm_event_cancel_free(dev,
> > > + &crtc_state->event->base);
> > > + }
> > > +
> > > + for (i = 0; fence_state[i].out_fence_ptr; i++) {
> >
> > This goes boom if you have fences set for every crtc, because then this
> > check will walk past the end of the array and do something undefined. You
> > need to manually count how many of these slots are set (and might want to
> > switch to a krealloc pattern while at it). Sounds like it needs an igt.
>
> On the fd_install loop I was also checking for i <
> dev->mode_config.num_crtcs but forgot to add that here. However having a
> num_fences is a better solution, I'll add that.
And adding num_fence will be a good prep for writeback fences from Brian,
too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [Qemu-devel] [PATCH] cipher: fix leak on initialization error
From: Marc-André Lureau @ 2016-11-09 10:18 UTC (permalink / raw)
To: qemu-devel; +Cc: berrange, Marc-André Lureau
If ctx->blocksize != XTS_BLOCK_SIZE, ctx will be leaked.
Assign ctx earler, and call qcrypto_cipher_free() on error.
Spotted thanks to ASAN.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
crypto/cipher-nettle.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
index cd094cd..593962c 100644
--- a/crypto/cipher-nettle.c
+++ b/crypto/cipher-nettle.c
@@ -376,6 +376,7 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
goto error;
}
+ cipher->opaque = ctx;
if (mode == QCRYPTO_CIPHER_MODE_XTS &&
ctx->blocksize != XTS_BLOCK_SIZE) {
error_setg(errp, "Cipher block size %zu must equal XTS block size %d",
@@ -384,13 +385,11 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
}
ctx->iv = g_new0(uint8_t, ctx->blocksize);
- cipher->opaque = ctx;
return cipher;
error:
- g_free(cipher);
- g_free(ctx);
+ qcrypto_cipher_free(cipher);
return NULL;
}
@@ -404,10 +403,12 @@ void qcrypto_cipher_free(QCryptoCipher *cipher)
}
ctx = cipher->opaque;
- g_free(ctx->iv);
- g_free(ctx->ctx);
- g_free(ctx->ctx_tweak);
- g_free(ctx);
+ if (ctx) {
+ g_free(ctx->iv);
+ g_free(ctx->ctx);
+ g_free(ctx->ctx_tweak);
+ g_free(ctx);
+ }
g_free(cipher);
}
--
2.10.0
^ permalink raw reply related
* [PATCH v2] HID:i2c-hid: add a simple quirk to fix device defects
From: hn.chen @ 2016-11-09 10:20 UTC (permalink / raw)
To: jkosina; +Cc: benjamin.tissoires, dmitry.torokhov, linux-input, HungNien Chen
From: HungNien Chen <hn.chen@weidahitech.com>
Add a static quirk table and lookup for the quirks in i2c_hid_probe().
Also add comments and do return value check in i2c_hid_set_power().
Signed-off-by: HungNien Chen <hn.chen@weidahitech.com>
---
drivers/hid/hid-ids.h | 5 ++++
drivers/hid/i2c-hid/i2c-hid.c | 57 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 6cfb5ca..787afdf 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1033,6 +1033,11 @@
#define USB_DEVICE_ID_WALTOP_MEDIA_TABLET_14_1_INCH 0x0500
#define USB_DEVICE_ID_WALTOP_SIRIUS_BATTERY_FREE_TABLET 0x0502
+#define USB_VENDOR_ID_WEIDA 0x2575
+#define USB_DEVICE_ID_WEIDA_8756 0x8756
+#define USB_DEVICE_ID_WEIDA_8752 0xC300
+#define USB_DEVICE_ID_WEIDA_8755 0xC301
+
#define USB_VENDOR_ID_WISEGROUP 0x0925
#define USB_DEVICE_ID_SMARTJOY_PLUS 0x0005
#define USB_DEVICE_ID_SUPER_JOY_BOX_3 0x8888
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index b3ec4f2..b32a063 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -41,6 +41,11 @@
#include <linux/i2c/i2c-hid.h>
+#include "../hid-ids.h"
+
+/* quirks to control the device */
+#define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV (1 << 0)
+
/* flags */
#define I2C_HID_STARTED 0
#define I2C_HID_RESET_PENDING 1
@@ -143,6 +148,7 @@ struct i2c_hid {
char *argsbuf; /* Command arguments buffer */
unsigned long flags; /* device flags */
+ unsigned long quirks; /* Various quirks */
wait_queue_head_t wait; /* For waiting the interrupt */
struct gpio_desc *desc;
@@ -154,6 +160,39 @@ struct i2c_hid {
struct mutex reset_lock;
};
+static const struct i2c_hid_blacklist {
+ __u16 idVendor;
+ __u16 idProduct;
+ __u32 quirks;
+} i2c_hid_blacklist[] = {
+ { USB_VENDOR_ID_WEIDA, USB_DEVICE_ID_WEIDA_8752,
+ I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
+ { USB_VENDOR_ID_WEIDA, USB_DEVICE_ID_WEIDA_8755,
+ I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
+ { 0, 0 }
+};
+
+/*
+ * i2c_hid_lookup_quirk: return any quirks associated with a I2C HID device
+ * @idVendor: the 16-bit vendor ID
+ * @idProduct: the 16-bit product ID
+ *
+ * Returns: a u32 quirks value.
+ */
+static u32 i2c_hid_lookup_quirk(const u16 idVendor, const u16 idProduct)
+{
+ u32 quirks = 0;
+ int n = 0;
+
+ for (; i2c_hid_blacklist[n].idVendor; n++)
+ if (i2c_hid_blacklist[n].idVendor == idVendor &&
+ (i2c_hid_blacklist[n].idProduct == (__u16)HID_ANY_ID ||
+ i2c_hid_blacklist[n].idProduct == idProduct))
+ quirks = i2c_hid_blacklist[n].quirks;
+
+ return quirks;
+}
+
static int __i2c_hid_command(struct i2c_client *client,
const struct i2c_hid_cmd *command, u8 reportID,
u8 reportType, u8 *args, int args_len,
@@ -346,11 +385,27 @@ static int i2c_hid_set_power(struct i2c_client *client, int power_state)
i2c_hid_dbg(ihid, "%s\n", __func__);
+ /*
+ * Some devices require to send a command to wakeup before power on.
+ * The call will get a return value (EREMOTEIO) but device will be
+ * triggered and activated. After that, it goes like a normal device.
+ */
+ if (power_state == I2C_HID_PWR_ON &&
+ ihid->quirks & I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV) {
+ ret = i2c_hid_command(client, &hid_set_power_cmd, NULL, 0);
+
+ /* Device was already activated */
+ if (!ret)
+ goto set_pwr_exit;
+ }
+
ret = __i2c_hid_command(client, &hid_set_power_cmd, power_state,
0, NULL, 0, NULL, 0);
+
if (ret)
dev_err(&client->dev, "failed to change power setting.\n");
+set_pwr_exit:
return ret;
}
@@ -1050,6 +1105,8 @@ static int i2c_hid_probe(struct i2c_client *client,
client->name, hid->vendor, hid->product);
strlcpy(hid->phys, dev_name(&client->dev), sizeof(hid->phys));
+ ihid->quirks = i2c_hid_lookup_quirk(hid->vendor, hid->product);
+
ret = hid_add_device(hid);
if (ret) {
if (ret != -ENODEV)
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.