Re: [ 35/54] ARM: SAMSUNG: Add naming of s3c64xx-spi devices
On Sun, Nov 4, 2012 at 11:51 PM, Greg Kroah-Hartman
wrote:
> On Sat, Nov 03, 2012 at 11:17:57PM -0700, Colin Cross wrote:
>> On Mon, Oct 29, 2012 at 2:40 PM, Greg Kroah-Hartman
>> wrote:
>> > 3.4-stable review patch. If anyone has any objections, please let me know.
>> >
>> > --
>> >
>> > From: Heiko Stuebner
>> >
>> > commit 308b3afb97dc342e9c4f958d8b4c459ae0e22bd7 upstream.
>> >
>> > Commit a5238e360b71 (spi: s3c64xx: move controller information into driver
>> > data) introduced separate device names for the different subtypes of the
>> > spi controller but forgot to set these in the relevant machines.
>> >
>> > To fix this introduce a s3c64xx_spi_setname function and populate all
>> > Samsung arches with the correct names. The function resides in a new
>> > header, as the s3c64xx-spi.h contains driver platform data and should
>> > therefore at some later point move out of the Samsung include dir.
>> >
>> > Tested on a s3c2416-based machine.
>> >
>> > Signed-off-by: Heiko Stuebner
>> > Reviewed-by: Sylwester Nawrocki
>> > [s.nawro...@samsung.com: tested on mach-exynos]
>> > Tested-by: Sylwester Nawrocki
>> > Signed-off-by: Kukjin Kim
>> > Signed-off-by: Greg Kroah-Hartman
>> >
>> > ---
>> > arch/arm/mach-exynos/common.c |5
>> > arch/arm/mach-s3c24xx/s3c2416.c |2 +
>> > arch/arm/mach-s3c24xx/s3c2443.c |4 +++
>> > arch/arm/mach-s5p64x0/common.c|3 ++
>> > arch/arm/mach-s5pc100/common.c|3 ++
>> > arch/arm/mach-s5pv210/common.c|3 ++
>> > arch/arm/plat-samsung/include/plat/spi-core.h | 30
>> > ++
>> > 7 files changed, 50 insertions(+)
>> >
>> > --- a/arch/arm/mach-exynos/common.c
>> > +++ b/arch/arm/mach-exynos/common.c
>> > @@ -44,6 +44,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> > #include
>> >
>> > #include "common.h"
>> > @@ -338,6 +339,8 @@ static void __init exynos4_map_io(void)
>> >
>> > s5p_fb_setname(0, "exynos4-fb");
>> > s5p_hdmi_setname("exynos4-hdmi");
>> > +
>> > + s3c64xx_spi_setname("exynos4210-spi");
>> > }
>> >
>> > static void __init exynos5_map_io(void)
>> > @@ -358,6 +361,8 @@ static void __init exynos5_map_io(void)
>> > s3c_i2c0_setname("s3c2440-i2c");
>> > s3c_i2c1_setname("s3c2440-i2c");
>> > s3c_i2c2_setname("s3c2440-i2c");
>> > +
>> > + s3c64xx_spi_setname("exynos4210-spi");
>> > }
>> >
>> > static void __init exynos4_init_clocks(int xtal)
>> > --- a/arch/arm/mach-s3c24xx/s3c2416.c
>> > +++ b/arch/arm/mach-s3c24xx/s3c2416.c
>> > @@ -61,6 +61,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
>> > static struct map_desc s3c2416_iodesc[] __initdata = {
>> > IODESC_ENT(WATCHDOG),
>> > @@ -131,6 +132,7 @@ void __init s3c2416_map_io(void)
>> > /* initialize device information early */
>> > s3c2416_default_sdhci0();
>> > s3c2416_default_sdhci1();
>> > + s3c64xx_spi_setname("s3c2443-spi");
>> >
>> > iotable_init(s3c2416_iodesc, ARRAY_SIZE(s3c2416_iodesc));
>> > }
>> > --- a/arch/arm/mach-s3c24xx/s3c2443.c
>> > +++ b/arch/arm/mach-s3c24xx/s3c2443.c
>> > @@ -43,6 +43,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
>> > static struct map_desc s3c2443_iodesc[] __initdata = {
>> > IODESC_ENT(WATCHDOG),
>> > @@ -100,6 +101,9 @@ void __init s3c2443_map_io(void)
>> > s3c24xx_gpiocfg_default.set_pull = s3c2443_gpio_setpull;
>> > s3c24xx_gpiocfg_default.get_pull = s3c2443_gpio_getpull;
>> >
>> > + /* initialize device information early */
>> > + s3c64xx_spi_setname("s3c2443-spi");
>> > +
>> > iotable_init(s3c2443_iodesc, ARRAY_SIZE(s3c2443_iodesc));
>> > }
>> >
>> > --- a/arch/arm/mach-s5p64x0/common.c
>> > +++ b/arch/arm/mach-s5p64x0/common.c
>> > @@ -44,6 +44,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> > #include
>> > #include
>> > #include
>> > @@ -179,6 +180,7 @@ void __init s5p6440_map_io(void)
>> > /* initialize any device information early */
>> > s3c_adc_setname("s3c64xx-adc");
>> > s3c_fb_setname("s5p64x0-fb");
>> > + s3c64xx_spi_setname("s5p64x0-spi");
>> >
>> > s5p64x0_default_sdhci0();
>> > s5p64x0_default_sdhci1();
>> > @@ -193,6 +195,7 @@ void __init s5p6450_map_io(void)
>> > /* initialize any device information early */
>> > s3c_adc_setname("s3c64xx-adc");
>> > s3c_fb_setname("s5p64x0-fb");
>> > + s3c64xx_spi_setname("s5p64x0-spi");
>> >
>> > s5p64x0_default_sdhci0();
>> > s5p64x0_default_sdhci1();
>> > --- a/arch/arm/mach-s5pc100/common.c
>> > +++ b/arch/arm/mach-s5pc100/common.c
>> > @@ -45,6 +45,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> > #include
>> > #include
>> >
>> > @@ -165,6 +166,8 @@ void __init s5pc100_map_io(void)
Re: [ 35/54] ARM: SAMSUNG: Add naming of s3c64xx-spi devices
On Sat, Nov 03, 2012 at 11:17:57PM -0700, Colin Cross wrote:
> On Mon, Oct 29, 2012 at 2:40 PM, Greg Kroah-Hartman
> wrote:
> > 3.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Heiko Stuebner
> >
> > commit 308b3afb97dc342e9c4f958d8b4c459ae0e22bd7 upstream.
> >
> > Commit a5238e360b71 (spi: s3c64xx: move controller information into driver
> > data) introduced separate device names for the different subtypes of the
> > spi controller but forgot to set these in the relevant machines.
> >
> > To fix this introduce a s3c64xx_spi_setname function and populate all
> > Samsung arches with the correct names. The function resides in a new
> > header, as the s3c64xx-spi.h contains driver platform data and should
> > therefore at some later point move out of the Samsung include dir.
> >
> > Tested on a s3c2416-based machine.
> >
> > Signed-off-by: Heiko Stuebner
> > Reviewed-by: Sylwester Nawrocki
> > [s.nawro...@samsung.com: tested on mach-exynos]
> > Tested-by: Sylwester Nawrocki
> > Signed-off-by: Kukjin Kim
> > Signed-off-by: Greg Kroah-Hartman
> >
> > ---
> > arch/arm/mach-exynos/common.c |5
> > arch/arm/mach-s3c24xx/s3c2416.c |2 +
> > arch/arm/mach-s3c24xx/s3c2443.c |4 +++
> > arch/arm/mach-s5p64x0/common.c|3 ++
> > arch/arm/mach-s5pc100/common.c|3 ++
> > arch/arm/mach-s5pv210/common.c|3 ++
> > arch/arm/plat-samsung/include/plat/spi-core.h | 30
> > ++
> > 7 files changed, 50 insertions(+)
> >
> > --- a/arch/arm/mach-exynos/common.c
> > +++ b/arch/arm/mach-exynos/common.c
> > @@ -44,6 +44,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "common.h"
> > @@ -338,6 +339,8 @@ static void __init exynos4_map_io(void)
> >
> > s5p_fb_setname(0, "exynos4-fb");
> > s5p_hdmi_setname("exynos4-hdmi");
> > +
> > + s3c64xx_spi_setname("exynos4210-spi");
> > }
> >
> > static void __init exynos5_map_io(void)
> > @@ -358,6 +361,8 @@ static void __init exynos5_map_io(void)
> > s3c_i2c0_setname("s3c2440-i2c");
> > s3c_i2c1_setname("s3c2440-i2c");
> > s3c_i2c2_setname("s3c2440-i2c");
> > +
> > + s3c64xx_spi_setname("exynos4210-spi");
> > }
> >
> > static void __init exynos4_init_clocks(int xtal)
> > --- a/arch/arm/mach-s3c24xx/s3c2416.c
> > +++ b/arch/arm/mach-s3c24xx/s3c2416.c
> > @@ -61,6 +61,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > static struct map_desc s3c2416_iodesc[] __initdata = {
> > IODESC_ENT(WATCHDOG),
> > @@ -131,6 +132,7 @@ void __init s3c2416_map_io(void)
> > /* initialize device information early */
> > s3c2416_default_sdhci0();
> > s3c2416_default_sdhci1();
> > + s3c64xx_spi_setname("s3c2443-spi");
> >
> > iotable_init(s3c2416_iodesc, ARRAY_SIZE(s3c2416_iodesc));
> > }
> > --- a/arch/arm/mach-s3c24xx/s3c2443.c
> > +++ b/arch/arm/mach-s3c24xx/s3c2443.c
> > @@ -43,6 +43,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > static struct map_desc s3c2443_iodesc[] __initdata = {
> > IODESC_ENT(WATCHDOG),
> > @@ -100,6 +101,9 @@ void __init s3c2443_map_io(void)
> > s3c24xx_gpiocfg_default.set_pull = s3c2443_gpio_setpull;
> > s3c24xx_gpiocfg_default.get_pull = s3c2443_gpio_getpull;
> >
> > + /* initialize device information early */
> > + s3c64xx_spi_setname("s3c2443-spi");
> > +
> > iotable_init(s3c2443_iodesc, ARRAY_SIZE(s3c2443_iodesc));
> > }
> >
> > --- a/arch/arm/mach-s5p64x0/common.c
> > +++ b/arch/arm/mach-s5p64x0/common.c
> > @@ -44,6 +44,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -179,6 +180,7 @@ void __init s5p6440_map_io(void)
> > /* initialize any device information early */
> > s3c_adc_setname("s3c64xx-adc");
> > s3c_fb_setname("s5p64x0-fb");
> > + s3c64xx_spi_setname("s5p64x0-spi");
> >
> > s5p64x0_default_sdhci0();
> > s5p64x0_default_sdhci1();
> > @@ -193,6 +195,7 @@ void __init s5p6450_map_io(void)
> > /* initialize any device information early */
> > s3c_adc_setname("s3c64xx-adc");
> > s3c_fb_setname("s5p64x0-fb");
> > + s3c64xx_spi_setname("s5p64x0-spi");
> >
> > s5p64x0_default_sdhci0();
> > s5p64x0_default_sdhci1();
> > --- a/arch/arm/mach-s5pc100/common.c
> > +++ b/arch/arm/mach-s5pc100/common.c
> > @@ -45,6 +45,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -165,6 +166,8 @@ void __init s5pc100_map_io(void)
> > s3c_onenand_setname("s5pc100-onenand");
> > s3c_fb_setname("s5pc100-fb");
> > s3c_cfcon_setname("s5pc100-pata");
> > +
> > + s3c64xx_spi_setname("s5pc100-spi");
> > }
>
Re: [ 00/24] 3.6.6-stable review
On Mon, Nov 5, 2012 at 3:41 PM, Greg Kroah-Hartman wrote: > On Mon, Nov 05, 2012 at 03:37:31PM +0800, Zhi Yong Wu wrote: >> HI, greg >> >> Some of the patchset haven't passed the check of checkpatch.pl as below: >> >> WARNING: line over 80 characters >> #85: FILE: drivers/block/floppy.c:4319: >> + device_remove_file(_device[drive].dev, >> _attr_cmos); >> >> WARNING: line over 80 characters >> #419: FILE: drivers/scsi/qla2xxx/qla_target.c:744: >> + ha->tgt.tgt_ops->update_sess(sess, fcport->d_id, >> fcport->loop_id, >> >> WARNING: line over 80 characters >> #420: FILE: drivers/scsi/qla2xxx/qla_target.c:745: >> + (fcport->flags & >> FCF_CONF_COMP_SUPPORTED)); >> >> WARNING: line over 80 characters >> #443: FILE: drivers/scsi/qla2xxx/qla_target.c:871: >> + ha->tgt.tgt_ops->update_sess(sess, fcport->d_id, >> fcport->loop_id, >> >> WARNING: line over 80 characters >> #444: FILE: drivers/scsi/qla2xxx/qla_target.c:872: >> + (fcport->flags & >> FCF_CONF_COMP_SUPPORTED)); >> >> WARNING: line over 80 characters >> #488: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1491: >> + sess->s_id.b.domain, sess->s_id.b.area, >> sess->s_id.b.al_pa, >> >> WARNING: line over 80 characters >> #514: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1517: >> + WARN(btree_remove32(>lport_fcport_map, key) != >> se_nacl, >> >> WARNING: line over 80 characters >> #516: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1519: >> + sess->s_id.b.domain, sess->s_id.b.area, >> sess->s_id.b.al_pa); >> >> WARNING: line over 80 characters >> #519: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1522: >> + sess->s_id.b.domain, sess->s_id.b.area, >> sess->s_id.b.al_pa); >> >> WARNING: line over 80 characters >> #530: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1533: >> + btree_insert32(>lport_fcport_map, key, se_nacl, >> GFP_ATOMIC); >> >> total: 0 errors, 10 warnings, 1094 lines checked > > That's fine, take those up with the people who send them in for the > upstream kernel, I take them no-changes for the stable releases. I will do after all three stable -rc kernels test are completed. > > And really, the 80 characters is just a "hint", it's not a hard and fast > rule for anything here. Especially for the old, and horrible, floppy > and scsi drivers :) ok, thanks. > > thanks, > > greg k-h -- Regards, Zhi Yong Wu -- 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: [ 00/24] 3.6.6-stable review
On Mon, Nov 05, 2012 at 03:37:31PM +0800, Zhi Yong Wu wrote: > HI, greg > > Some of the patchset haven't passed the check of checkpatch.pl as below: > > WARNING: line over 80 characters > #85: FILE: drivers/block/floppy.c:4319: > + device_remove_file(_device[drive].dev, > _attr_cmos); > > WARNING: line over 80 characters > #419: FILE: drivers/scsi/qla2xxx/qla_target.c:744: > + ha->tgt.tgt_ops->update_sess(sess, fcport->d_id, > fcport->loop_id, > > WARNING: line over 80 characters > #420: FILE: drivers/scsi/qla2xxx/qla_target.c:745: > + (fcport->flags & > FCF_CONF_COMP_SUPPORTED)); > > WARNING: line over 80 characters > #443: FILE: drivers/scsi/qla2xxx/qla_target.c:871: > + ha->tgt.tgt_ops->update_sess(sess, fcport->d_id, > fcport->loop_id, > > WARNING: line over 80 characters > #444: FILE: drivers/scsi/qla2xxx/qla_target.c:872: > + (fcport->flags & > FCF_CONF_COMP_SUPPORTED)); > > WARNING: line over 80 characters > #488: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1491: > + sess->s_id.b.domain, sess->s_id.b.area, > sess->s_id.b.al_pa, > > WARNING: line over 80 characters > #514: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1517: > + WARN(btree_remove32(>lport_fcport_map, key) != > se_nacl, > > WARNING: line over 80 characters > #516: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1519: > + sess->s_id.b.domain, sess->s_id.b.area, > sess->s_id.b.al_pa); > > WARNING: line over 80 characters > #519: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1522: > + sess->s_id.b.domain, sess->s_id.b.area, > sess->s_id.b.al_pa); > > WARNING: line over 80 characters > #530: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1533: > + btree_insert32(>lport_fcport_map, key, se_nacl, > GFP_ATOMIC); > > total: 0 errors, 10 warnings, 1094 lines checked That's fine, take those up with the people who send them in for the upstream kernel, I take them no-changes for the stable releases. And really, the 80 characters is just a "hint", it's not a hard and fast rule for anything here. Especially for the old, and horrible, floppy and scsi drivers :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
This is not a good thing to assume. A vendor could have an external button, gor example. ebied...@xmission.com wrote: >"H. Peter Anvin" writes: > >> On 11/05/2012 07:14 AM, Eric W. Biederman wrote: >>> >>> In any case the notion that unattended install with no user >interaction >>> on any uefi machine in any state is complete and total rubbish. It >>> can't be done. You need power and you need boot media. >>> >> >> That is a hugely different thing from needing a console. > >Not at all. > >In the general case user intereaction is required to tell the system to >boot off of your choosen boot media instead of the local hard drive. > >Eric -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- 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: [ 00/24] 3.6.6-stable review
HI, greg Some of the patchset haven't passed the check of checkpatch.pl as below: WARNING: line over 80 characters #85: FILE: drivers/block/floppy.c:4319: + device_remove_file(_device[drive].dev, _attr_cmos); WARNING: line over 80 characters #419: FILE: drivers/scsi/qla2xxx/qla_target.c:744: + ha->tgt.tgt_ops->update_sess(sess, fcport->d_id, fcport->loop_id, WARNING: line over 80 characters #420: FILE: drivers/scsi/qla2xxx/qla_target.c:745: + (fcport->flags & FCF_CONF_COMP_SUPPORTED)); WARNING: line over 80 characters #443: FILE: drivers/scsi/qla2xxx/qla_target.c:871: + ha->tgt.tgt_ops->update_sess(sess, fcport->d_id, fcport->loop_id, WARNING: line over 80 characters #444: FILE: drivers/scsi/qla2xxx/qla_target.c:872: + (fcport->flags & FCF_CONF_COMP_SUPPORTED)); WARNING: line over 80 characters #488: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1491: + sess->s_id.b.domain, sess->s_id.b.area, sess->s_id.b.al_pa, WARNING: line over 80 characters #514: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1517: + WARN(btree_remove32(>lport_fcport_map, key) != se_nacl, WARNING: line over 80 characters #516: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1519: +sess->s_id.b.domain, sess->s_id.b.area, sess->s_id.b.al_pa); WARNING: line over 80 characters #519: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1522: +sess->s_id.b.domain, sess->s_id.b.area, sess->s_id.b.al_pa); WARNING: line over 80 characters #530: FILE: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1533: + btree_insert32(>lport_fcport_map, key, se_nacl, GFP_ATOMIC); total: 0 errors, 10 warnings, 1094 lines checked On Sat, Nov 3, 2012 at 1:06 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.6.6 release. > There are 24 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Nov 4 17:02:39 UTC 2012. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.6.6-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.6.6-rc1 > > Ben Skeggs > drm/nouveau: headless mode by default if pci class != vga display > > Ben Skeggs > drm/nouveau: fix suspend/resume when in headless mode > > Ben Skeggs > drm/nouveau: silence modesetting spam on pre-gf8 chipsets > > Jiri Slaby > HID: microsoft: fix invalid rdesc for 3k kbd > > Nicholas Bellinger > target: Fix double-free of se_cmd in target_complete_tmr_failure > > Bernhard Kohl > target: reintroduce some obsolete SCSI-2 commands > > Roland Dreier > qla2xxx: Update target lookup session tables when a target session changes > > Paul Bolle > USB: io_edgeport: remove unused variable > > Johan Hovold > USB: iuu_phoenix: fix backported patches > > Johan Hovold > USB: mos7840: fix port-data memory leak > > Alex Elder > ceph: avoid 32-bit page index overflow > > Sage Weil > libceph: check for invalid mapping > > Yan, Zheng > ceph: Fix oops when handling mdsmap that decreases max_mds > > David Zafman > ceph: fix dentry reference leak in encode_fh() > > Sage Weil > libceph: avoid NULL kref_put when osd reset races with alloc_msg > > Alex Elder > rbd: reset BACKOFF if unable to re-queue > > Herton Ronaldo Krzesinski > floppy: properly handle failure on add_disk loop > > Herton Ronaldo Krzesinski > floppy: do put_disk on current dr if blk_init_queue fails > > Herton Ronaldo Krzesinski > floppy: don't call alloc_ordered_workqueue inside the alloc_disk loop > > NeilBrown > md/raid1: Fix assembling of arrays containing Replacements. > > Mathias Nyman > gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios > > Dan Carpenter > gpio-timberdale: fix a potential wrapping issue > > Jun'ichi Nomura > blkcg: Fix use-after-free of q->root_blkg and q->root_rl.blkg > > Eric Sandeen > ext4: fix unjournaled inode bitmap modification > > > - > > Diffstat: > > Makefile| 4 +- > block/blk-cgroup.c | 7 ++ > drivers/block/floppy.c | 27 +++-- > drivers/gpio/gpio-timberdale.c | 4 +- > drivers/gpio/gpiolib.c | 10 +- > drivers/gpu/drm/nouveau/nouveau_drv.c | 20 ++-- > drivers/gpu/drm/nouveau/nouveau_state.c | 4 +- > drivers/gpu/drm/nouveau/nv04_dac.c | 8 +- > drivers/gpu/drm/nouveau/nv04_dfp.c | 6 +- > drivers/gpu/drm/nouveau/nv04_tv.c | 4 +- >
Re: [PATCH] pwm-backlight: Pinctrl-fy
On Wed, Oct 31, 2012 at 05:57:27PM +0200, Pantelis Antoniou wrote: [...] > diff --git a/drivers/video/backlight/pwm_bl.c > b/drivers/video/backlight/pwm_bl.c [...] > @@ -20,6 +20,8 @@ > #include > #include > #include > +#include > +#include linux/err.h is already included earlier. Thierry pgpHJDOsqkP7H.pgp Description: PGP signature
Re: How about a gpio_get(device *, char *) function?
Hi Linus, thanks for the reply! On Monday 05 November 2012 02:04:33 Linus Walleij wrote: > On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot wrote: > > Would anyone be opposed to having a gpio_get() function that works > > similarly to e.g. regulator_get() and clk_get()? > > I understand the concept and why you want to do this. > > However I think the global GPIO numberspace defeats the > purpose. > > gpio_get() should get an abstract handle just like clk_get() or > regulator_get(), not a fixed numeral. > > That is the only way to really transit away from the global GPIO > numberspace. Interesting. I see you already gave the whole thing a thought. What I don't understand however is what is so wrong with the current GPIO numberspace that you want to replace it? Whether we use simple integers or blind pointers, the adressable space will basically remain the same. GPIO numbers can actually be considered as handles, and actually I would not mind typedef'ing "int" to a GPIO handle type in order to add more opacity to the framework. Also the current DT bindings will likely continue to require the legacy API anyway, so I am not sure we can make it go away. My initial thought was to build something on top of the existing scheme to address my immediate needs - what you are talking about is much more scary. :) Could you elaborate on your motivations for such a radical direction? 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/
Re: [RFC] Second attempt at kernel secure boot support
"H. Peter Anvin" writes: > On 11/05/2012 07:14 AM, Eric W. Biederman wrote: >> >> In any case the notion that unattended install with no user interaction >> on any uefi machine in any state is complete and total rubbish. It >> can't be done. You need power and you need boot media. >> > > That is a hugely different thing from needing a console. Not at all. In the general case user intereaction is required to tell the system to boot off of your choosen boot media instead of the local hard drive. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH v3 00/16] DMA Engine support for AM33XX
On Thu, Oct 18, 2012 at 18:56:39, Porter, Matt wrote: ...snip... ...snip... ...snip... > > This series adds DMA Engine support for AM33xx, which uses > an EDMA DMAC. The EDMA DMAC has been previously supported by only > a private API implementation (much like the situation with OMAP > DMA) found on the DaVinci family of SoCs. > > The series applies on top of 3.7-rc1 and the following patches: > > - GPMC fails to reserve memory fix: > http://www.spinics.net/lists/linux-omap/msg79675.html > - TPS65910 regulator fix: > https://patchwork.kernel.org/patch/1593651/ > - dmaengine DT support from Vinod's dmaengine_dt branch in > git://git.infradead.org/users/vkoul/slave-dma.git since > 027478851791df751176398be02a3b1c5f6aa824 > > The approach taken is similar to how OMAP DMA is being converted to > DMA Engine support. With the functional EDMA private API already > existing in mach-davinci/dma.c, we first move that to an ARM common > area so it can be shared. Adding DT and runtime PM support to the > private EDMA API implementation allows it to run on AM33xx. AM33xx > *only* boots using DT so we leverage Jon's generic DT DMA helpers to > register EDMA DMAC with the of_dma framework and then add support > for calling the dma_request_slave_channel() API to both the mmc > and spi drivers. > > With this series both BeagleBone and the AM335x EVM have working > MMC and SPI support. > > This is tested on BeagleBone with a SPI framebuffer driver and MMC > rootfs. A trivial gpio DMA event misc driver was used to test the > crossbar DMA event support. It is also tested on the AM335x EVM > with the onboard SPI flash and MMC rootfs. The branch at > https://github.com/ohporter/linux/tree/edma-dmaengine-v3 has the > complete series, dependencies, and some test drivers/defconfigs. > > Regression testing was done on AM180x-EVM (which also makes use > of the EDMA dmaengine driver and the EDMA private API) using SD, > SPI flash, and the onboard audio supported by the ASoC Davinci > driver. Since you have tested MMC, and probably will be adding Audio support for AM335x as well, I believe you will also be adding Pin-mux support for both the modules. Can you share your plan to release the next version? I have few patches pending for AM335x Audio (DT related). Thanks in advance Regards Gururaja > > After this series, the plan is to convert the last in-tree user > of the private EDMA API (davinci-pcm/mcasp) and then eliminate > the private EDMA API by folding its functionality into > drivers/dma/edma.c. > > Matt Porter (16): > dmaengine: edma: fix slave config dependency on direction > ARM: davinci: move private EDMA API to arm/common > ARM: edma: remove unused transfer controller handlers > ARM: edma: add DT and runtime PM support for AM33XX > ARM: edma: add AM33XX crossbar event support > dmaengine: edma: enable build for AM33XX > dmaengine: edma: Add TI EDMA device tree binding > ARM: dts: add AM33XX EDMA support > dmaengine: add dma_request_slave_channel_compat() > mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() > mmc: omap_hsmmc: limit max_segs with the EDMA DMAC > mmc: omap_hsmmc: add generic DMA request support to the DT binding > ARM: dts: add AM33XX MMC support > spi: omap2-mcspi: convert to dma_request_slave_channel_compat() > spi: omap2-mcspi: add generic DMA request support to the DT binding > ARM: dts: add AM33XX SPI support > -- 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] Second attempt at kernel secure boot support
On 11/05/2012 07:14 AM, Eric W. Biederman wrote: > > In any case the notion that unattended install with no user interaction > on any uefi machine in any state is complete and total rubbish. It > can't be done. You need power and you need boot media. > That is a hugely different thing from needing a console. -hpa -- 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] pwm: export of_pwm_request
On Wed, Oct 31, 2012 at 05:57:10PM +0200, Pantelis Antoniou wrote: > No need to hide of_pwm_request, it's useful to other in-kernel users. Can you specify which users that might be? I'm reluctant to export symbols which aren't used by any drivers. > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c [...] > @@ -457,7 +457,7 @@ static struct pwm_chip *of_node_to_pwmchip(struct > device_node *np) > * becomes mandatory for devices that look up the PWM device via the con_id > * parameter. > */ > -static struct pwm_device *of_pwm_request(struct device_node *np, > +struct pwm_device *of_pwm_request(struct device_node *np, >const char *con_id) Can you please make sure that this remains properly aligned? > diff --git a/include/linux/pwm.h b/include/linux/pwm.h [...] > @@ -171,6 +171,7 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip > *chip, >unsigned int index, >const char *label); > > +struct pwm_device *of_pwm_request(struct device_node *np, const char > *consumer); The second argument is called con_id, so please fix this up to keep it consistent. > struct pwm_device *pwm_get(struct device *dev, const char *consumer); > void pwm_put(struct pwm_device *pwm); > > @@ -204,6 +205,12 @@ static inline struct pwm_device > *pwm_request_from_chip(struct pwm_chip *chip, > return ERR_PTR(-ENODEV); > } > > +static inline struct pwm_device *of_pwm_request(struct device_node *np, > + const char *consumer) Here as well. Also make sure the arguments are properly aligned. Thierry pgpkwGTzfKMEM.pgp Description: PGP signature
Re: linux-next: manual merge of the thermal tree with Linus' tree
Hi, Stephen,
On Mon, 2012-11-05 at 11:46 +1100, Stephen Rothwell wrote:
> Hi Zhang,
>
> Today's linux-next merge of the thermal tree got a conflict in
> drivers/thermal/rcar_thermal.c between commit 608f62b996c6 ("thermal:
> solve compilation errors in rcar_thermal") from Linus' tree and commit
> ebbf0f11e7b4 ("Thermal: Pass zone parameters as argument to
> tzd_register") from the thermal tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
I've rebased my -next branch on top of 3.7-rc4.
so please drop this fix.
thanks,
rui
--
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] mm: fix NULL checking in dma_pool_create()
First, `dev' is dereferenced in dev_to_node(dev), suggesting that it
must be non-null. Later `dev' is checked against NULL, suggesting
the opposite. This patch adds a NULL check before its use.
Signed-off-by: Xi Wang
---
mm/dmapool.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index c5ab33b..afbf88e 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -135,6 +135,7 @@ struct dma_pool *dma_pool_create(const char *name, struct
device *dev,
{
struct dma_pool *retval;
size_t allocation;
+ int node;
if (align == 0) {
align = 1;
@@ -159,7 +160,9 @@ struct dma_pool *dma_pool_create(const char *name, struct
device *dev,
return NULL;
}
- retval = kmalloc_node(sizeof(*retval), GFP_KERNEL, dev_to_node(dev));
+ node = dev ? dev_to_node(dev) : -1;
+
+ retval = kmalloc_node(sizeof(*retval), GFP_KERNEL, node);
if (!retval)
return retval;
--
1.7.10.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] vlan: set sysfs device_type to 'vlan'
From: Doug Goldstein Date: Mon, 5 Nov 2012 00:19:19 -0600 > By this argument we shouldn't ever improve any API or add new syscalls > since we'll have to have fallback code to handle the old interfaces > when the new ones aren't available. It makes sense to add new APIs when existing mechanisms are too difficult _AND_ code doesn't already exist that works reasonable well with existing facilities. -- 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] Second attempt at kernel secure boot support
Jiri Kosina writes: > On Fri, 2 Nov 2012, Vivek Goyal wrote: > >> > With secure boot enabled, then the kernel should refuse to let an >> > unsigned kexec load new images, and kexec itself should refuse to >> > load unsigned images. >> >> Yep, good in theory. Now that basically means reimplementing kexec-tools >> in kernel. > > Why is "when kernel has been securely booted, the in-kernel kexec > mechanism has to verify the signature of the supplied image before > kexecing it" not enough? (basically the same thing we are doing for signed > modules already). For modules the only untrusted part of their environment are the command line parameters, and several of those have already been noted for needing to be ignored in a non-trusted root scenario. For kexec there is a bunch of glue code and data that takes care of transitioning from the environment provided by kexec and the environment that the linux kernel or memtest86 or whatever we are booting is expecting. Figuring out what glue code and data we need and supplying that glue code and data is what kexec-tools does. The situation is a bit like dealing with the modules before most of the work of insmod was moved into the kernel. For kexec-tools it is desirable to have glue layers outside of the kernel because every boot system in existence has a different set of parameter passing rules. So signing in the kernel gets us into how do we sign the glue code and how dow we verify the glue code will jump to our signed and verified kernel image. I will be happy to review patches for that don't through the baby out with the bath water. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] staging: usbip: remove an unnecessary lock in usbip_event_happened. The variable "happened" is local. So I think there is no need to lock here.
I think no need to make 'happened' static as we just check 'ud->event'
feild. Maybe making this function inline would make more sense.
inline int usbip_event_happened(struct usbip_device *ud)
{
return ud->event ? 1 : 0;
}
Thanks
Harvey
On Mon, Nov 5, 2012 at 1:34 PM, Prashant Shah wrote:
> Hi,
>
>> int happened = 0;
>>
>> - spin_lock(>lock);
>> if (ud->event != 0)
>> happened = 1;
>> - spin_unlock(>lock);
>>
>> return happened;
>
> I am guessing locking was intended to protect ud->event along with
> happened so that (checking the value of ud->event and setting value of
> happened) was atomic.
>
> return ud->event != 0 ? 1 : 0;
>
> Regards.
--
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 v2] makedumpfile: Add a default action to exclude hwpoison page from vmcore
Hello Tanino-san,
On Wed, 31 Oct 2012 23:05:01 +0900
Mitsuhiro Tanino wrote:
> This patch introduces a function which excludes hwpoison pages
> from vmcore as a default action for makedumpfile.
>
> Signed-off-by: Mitsuhiro Tanino
Thank you for your work. I think it's good feature.
I will merge this patch into makedumpfile-1.5.2 with the small change below.
Of course, I will accept --no-hwposion-filtering option when it's needed.
diff --git a/makedumpfile.c b/makedumpfile.c
index 30cf130..fcf42f6 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -3864,8 +3864,8 @@ __exclude_unnecessary_pages(unsigned long mem_map,
* Exclude the hwpoison page.
*/
else if (isHWPOISON(flags)) {
- clear_bit_on_2nd_bitmap_for_kernel(pfn);
- pfn_hwpoison++;
+ if (clear_bit_on_2nd_bitmap_for_kernel(pfn))
+ pfn_hwpoison++;
}
}
return TRUE;
Thanks
Atsushi Kumagai
> diff -uprN a/makedumpfile.c b/makedumpfile.c
> --- a/makedumpfile.c 2012-10-01 15:26:54.510354074 +0900
> +++ b/makedumpfile.c 2012-10-29 22:32:24.913057535 +0900
> @@ -43,6 +43,7 @@ unsigned long long pfn_cache;
> unsigned long long pfn_cache_private;
> unsigned long long pfn_user;
> unsigned long long pfn_free;
> +unsigned long long pfn_hwpoison;
>
> unsigned long long num_dumped;
>
> @@ -969,6 +970,7 @@ get_structure_info(void)
> ENUM_NUMBER_INIT(PG_lru, "PG_lru");
> ENUM_NUMBER_INIT(PG_private, "PG_private");
> ENUM_NUMBER_INIT(PG_swapcache, "PG_swapcache");
> + ENUM_NUMBER_INIT(PG_hwpoison, "PG_hwpoison");
>
> TYPEDEF_SIZE_INIT(nodemask_t, "nodemask_t");
>
> @@ -1371,6 +1373,7 @@ write_vmcoreinfo_data(void)
> WRITE_NUMBER("PG_lru", PG_lru);
> WRITE_NUMBER("PG_private", PG_private);
> WRITE_NUMBER("PG_swapcache", PG_swapcache);
> + WRITE_NUMBER("PG_hwpoison", PG_hwpoison);
>
> /*
>* write the source file of 1st kernel
> @@ -1659,6 +1662,7 @@ read_vmcoreinfo(void)
> READ_NUMBER("PG_lru", PG_lru);
> READ_NUMBER("PG_private", PG_private);
> READ_NUMBER("PG_swapcache", PG_swapcache);
> + READ_NUMBER("PG_hwpoison", PG_hwpoison);
>
> READ_SRCFILE("pud_t", pud_t);
>
> @@ -3856,6 +3860,13 @@ __exclude_unnecessary_pages(unsigned lon
> if (clear_bit_on_2nd_bitmap_for_kernel(pfn))
> pfn_user++;
> }
> + /*
> + * Exclude the hwpoison page.
> + */
> + else if (isHWPOISON(flags)) {
> + clear_bit_on_2nd_bitmap_for_kernel(pfn);
> + pfn_hwpoison++;
> + }
> }
> return TRUE;
> }
> @@ -3914,11 +3925,13 @@ exclude_unnecessary_pages_cyclic(void)
> return FALSE;
>
> /*
> - * Exclude cache pages, cache private pages, user data pages, and free
> pages.
> + * Exclude cache pages, cache private pages, user data pages,
> +free pages and hwpoison pages.
>*/
> if (info->dump_level & DL_EXCLUDE_CACHE ||
> info->dump_level & DL_EXCLUDE_CACHE_PRI ||
> - info->dump_level & DL_EXCLUDE_USER_DATA) {
> + info->dump_level & DL_EXCLUDE_USER_DATA ||
> + (NUMBER(PG_hwpoison) != NOT_FOUND_NUMBER)) {
>
> gettimeofday(_start, NULL);
>
> @@ -4018,11 +4031,13 @@ create_2nd_bitmap(void)
> }
>
> /*
> - * Exclude cache pages, cache private pages, user data pages.
> + * Exclude cache pages, cache private pages, user data pages,
> + * and hwpoison pages.
>*/
> if (info->dump_level & DL_EXCLUDE_CACHE ||
> info->dump_level & DL_EXCLUDE_CACHE_PRI ||
> - info->dump_level & DL_EXCLUDE_USER_DATA) {
> + info->dump_level & DL_EXCLUDE_USER_DATA ||
> + (NUMBER(PG_hwpoison) != NOT_FOUND_NUMBER)) {
> if (!exclude_unnecessary_pages()) {
> ERRMSG("Can't exclude unnecessary pages.\n");
> return FALSE;
> @@ -5062,7 +5077,8 @@ write_elf_pages_cyclic(struct cache_data
> /*
>* Reset counter for debug message.
>*/
> - pfn_zero = pfn_cache = pfn_cache_private = pfn_user = pfn_free = 0;
> + pfn_zero = pfn_cache = pfn_cache_private = 0;
> + pfn_user = pfn_free = pfn_hwpoison = 0;
> pfn_memhole = info->max_mapnr;
>
> info->cyclic_start_pfn = 0;
> @@ -5902,7 +5918,8 @@ write_kdump_pages_and_bitmap_cyclic(stru
> /*
>* Reset counter for debug message.
>*/
> - pfn_zero = pfn_cache = pfn_cache_private = pfn_user = pfn_free = 0;
> + pfn_zero = pfn_cache = pfn_cache_private = 0;
> + pfn_user = pfn_free = pfn_hwpoison = 0;
> pfn_memhole = info->max_mapnr;
>
> cd_header->offset
> @@ -6687,7 +6704,7 @@ print_report(void)
>
Re: [PATCH] vlan: set sysfs device_type to 'vlan'
On Sun, Nov 4, 2012 at 11:53 PM, David Miller wrote: > From: Doug Goldstein > Date: Sun, 4 Nov 2012 23:45:56 -0600 > >> As Ben Greear pointed out this would allow shell scripts and other >> scripting languages to better detect vlans. Kay pointed out that this >> would allow better uevent filters in the future as well. So there are >> some merits to this patch. If you'd prefer I can resubmit with a >> better commit message entailing the reasons behind it. > > For the thousandth time: > > All of those scripts and other users of this new facility will > need to have backup code to detect vlan devices when this > sysfs thing is not present. > > They are already to determine this information already, and > they alreayd have to be ugly to handle EVERY EXISTING KERNEL > ON THE PLANET. > > So the effective value is zero. By this argument we shouldn't ever improve any API or add new syscalls since we'll have to have fallback code to handle the old interfaces when the new ones aren't available. Since everything already has the existing implementations to handle every existing kernel on the planet then this patch doesn't harm anything and should I want to write a shell script that only works on Linux 3.8 (assuming this patch is in there) and is only forward looking then I can use the more complete sysfs. So the effective penalty is zero and you get a more complete sysfs, which is where you're value is. -- Doug Goldstein -- 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] [SCSI] bnx2fc: fix NULL checking in bnx2fc_initiate_tmf()
The dereference rport->data should come after the NULL check of rport.
Signed-off-by: Xi Wang
---
drivers/scsi/bnx2fc/bnx2fc_io.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c
index 8d4626c..eebe93c 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_io.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_io.c
@@ -686,7 +686,7 @@ static int bnx2fc_initiate_tmf(struct scsi_cmnd *sc_cmd, u8
tm_flags)
{
struct fc_lport *lport;
struct fc_rport *rport = starget_to_rport(scsi_target(sc_cmd->device));
- struct fc_rport_libfc_priv *rp = rport->dd_data;
+ struct fc_rport_libfc_priv *rp;
struct fcoe_port *port;
struct bnx2fc_interface *interface;
struct bnx2fc_rport *tgt;
@@ -712,6 +712,7 @@ static int bnx2fc_initiate_tmf(struct scsi_cmnd *sc_cmd, u8
tm_flags)
rc = FAILED;
goto tmf_err;
}
+ rp = rport->dd_data;
rc = fc_block_scsi_eh(sc_cmd);
if (rc)
--
1.7.10.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: [RFC] Second attempt at kernel secure boot support
Matthew Garrett writes: > On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote: > >> I've actually had more than enough experience with automated installs >> over my career: they're either done by paying someone or using a >> provisioning system. In either case, they provision a static image and >> boot environment description, including EFI boot services variables, so >> you can provision a default MOK database if you want the ignition image >> not to pause on firstboot. > > And now you've moved the attack vector to a copy of your provisioning > system instead. > >> There is obviously the question of making the provisioning systems >> secure, but it's a separate one from making boot secure. > > You don't get to punt on making the kernel secure by simply asserting > that some other system can be secure instead. The chain of trust needs > to go all the way back - if your security model is based on all installs > needing a physically present end user, all installs need a physically > present end user. That's not acceptable, so we need a different security > model. Bzzzt. Theory and reality disagreeing. I have done a lot of automatic installs. At the very least someone has to be present to apply power to the hardware. So someone being present is not a requirement you can remove. Furthermore in most cases an automatic install requires kicking the system into network boot mode or into inserting an install cd. Both are actions that require a user to be present. The goal is to reduce what a user must do to a minimum to remove the possibility of human error, not to reduce what must happen into absurdity. The other side is that a general purpose configuration of firmware almost never is suitable for a general install. So either some small amount of time must be spent fixing the BIOS settings or have an appropriate set of BIOS settings come from your supplier. In practice what I would expect of a UEFI system that ships ready for automatic installs is a system that initiall boots up in "setup mode" where it is possible to install your own platform signing key. What I would expect to happen in that situation is that during the first boot software would come over the network or from an install cd and install my platform signing key. Then a bootloader signed with my key would be installed, and then everything would chain from there. In most cases where I would be setting up an automatic install I would not install Microsoft's key, and I would definitely not sign my bootloader with Microsoft's key. At most I would sign my own "key install" with Microsoft's key. Then in cases of automatic reinstallation my key would be in the firmware and I could change my bootloader and my kernels at will with no risk that some third party could do anything to the machine unless they manged to get physical access. If I was a distroy my key would that I would install by default would be the distro's signing key. Although honestly I would still prefer a solution where I could lock things down a little farther. In any case the notion that unattended install with no user interaction on any uefi machine in any state is complete and total rubbish. It can't be done. You need power and you need boot media. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3, v2] AMD64 EDAC: Cleanup type usage to be consistent
As the Northbridge IDs are at most 16-bits, use the same type
consistently and cleanup some indexes to use smaller types.
v2: Drop unneeded changes and changes Boris will cleanup later
Signed-off-by: Daniel J Blueman
---
arch/x86/include/asm/amd_nb.h|2 +-
arch/x86/include/asm/processor.h |2 +-
arch/x86/kernel/cpu/amd.c|4 ++--
drivers/edac/amd64_edac.c| 14 +++---
drivers/edac/amd64_edac.h|6 +++---
5 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/x86/include/asm/amd_nb.h b/arch/x86/include/asm/amd_nb.h
index 9f5532a..b0815a0 100644
--- a/arch/x86/include/asm/amd_nb.h
+++ b/arch/x86/include/asm/amd_nb.h
@@ -76,7 +76,7 @@ static inline bool amd_nb_has_feature(unsigned feature)
return ((amd_northbridges.flags & feature) == feature);
}
-static inline struct amd_northbridge *node_to_amd_nb(int node)
+static inline struct amd_northbridge *node_to_amd_nb(u16 node)
{
return (node < amd_northbridges.num) ? _northbridges.nb[node] :
NULL;
}
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index ad1fc85..eb3ba58 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -934,7 +934,7 @@ extern void start_thread(struct pt_regs *regs, unsigned
long new_ip,
extern int get_tsc_mode(unsigned long adr);
extern int set_tsc_mode(unsigned int val);
-extern int amd_get_nb_id(int cpu);
+extern u16 amd_get_nb_id(int cpu);
struct aperfmperf {
u64 aperf, mperf;
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index f7e98a2..52cab1f 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -364,9 +364,9 @@ static void __cpuinit amd_detect_cmp(struct cpuinfo_x86 *c)
#endif
}
-int amd_get_nb_id(int cpu)
+u16 amd_get_nb_id(int cpu)
{
- int id = 0;
+ u16 id = 0;
#ifdef CONFIG_SMP
id = per_cpu(cpu_llc_id, cpu);
#endif
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 5dfe452..a3e297a 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -239,7 +239,7 @@ static int amd64_get_scrub_rate(struct mem_ctl_info *mci)
* DRAM base/limit associated with node_id
*/
static bool amd64_base_limit_match(struct amd64_pvt *pvt, u64 sys_addr,
- unsigned nid)
+ u8 nid)
{
u64 addr;
@@ -265,7 +265,7 @@ static struct mem_ctl_info *find_mc_by_sys_addr(struct
mem_ctl_info *mci,
u64 sys_addr)
{
struct amd64_pvt *pvt;
- unsigned node_id;
+ u8 node_id;
u32 intlv_en, bits;
/*
@@ -1349,7 +1349,7 @@ static u8 f1x_determine_channel(struct amd64_pvt *pvt,
u64 sys_addr,
}
/* Convert the sys_addr to the normalized DCT address */
-static u64 f1x_get_norm_dct_addr(struct amd64_pvt *pvt, unsigned range,
+static u64 f1x_get_norm_dct_addr(struct amd64_pvt *pvt, u8 range,
u64 sys_addr, bool hi_rng,
u32 dct_sel_base_addr)
{
@@ -1400,7 +1400,7 @@ static u64 f1x_get_norm_dct_addr(struct amd64_pvt *pvt,
unsigned range,
* checks if the csrow passed in is marked as SPARED, if so returns the new
* spare row
*/
-static int f10_process_possible_spare(struct amd64_pvt *pvt, u8 dct, int csrow)
+static int f10_process_possible_spare(struct amd64_pvt *pvt, u16 dct, int
csrow)
{
int tmp_cs;
@@ -1425,7 +1425,7 @@ static int f10_process_possible_spare(struct amd64_pvt
*pvt, u8 dct, int csrow)
* -EINVAL: NOT FOUND
* 0..csrow = Chip-Select Row
*/
-static int f1x_lookup_addr_in_dct(u64 in_addr, u32 nid, u8 dct)
+static int f1x_lookup_addr_in_dct(u64 in_addr, u16 nid, u8 dct)
{
struct mem_ctl_info *mci;
struct amd64_pvt *pvt;
@@ -2257,7 +2257,7 @@ static int init_csrows(struct mem_ctl_info *mci)
}
/* get all cores on this DCT */
-static void get_cpus_on_this_dct_cpumask(struct cpumask *mask, unsigned nid)
+static void get_cpus_on_this_dct_cpumask(struct cpumask *mask, u16 nid)
{
int cpu;
@@ -2267,7 +2267,7 @@ static void get_cpus_on_this_dct_cpumask(struct cpumask
*mask, unsigned nid)
}
/* check MCG_CTL on all the cpus on this node */
-static bool amd64_nb_mce_bank_enabled_on_node(unsigned nid)
+static bool amd64_nb_mce_bank_enabled_on_node(u16 nid)
{
cpumask_var_t mask;
int cpu, nbe;
diff --git a/drivers/edac/amd64_edac.h b/drivers/edac/amd64_edac.h
index 90cae61..a2ea6a4 100644
--- a/drivers/edac/amd64_edac.h
+++ b/drivers/edac/amd64_edac.h
@@ -332,7 +332,7 @@ struct amd64_pvt {
/* pci_device handles which we utilize */
struct pci_dev *F1, *F2, *F3;
- unsigned mc_node_id;/* MC index of this MC node */
+ u16 mc_node_id; /* MC index of this MC node */
int ext_model; /* extended model value of this node */
int channel_count;
[PATCH 2/3, v3] AMD64 EDAC: Support >255 memory controllers
As the AMD64 last-level-cache ID is 16-bits and federated systems
eg using Numascale's NumaConnect/NumaChip can have more than 255 memory
controllers, use 16-bits to store the ID.
v2: Avoid change to intlv_en variable
v3: Drop unneeded change to index
Signed-off-by: Daniel J Blueman
---
drivers/edac/amd64_edac.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 852f1cd..5dfe452 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -942,7 +942,8 @@ static u64 get_error_address(struct mce *m)
struct amd64_pvt *pvt;
u64 cc6_base, tmp_addr;
u32 tmp;
- u8 mce_nid, intlv_en;
+ u16 mce_nid;
+ u8 intlv_en;
if ((addr & GENMASK(24, 47)) >> 24 != 0x00fdf7)
return addr;
@@ -2299,7 +2300,7 @@ out:
return ret;
}
-static int toggle_ecc_err_reporting(struct ecc_settings *s, u8 nid, bool on)
+static int toggle_ecc_err_reporting(struct ecc_settings *s, u16 nid, bool on)
{
cpumask_var_t cmask;
int cpu;
@@ -2337,7 +2338,7 @@ static int toggle_ecc_err_reporting(struct ecc_settings
*s, u8 nid, bool on)
return 0;
}
-static bool enable_ecc_error_reporting(struct ecc_settings *s, u8 nid,
+static bool enable_ecc_error_reporting(struct ecc_settings *s, u16 nid,
struct pci_dev *F3)
{
bool ret = true;
@@ -2389,7 +2390,7 @@ static bool enable_ecc_error_reporting(struct
ecc_settings *s, u8 nid,
return ret;
}
-static void restore_ecc_error_reporting(struct ecc_settings *s, u8 nid,
+static void restore_ecc_error_reporting(struct ecc_settings *s, u16 nid,
struct pci_dev *F3)
{
u32 value, mask = 0x3; /* UECC/CECC enable */
@@ -2428,7 +2429,7 @@ static const char *ecc_msg =
"'ecc_enable_override'.\n"
" (Note that use of the override may cause unknown side effects.)\n";
-static bool ecc_enabled(struct pci_dev *F3, u8 nid)
+static bool ecc_enabled(struct pci_dev *F3, u16 nid)
{
u32 value;
u8 ecc_en = 0;
@@ -2549,7 +2550,7 @@ static int amd64_init_one_instance(struct pci_dev *F2)
struct mem_ctl_info *mci = NULL;
struct edac_mc_layer layers[2];
int err = 0, ret;
- u8 nid = amd_get_node_id(F2);
+ u16 nid = amd_get_node_id(F2);
ret = -ENOMEM;
pvt = kzalloc(sizeof(struct amd64_pvt), GFP_KERNEL);
@@ -2640,7 +2641,7 @@ err_ret:
static int __devinit amd64_probe_one_instance(struct pci_dev *pdev,
const struct pci_device_id
*mc_type)
{
- u8 nid = amd_get_node_id(pdev);
+ u16 nid = amd_get_node_id(pdev);
struct pci_dev *F3 = node_to_amd_nb(nid)->misc;
struct ecc_settings *s;
int ret = 0;
@@ -2690,7 +2691,7 @@ static void __devexit amd64_remove_one_instance(struct
pci_dev *pdev)
{
struct mem_ctl_info *mci;
struct amd64_pvt *pvt;
- u8 nid = amd_get_node_id(pdev);
+ u16 nid = amd_get_node_id(pdev);
struct pci_dev *F3 = node_to_amd_nb(nid)->misc;
struct ecc_settings *s = ecc_stngs[nid];
--
1.7.10.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/3, v5] AMD64 EDAC: Add muli-domain support
Fix the handling of memory controller detection to index the array
of detected Northbridges, allowing memory controllers over multiple
PCI domains in federated systems eg using Numascale's NumaConnect/
NumaChip.
v4: Generate linear Northbridge ID by indexing detected Northbridges
v5: Reorder functions to prevent extra function declaration; merge 4th
patch; simplify Fam15h code; add detail to warning
Signed-off-by: Daniel J Blueman
---
arch/x86/include/asm/amd_nb.h | 13 +++
drivers/edac/amd64_edac.c | 49 ++---
drivers/edac/amd64_edac.h |6 -
3 files changed, 39 insertions(+), 29 deletions(-)
diff --git a/arch/x86/include/asm/amd_nb.h b/arch/x86/include/asm/amd_nb.h
index b3341e9..9f5532a 100644
--- a/arch/x86/include/asm/amd_nb.h
+++ b/arch/x86/include/asm/amd_nb.h
@@ -81,6 +81,19 @@ static inline struct amd_northbridge *node_to_amd_nb(int
node)
return (node < amd_northbridges.num) ? _northbridges.nb[node] :
NULL;
}
+static inline u16 amd_get_node_id(struct pci_dev *pdev)
+{
+ int i;
+
+ for (i = 0; i != amd_nb_num(); i++)
+ if (pci_domain_nr(node_to_amd_nb(i)->misc->bus) ==
pci_domain_nr(pdev->bus) &&
+ PCI_SLOT(node_to_amd_nb(i)->misc->devfn) ==
PCI_SLOT(pdev->devfn))
+ return i;
+
+ WARN(1, "Unable to find AMD Northbridge identifier for %s\n",
pci_name(pdev));
+ return 0;
+}
+
#else
#define amd_nb_num(x) 0
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index cc8e7c7..852f1cd 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -982,6 +982,24 @@ static u64 get_error_address(struct mce *m)
return addr;
}
+static struct pci_dev *pci_get_related_function(unsigned int vendor,
+ unsigned int device,
+ struct pci_dev *related)
+{
+ struct pci_dev *dev = NULL;
+
+ dev = pci_get_device(vendor, device, dev);
+ while (dev) {
+ if (pci_domain_nr(dev->bus) == pci_domain_nr(related->bus) &&
+ (dev->bus->number == related->bus->number) &&
+ (PCI_SLOT(dev->devfn) == PCI_SLOT(related->devfn)))
+ break;
+ dev = pci_get_device(vendor, device, dev);
+ }
+
+ return dev;
+}
+
static void read_dram_base_limit_regs(struct amd64_pvt *pvt, unsigned range)
{
struct cpuinfo_x86 *c = _cpu_data;
@@ -1001,11 +1019,13 @@ static void read_dram_base_limit_regs(struct amd64_pvt
*pvt, unsigned range)
/* Factor in CC6 save area by reading dst node's limit reg */
if (c->x86 == 0x15) {
- struct pci_dev *f1 = NULL;
- u8 nid = dram_dst_node(pvt, range);
+ struct pci_dev *misc, *f1 = NULL;
+ struct amd64_family_type *fam_type;
+ u16 nid = dram_dst_node(pvt, range);
u32 llim;
- f1 = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0x18 + nid,
1));
+ misc = node_to_amd_nb(nid)->misc;
+ f1 = pci_get_related_function(misc->vendor,
PCI_DEVICE_ID_AMD_15H_NB_F1, misc);
if (WARN_ON(!f1))
return;
@@ -1712,23 +1732,6 @@ static struct amd64_family_type amd64_family_types[] = {
},
};
-static struct pci_dev *pci_get_related_function(unsigned int vendor,
- unsigned int device,
- struct pci_dev *related)
-{
- struct pci_dev *dev = NULL;
-
- dev = pci_get_device(vendor, device, dev);
- while (dev) {
- if ((dev->bus->number == related->bus->number) &&
- (PCI_SLOT(dev->devfn) == PCI_SLOT(related->devfn)))
- break;
- dev = pci_get_device(vendor, device, dev);
- }
-
- return dev;
-}
-
/*
* These are tables of eigenvectors (one per line) which can be used for the
* construction of the syndrome tables. The modified syndrome search algorithm
@@ -2546,7 +2549,7 @@ static int amd64_init_one_instance(struct pci_dev *F2)
struct mem_ctl_info *mci = NULL;
struct edac_mc_layer layers[2];
int err = 0, ret;
- u8 nid = get_node_id(F2);
+ u8 nid = amd_get_node_id(F2);
ret = -ENOMEM;
pvt = kzalloc(sizeof(struct amd64_pvt), GFP_KERNEL);
@@ -2637,7 +2640,7 @@ err_ret:
static int __devinit amd64_probe_one_instance(struct pci_dev *pdev,
const struct pci_device_id
*mc_type)
{
- u8 nid = get_node_id(pdev);
+ u8 nid = amd_get_node_id(pdev);
struct pci_dev *F3 = node_to_amd_nb(nid)->misc;
struct ecc_settings *s;
int ret = 0;
@@ -2687,7 +2690,7 @@ static void __devexit amd64_remove_one_instance(struct
pci_dev *pdev)
{
kernels from 3.3.x series onwards fail to boot on ARM-based ZEUS (XScale PXA270) Single Board Computer
Hi, Although the ARM-based Zeus (XScale PXA270) Single board computer works well for 3.2.x series kernels, it fails to boot from series 3.3.x. It attempts to boot but stops at: "Uncompressing Linux... done, booting the kernel". This problem is also exhibited in kernel series 3.4.x, 3.5.x, 3.6.x. The kernels are configured with zeus_defconfig and built with arm-iwmmxt-linux-gnueabi toolchain. Please CC answers/comments posted. Thanks & Regards, Sanjeev N. -- 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] staging: ste_rmi4: Convert to Type-B support
Hi Henrik,
> > This patch converts to MT-B because Synaptics touch devices are
> > capable of tracking identifiable fingers
> >
> > This patch was tested on pandaboard, except input_mt_sync_frame(),
> > which is a quite new function.
>
> I am not sure how to interpret this. Is the patch untested, or tested
> on something different from a pandaboard?
My validation platform is pandaboard. However kernel running on pandaboard
Have not been updated to 3.7, therefore kernel does not contain function
input_mt_sync_frame(). When I tested my patch on pandaboard, I modified
the patch to call function input_mt_report_pointer_emulation(), instead of
calling function input_mt_sync_frame(). I think calling
input_mt_report_pointer_emulation() or input_mt_sync_frame()
should have the same results.
Please let me know if my understanding is incorrect.
> > I changed to use sylpheed as my mail client. Please let me know
> > if there is any problem.
> > Greatly appreciate your time.
>
> As mentioned, the commit message of the patch should not contain mail
> conversation.
Oh, I see! I should move conversation message to the outside of the patch
content. Thanks for your reminder.
> > drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c | 122
> -
> > 1 files changed, 57 insertions(+), 65 deletions(-)
> >
> > diff --git a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
> b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
> > index 277491a..7876f6b 100644
> > --- a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
> > +++ b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
> > @@ -1,7 +1,7 @@
> > /**
> > *
> > - * Synaptics Register Mapped Interface (RMI4) I2C Physical Layer Driver.
> > - * Copyright (c) 2007-2010, Synaptics Incorporated
> > + * Synaptics Register Mapped Interface (RMI4) I2C Touchscreen Driver.
> > + * Copyright (c) 2007-2012, Synaptics Incorporated
> > *
> > * Author: Js HA for ST-Ericsson
> > * Author: Naveen Kumar G for
> ST-Ericsson
> > @@ -31,6 +31,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include "synaptics_i2c_rmi4.h"
> >
> > /* TODO: for multiple device support will need a per-device mutex */
> > @@ -63,12 +64,11 @@
> > #define MASK_4BIT 0x0F
> > #define MASK_3BIT 0x07
> > #define MASK_2BIT 0x03
> > -#define TOUCHPAD_CTRL_INTR 0x8
> > +#define TOUCHSCREEN_CTRL_INTR 0x8
> > #define PDT_START_SCAN_LOCATION (0x00E9)
> > #define PDT_END_SCAN_LOCATION (0x000A)
> > #define PDT_ENTRY_SIZE (0x0006)
> > -#define RMI4_NUMBER_OF_MAX_FINGERS (8)
> > -#define SYNAPTICS_RMI4_TOUCHPAD_FUNC_NUM (0x11)
> > +#define SYNAPTICS_RMI4_TOUCHSCREEN_FUNC_NUM(0x11)
> > #define SYNAPTICS_RMI4_DEVICE_CONTROL_FUNC_NUM (0x01)
> >
> > /**
> > @@ -164,6 +164,7 @@ struct synaptics_rmi4_device_info {
> > * @regulator: pointer to the regulator structure
> > * @wait: wait queue structure variable
> > * @touch_stopped: flag to stop the thread function
> > + * @fingers_supported: maximum supported fingers
> > *
> > * This structure gives the device data information.
> > */
> > @@ -184,6 +185,7 @@ struct synaptics_rmi4_data {
> > struct regulator*regulator;
> > wait_queue_head_t wait;
> > booltouch_stopped;
> > + unsigned char fingers_supported;
> > };
> >
> > /**
> > @@ -291,34 +293,33 @@ exit:
> > }
> >
> > /**
> > - * synpatics_rmi4_touchpad_report() - reports for the rmi4 touchpad device
> > + * synpatics_rmi4_touchscreen_report() - reports for the rmi4 touchscreen
> device
> > * @pdata: pointer to synaptics_rmi4_data structure
> > * @rfi: pointer to synaptics_rmi4_fn structure
> > *
> > - * This function calls to reports for the rmi4 touchpad device
> > + * This function calls to reports for the rmi4 touchscreen device
> > */
> > -static int synpatics_rmi4_touchpad_report(struct synaptics_rmi4_data
> > *pdata,
> > +static int synpatics_rmi4_touchscreen_report(struct synaptics_rmi4_data
> *pdata,
> > struct synaptics_rmi4_fn *rfi)
> > {
> > /* number of touch points - fingers down in this case */
> > int touch_count = 0;
> > int finger;
> > - int fingers_supported;
> > int finger_registers;
> > int reg;
> > int finger_shift;
> > int finger_status;
> > int retval;
> > + int x, y;
> > + int wx, wy;
> > unsigned short data_base_addr;
> > unsigned short data_offset;
> > unsigned char data_reg_blk_size;
> > unsigned char values[2];
> > unsigned char data[DATA_LEN];
> > - int x[RMI4_NUMBER_OF_MAX_FINGERS];
> > - int y[RMI4_NUMBER_OF_MAX_FINGERS];
> > - int wx[RMI4_NUMBER_OF_MAX_FINGERS];
> > - int wy[RMI4_NUMBER_OF_MAX_FINGERS];
> > + unsigned char fingers_supported = pdata->fingers_supported;
> > struct i2c_client *client = pdata->i2c_client;
> > +
[PATCH] ARM: dts: AM33XX: Add usbss node
From: Ajay Kumar Gupta
Device tree node for usbss on AM33XX. There are two musb
controllers on am33xx platform so have port0-mode and
port1-mode data.
[af...@ti.com: reg & interrupt property addition]
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
Signed-off-by: Afzal Mohammed
---
Hi Benoit,
This is based on your "for_3.8/dts" branch.
This is made on top of "usb: musb: am335x support"
(http://marc.info/?l=linux-omap=135187391904863=2)
and has been tested on Beagle Bone.
Regards
Afzal
arch/arm/boot/dts/am33xx.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5dfd682..78340a5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -321,5 +321,22 @@
ti,hwmods = "spi1";
status = "disabled";
};
+
+ usb_otg_hs@4740 {
+ compatible = "ti,musb-am33xx";
+ reg = <0x4740 0x1000/* usbss */
+ 0x47401000 0x800 /* musb instance 0 */
+ 0x47401800 0x800>; /* musb instance 1 */
+ interrupts = <17/* usbss */
+ 18/* musb instance 0 */
+ 19>; /* musb instance 1 */
+ multipoint = <1>;
+ num-eps = <16>;
+ ram-bits = <12>;
+ port0-mode = <3>;
+ port1-mode = <3>;
+ power = <250>;
+ ti,hwmods = "usb_otg_hs";
+ };
};
};
--
1.7.12
--
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] vlan: set sysfs device_type to 'vlan'
From: Doug Goldstein Date: Sun, 4 Nov 2012 23:45:56 -0600 > As Ben Greear pointed out this would allow shell scripts and other > scripting languages to better detect vlans. Kay pointed out that this > would allow better uevent filters in the future as well. So there are > some merits to this patch. If you'd prefer I can resubmit with a > better commit message entailing the reasons behind it. For the thousandth time: All of those scripts and other users of this new facility will need to have backup code to detect vlan devices when this sysfs thing is not present. They are already to determine this information already, and they alreayd have to be ugly to handle EVERY EXISTING KERNEL ON THE PLANET. So the effective value is zero. -- 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: Tree for Nov 5
Hi all, Changes since 20121102: The v4l-dvb tree still had its build failure so I used the version from next-20121026. The thermal tree gained a conflict against Linus' tree. The modules tree lost its build failure. The usb tree lost its build failures. The signal tree gained a conflict against the cortex tree. The akpm tree gained a conflict against the pm tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 209 trees (counting Linus' and 28 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (3d70f8c Linux 3.7-rc4) Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux) Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by list_head-style lists.) Merging arm-current/fixes (b43b1ff Merge tag 'fixes-for-rmk' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc into fixes) Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp) Merging powerpc-merge/merge (8c23f40 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging sparc/master (f7e8d9f qlogicpti: Fix build warning.) Merging net/master (cacb6ba net: inet_diag -- Return error code if protocol handler is missed) Merging sound-current/for-linus (16c2e1f ALSA: ice1724: Fix rate setup after resume) Merging pci-current/for-linus (0ff9514 PCI: Don't print anything while decoding is disabled) Merging wireless/master (6fe7cc7 ath9k: Test for TID only in BlockAcks while checking tx status) Merging driver-core.current/driver-core-linus (8f0d816 Linux 3.7-rc3) Merging tty.current/tty-linus (8f0d816 Linux 3.7-rc3) Merging usb.current/usb-linus (d99e65b USB: fix build with XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled) Merging staging.current/staging-linus (8f0d816 Linux 3.7-rc3) Merging char-misc.current/char-misc-linus (8f0d816 Linux 3.7-rc3) Merging input-current/for-linus (32ed191 Input: tsc40 - remove wrong announcement of pressure support) Merging md-current/for-linus (ed30be0 MD RAID10: Fix oops when creating RAID10 arrays via dm-raid.c) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (9efade1 crypto: cryptd - disable softirqs in cryptd_queue_worker to prevent data corruption) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging rr-fixes/fixes (59ef28b module: fix out-by-one error in kallsyms) Merging asm-generic/master (9b04ebd asm-generic/io.h: remove asm/cacheflush.h include) Merging arm/for-next (4a83d2e Merge remote-tracking branch 'wildea/asids' into for-next) Merging
[PATCH] drivers: ethernet: qlogic: netxen_nic_ethtool.c: Fixed a coding style issue
Fixed some coding style issues.
Signed-off-by: Kumar Amit Mehta
---
.../ethernet/qlogic/netxen/netxen_nic_ethtool.c| 86 ++--
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
index 6bf73e1..4ca2c19 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
@@ -218,7 +218,7 @@ skip:
check_sfp_module = netif_running(dev) &&
adapter->has_link_events;
} else {
- ecmd->supported |= (SUPPORTED_TP |SUPPORTED_Autoneg);
+ ecmd->supported |= (SUPPORTED_TP | SUPPORTED_Autoneg);
ecmd->advertising |=
(ADVERTISED_TP | ADVERTISED_Autoneg);
ecmd->port = PORT_TP;
@@ -381,7 +381,7 @@ static u32 netxen_nic_test_link(struct net_device *dev)
static int
netxen_nic_get_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom,
- u8 * bytes)
+ u8 *bytes)
{
struct netxen_adapter *adapter = netdev_priv(dev);
int offset;
@@ -498,19 +498,19 @@ netxen_nic_get_pauseparam(struct net_device *dev,
pause->rx_pause = netxen_gb_get_rx_flowctl(val);
val = NXRD32(adapter, NETXEN_NIU_GB_PAUSE_CTL);
switch (port) {
- case 0:
- pause->tx_pause =
!(netxen_gb_get_gb0_mask(val));
- break;
- case 1:
- pause->tx_pause =
!(netxen_gb_get_gb1_mask(val));
- break;
- case 2:
- pause->tx_pause =
!(netxen_gb_get_gb2_mask(val));
- break;
- case 3:
- default:
- pause->tx_pause =
!(netxen_gb_get_gb3_mask(val));
- break;
+ case 0:
+ pause->tx_pause = !(netxen_gb_get_gb0_mask(val));
+ break;
+ case 1:
+ pause->tx_pause = !(netxen_gb_get_gb1_mask(val));
+ break;
+ case 2:
+ pause->tx_pause = !(netxen_gb_get_gb2_mask(val));
+ break;
+ case 3:
+ default:
+ pause->tx_pause = !(netxen_gb_get_gb3_mask(val));
+ break;
}
} else if (adapter->ahw.port_type == NETXEN_NIC_XGBE) {
if ((port < 0) || (port >= NETXEN_NIU_MAX_XG_PORTS))
@@ -556,31 +556,31 @@ netxen_nic_set_pauseparam(struct net_device *dev,
/* set autoneg */
val = NXRD32(adapter, NETXEN_NIU_GB_PAUSE_CTL);
switch (port) {
- case 0:
- if (pause->tx_pause)
- netxen_gb_unset_gb0_mask(val);
- else
- netxen_gb_set_gb0_mask(val);
- break;
- case 1:
- if (pause->tx_pause)
- netxen_gb_unset_gb1_mask(val);
- else
- netxen_gb_set_gb1_mask(val);
- break;
- case 2:
- if (pause->tx_pause)
- netxen_gb_unset_gb2_mask(val);
- else
- netxen_gb_set_gb2_mask(val);
- break;
- case 3:
- default:
- if (pause->tx_pause)
- netxen_gb_unset_gb3_mask(val);
- else
- netxen_gb_set_gb3_mask(val);
- break;
+ case 0:
+ if (pause->tx_pause)
+ netxen_gb_unset_gb0_mask(val);
+ else
+ netxen_gb_set_gb0_mask(val);
+ break;
+ case 1:
+ if (pause->tx_pause)
+ netxen_gb_unset_gb1_mask(val);
+ else
+ netxen_gb_set_gb1_mask(val);
+ break;
+ case 2:
+ if (pause->tx_pause)
+ netxen_gb_unset_gb2_mask(val);
+ else
+
Re: [PATCH] vlan: set sysfs device_type to 'vlan'
On Tue, Oct 23, 2012 at 1:36 AM, David Miller wrote: > From: Doug Goldstein > Date: Mon, 22 Oct 2012 00:53:57 -0500 > >> Sets the sysfs device_type to 'vlan' for udev. This makes it easier for >> applications that query network information via udev to identify vlans >> instead of using strrchr(). >> >> Signed-off-by: Doug Goldstein > > You're extremely misguided. This change, in fact, makes it ten times > harder for such applications to query such devices. > > Because now the application has to decide whether it wants to support > EVERY EXISTING SYSTEM OUT THERE or not. Hundreds of millions of Linux > systems do not provide this attribute. > > Applications have to handle the case of not having the 'vlan' device > type available attribute essentially forever. > > So providing it in new kernels provides zero value whatsoever. > > I'm not applying this patch, sorry. Dave, As others on this thread have discussed there are other merits to the patch as well. Yes you are correct that netlink is the preferred method to gather information about network devices but the point was really to make the sysfs layout more correct a matter of completeness. As Ben Greear pointed out this would allow shell scripts and other scripting languages to better detect vlans. Kay pointed out that this would allow better uevent filters in the future as well. So there are some merits to this patch. If you'd prefer I can resubmit with a better commit message entailing the reasons behind it. Thanks. -- Doug Goldstein -- 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] cgroup: make ->pre_destroy() return void
On 2012/11/1 3:44, Tejun Heo wrote: > All ->pre_destory() implementations return 0 now, which is the only > allowed return value. Make it return void. > > Signed-off-by: Tejun Heo > Cc: Michal Hocko > Cc: Balbir Singh > Cc: KAMEZAWA Hiroyuki > Cc: Vivek Goyal Acked-by: Li Zefan -- 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 5/8] cgroup: remove CGRP_WAIT_ON_RMDIR, cgroup_exclude_rmdir() and cgroup_release_and_wakeup_rmdir()
On 2012/11/1 3:44, Tejun Heo wrote:
> CGRP_WAIT_ON_RMDIR is another kludge which was added to make cgroup
> destruction rollback somewhat working. cgroup_rmdir() used to drain
> CSS references and CGRP_WAIT_ON_RMDIR and the associated waitqueue and
> helpers were used to allow the task performing rmdir to wait for the
> next relevant event.
>
> Unfortunately, the wait is visible to controllers too and the
> mechanism got exposed to memcg by 887032670d ("cgroup avoid permanent
> sleep at rmdir").
>
> Now that the draining and retries are gone, CGRP_WAIT_ON_RMDIR is
> unnecessary. Remove it and all the mechanisms supporting it. Note
> that memcontrol.c changes are essentially revert of 887032670d
> ("cgroup avoid permanent sleep at rmdir").
>
> Signed-off-by: Tejun Heo
> Reviewed-by: Michal Hocko
> Cc: Balbir Singh
> Cc: KAMEZAWA Hiroyuki
> ---
> include/linux/cgroup.h | 21 -
> kernel/cgroup.c| 51
> --
> mm/memcontrol.c| 24 +---
> 3 files changed, 1 insertion(+), 95 deletions(-)
Acked-by: Li Zefan
--
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 4/8] cgroup: deactivate CSS's and mark cgroup dead before invoking ->pre_destroy()
On 2012/11/1 3:44, Tejun Heo wrote: > Because ->pre_destroy() could fail and can't be called under > cgroup_mutex, cgroup destruction did something very ugly. > > 1. Grab cgroup_mutex and verify it can be destroyed; fail otherwise. > > 2. Release cgroup_mutex and call ->pre_destroy(). > > 3. Re-grab cgroup_mutex and verify it can still be destroyed; fail > otherwise. > > 4. Continue destroying. > > In addition to being ugly, it has been always broken in various ways. > For example, memcg ->pre_destroy() expects the cgroup to be inactive > after it's done but tasks can be attached and detached between #2 and > #3 and the conditions that memcg verified in ->pre_destroy() might no > longer hold by the time control reaches #3. > > Now that ->pre_destroy() is no longer allowed to fail. We can switch > to the following. > > 1. Grab cgroup_mutex and verify it can be destroyed; fail otherwise. > > 2. Deactivate CSS's and mark the cgroup removed thus preventing any > further operations which can invalidate the verification from #1. > > 3. Release cgroup_mutex and call ->pre_destroy(). > > 4. Re-grab cgroup_mutex and continue destroying. > > After this change, controllers can safely assume that ->pre_destroy() > will only be called only once for a given cgroup and, once > ->pre_destroy() is called, the cgroup will stay dormant till it's > destroyed. > > This removes the only reason ->pre_destroy() can fail - new task being > attached or child cgroup being created inbetween. Error out path is > removed and ->pre_destroy() invocation is open coded in > cgroup_rmdir(). > > v2: cgroup_call_pre_destroy() removal moved to this patch per Michal. > Commit message updated per Glauber. > > Signed-off-by: Tejun Heo > Reviewed-by: Michal Hocko > Cc: Glauber Costa Acked-by: Li Zefan -- 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/8] cgroup: use cgroup_lock_live_group(parent) in cgroup_create()
On 2012/11/1 3:44, Tejun Heo wrote: > This patch makes cgroup_create() fail if @parent is marked removed. > This is to prepare for further updates to cgroup_rmdir() path. > > Note that this change isn't strictly necessary. cgroup can only be > created via mkdir and the removed marking and dentry removal happen > without releasing cgroup_mutex, so cgroup_create() can never race with > cgroup_rmdir(). Even after the scheduled updates to cgroup_rmdir(), > cgroup_mkdir() and cgroup_rmdir() are synchronized by i_mutex > rendering the added liveliness check unnecessary. > > Do it anyway such that locking is contained inside cgroup proper and > we don't get nasty surprises if we ever grow another caller of > cgroup_create(). > > Signed-off-by: Tejun Heo > Reviewed-by: Michal Hocko Acked-by: Li Zefan -- 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/8] cgroup: kill cgroup_subsys->__DEPRECATED_clear_css_refs
On 2012/11/1 3:44, Tejun Heo wrote:
> 2ef37d3fe4 ("memcg: Simplify mem_cgroup_force_empty_list error
> handling") removed the last user of __DEPRECATED_clear_css_refs. This
> patch removes __DEPRECATED_clear_css_refs and mechanisms to support
> it.
>
> * Conditionals dependent on __DEPRECATED_clear_css_refs removed.
>
> * cgroup_clear_css_refs() can no longer fail. All that needs to be
> done are deactivating refcnts, setting CSS_REMOVED and putting the
> base reference on each css. Remove cgroup_clear_css_refs() and the
> failure path, and open-code the loops into cgroup_rmdir().
>
> This patch keeps the two for_each_subsys() loops separate while open
> coding them. They can be merged now but there are scheduled changes
> which need them to be separate, so keep them separate to reduce the
> amount of churn.
>
> local_irq_save/restore() from cgroup_clear_css_refs() are replaced
> with local_irq_disable/enable() for simplicity. This is safe as
> cgroup_rmdir() is always called with IRQ enabled. Note that this IRQ
> switching is necessary to make CSS deactivation and CSS_REMOVED
> assertion atomic against css_tryget() and will be removed by future
> changes.
>
> v2: cgroup_call_pre_destroy() removal dropped per Michal. Commit
> message updated to explain local_irq_disable/enable() conversion.
>
> Signed-off-by: Tejun Heo
> Reviewed-by: Michal Hocko
Acked-by: Li Zefan
--
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/1] staging: usbip: remove an unnecessary lock in usbip_event_happened. The variable "happened" is local. So I think there is no need to lock here.
Hi, > int happened = 0; > > - spin_lock(>lock); > if (ud->event != 0) > happened = 1; > - spin_unlock(>lock); > > return happened; I am guessing locking was intended to protect ud->event along with happened so that (checking the value of ud->event and setting value of happened) was atomic. return ud->event != 0 ? 1 : 0; Regards. -- 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/8] cgroup: kill CSS_REMOVED
On 2012/11/1 3:44, Tejun Heo wrote: > CSS_REMOVED is one of the several contortions which were necessary to > support css reference draining on cgroup removal. All css->refcnts > which need draining should be deactivated and verified to equal zero > atomically w.r.t. css_tryget(). If any one isn't zero, all refcnts > needed to be re-activated and css_tryget() shouldn't fail in the > process. > > This was achieved by letting css_tryget() busy-loop until either the > refcnt is reactivated (failed removal attempt) or CSS_REMOVED is set > (committing to removal). > > Now that css refcnt draining is no longer used, there's no need for > atomic rollback mechanism. css_tryget() simply can look at the > reference count and fail if it's deactivated - it's never getting > re-activated. > > This patch removes CSS_REMOVED and updates __css_tryget() to fail if > the refcnt is deactivated. As deactivation and removal are a single > step now, they no longer need to be protected against css_tryget() > happening from irq context. Remove local_irq_disable/enable() from > cgroup_rmdir(). > > Note that this removes css_is_removed() whose only user is VM_BUG_ON() > in memcontrol.c. We can replace it with a check on the refcnt but > given that the only use case is a debug assert, I think it's better to > simply unexport it. > > v2: Comment updated and explanation on local_irq_disable/enable() > added per Michal Hocko. > > Signed-off-by: Tejun Heo > Reviewed-by: Michal Hocko > Cc: Johannes Weiner > Cc: Balbir Singh > Cc: KAMEZAWA Hiroyuki Acked-by: Li Zefan -- 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] drivers: ethernet: qlogic: qlge_dbg.c: Fixed a coding style issue
checkpatch.pl throws error message for the current code. This patch fixes
this coding style issue.
Signed-off-by: Kumar Amit Mehta
---
drivers/net/ethernet/qlogic/qlge/qlge_dbg.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
b/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
index 58185b6..10093f0 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_dbg.c
@@ -86,7 +86,7 @@ exit:
}
/* Read out the SERDES registers */
-static int ql_read_serdes_reg(struct ql_adapter *qdev, u32 reg, u32 * data)
+static int ql_read_serdes_reg(struct ql_adapter *qdev, u32 reg, u32 *data)
{
int status;
@@ -364,7 +364,7 @@ exit:
/* Read the 400 xgmac control/statistics registers
* skipping unused locations.
*/
-static int ql_get_xgmac_regs(struct ql_adapter *qdev, u32 * buf,
+static int ql_get_xgmac_regs(struct ql_adapter *qdev, u32 *buf,
unsigned int other_function)
{
int status = 0;
@@ -405,7 +405,7 @@ static int ql_get_xgmac_regs(struct ql_adapter *qdev, u32 *
buf,
return status;
}
-static int ql_get_ets_regs(struct ql_adapter *qdev, u32 * buf)
+static int ql_get_ets_regs(struct ql_adapter *qdev, u32 *buf)
{
int status = 0;
int i;
@@ -423,7 +423,7 @@ static int ql_get_ets_regs(struct ql_adapter *qdev, u32 *
buf)
return status;
}
-static void ql_get_intr_states(struct ql_adapter *qdev, u32 * buf)
+static void ql_get_intr_states(struct ql_adapter *qdev, u32 *buf)
{
int i;
@@ -434,7 +434,7 @@ static void ql_get_intr_states(struct ql_adapter *qdev, u32
* buf)
}
}
-static int ql_get_cam_entries(struct ql_adapter *qdev, u32 * buf)
+static int ql_get_cam_entries(struct ql_adapter *qdev, u32 *buf)
{
int i, status;
u32 value[3];
@@ -471,7 +471,7 @@ err:
return status;
}
-static int ql_get_routing_entries(struct ql_adapter *qdev, u32 * buf)
+static int ql_get_routing_entries(struct ql_adapter *qdev, u32 *buf)
{
int status;
u32 value, i;
@@ -496,7 +496,7 @@ err:
}
/* Read the MPI Processor shadow registers */
-static int ql_get_mpi_shadow_regs(struct ql_adapter *qdev, u32 * buf)
+static int ql_get_mpi_shadow_regs(struct ql_adapter *qdev, u32 *buf)
{
u32 i;
int status;
@@ -515,7 +515,7 @@ end:
}
/* Read the MPI Processor core registers */
-static int ql_get_mpi_regs(struct ql_adapter *qdev, u32 * buf,
+static int ql_get_mpi_regs(struct ql_adapter *qdev, u32 *buf,
u32 offset, u32 count)
{
int i, status = 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] staging: usbip: remove an unnecessary lock in usbip_event_happened. The variable "happened" is local. So I think there is no need to lock here.
On Mon, Nov 05, 2012 at 12:50:26PM +0800, Harvey Yang wrote:
> From: harvey.yang
>
>
> Signed-off-by: harvey.yang
> ---
> drivers/staging/usbip/usbip_event.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/usbip/usbip_event.c
> b/drivers/staging/usbip/usbip_event.c
> index d332a34..668f8e0 100644
> --- a/drivers/staging/usbip/usbip_event.c
> +++ b/drivers/staging/usbip/usbip_event.c
> @@ -116,10 +116,8 @@ int usbip_event_happened(struct usbip_device *ud)
> {
> int happened = 0;
>
> - spin_lock(>lock);
> if (ud->event != 0)
> happened = 1;
> - spin_unlock(>lock);
>
> return happened;
Are you sure that the real fix for this isn't just making 'happened' a
static variable? That would make more sense here. Well maybe, the code
seems pretty dumb, it's hard to tell what this is supposed to be doing,
any ideas?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm tree with the pm tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
drivers/acpi/acpi_memhotplug.c between commits 85fcb3758c10 ("ACPI /
memory-hotplug: introduce a mutex lock to protect the list in
acpi_memory_device") and d0fbb400b6f3 ("ACPI / memory-hotplug: add memory
offline code to acpi_memory_device_remove()") from the pm tree and commit
"acpi_memhotplug.c: fix memory leak when memory device is unbound from
the module acpi_memhotplug" from the akpm tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/acpi/acpi_memhotplug.c
index 92c973a,62c2c74..000
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@@ -131,6 -125,16 +131,18 @@@ acpi_memory_get_resource(struct acpi_re
return AE_OK;
}
+ static void
+ acpi_memory_free_device_resources(struct acpi_memory_device *mem_device)
+ {
+ struct acpi_memory_info *info, *n;
+
++ mutex_lock(_device->list_lock);
+ list_for_each_entry_safe(info, n, _device->res_list, list)
+ kfree(info);
+ INIT_LIST_HEAD(_device->res_list);
++ mutex_unlock(_device->list_lock);
+ }
+
static int
acpi_memory_get_device_resources(struct acpi_memory_device *mem_device)
{
@@@ -504,13 -490,7 +519,13 @@@ static int acpi_memory_device_remove(st
if (!device || !acpi_driver_data(device))
return -EINVAL;
- acpi_memory_device_free(acpi_driver_data(device));
+ mem_device = acpi_driver_data(device);
+
+ result = acpi_memory_remove_memory(mem_device);
+ if (result)
+ return result;
+
- kfree(mem_device);
++ acpi_memory_device_free(mem_device);
return 0;
}
pgp9hVTKAnCDQ.pgp
Description: PGP signature
[PATCH 1/1] staging: usbip: remove an unnecessary lock in usbip_event_happened. The variable "happened" is local. So I think there is no need to lock here.
From: harvey.yang
Signed-off-by: harvey.yang
---
drivers/staging/usbip/usbip_event.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/usbip/usbip_event.c
b/drivers/staging/usbip/usbip_event.c
index d332a34..668f8e0 100644
--- a/drivers/staging/usbip/usbip_event.c
+++ b/drivers/staging/usbip/usbip_event.c
@@ -116,10 +116,8 @@ int usbip_event_happened(struct usbip_device *ud)
{
int happened = 0;
- spin_lock(>lock);
if (ud->event != 0)
happened = 1;
- spin_unlock(>lock);
return happened;
}
--
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: mm: NULL ptr deref in anon_vma_interval_tree_verify
On Sun, Nov 4, 2012 at 8:14 PM, Bob Liu wrote: > Hmm, I attached a simple fix patch. Reviewed-by: Michel Lespinasse (also ran some tests with it, but I could never reproduce the original issue anyway). Bob, it would be easier if you had sent the original patch inline rather than as an attachment :) Andrew, can you get this simple fix into your -mm tree ? -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- 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: mm: NULL ptr deref in anon_vma_interval_tree_verify
On Mon, Nov 5, 2012 at 11:31 AM, Michel Lespinasse wrote: > On Sun, Nov 4, 2012 at 6:20 PM, Bob Liu wrote: >> The loop for each entry of vma->anon_vma_chain in validate_mm() is not >> protected by anon_vma lock. >> I think that may be the cause. >> >> Michel, What's your opinion？ > > Good catch, I think that's it. Somehow it had not occured to me to Hmm, I attached a simple fix patch. Sasha, Could you have a test to see whether it can fix your issue? Thanks, -Bob 0001-mm-add-anon_vma_lock-to-validate_mm.patch Description: Binary data
linux-next: manual merge of the signal tree with the cortex tree
Hi Al,
Today's linux-next merge of the signal tree got a conflict in
arch/arm/kernel/process.c between commit 77a3018e38b9 ("Cortex-M3: Add
support for exception handling") from the cortex tree and commit
9e6479930021 ("arm: switch to generic fork/vfork/clone") from the signal
tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/kernel/process.c
index 585b9ab,4ab80bb..000
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@@ -384,14 -383,11 +384,15 @@@ copy_thread(unsigned long clone_flags,
memset(>cpu_context, 0, sizeof(struct cpu_context_save));
- if (likely(regs)) {
- *childregs = *regs;
+ if (likely(!(p->flags & PF_KTHREAD))) {
+ *childregs = *current_pt_regs();
childregs->ARM_r0 = 0;
- childregs->ARM_sp = stack_start;
+ if (stack_start)
+ childregs->ARM_sp = stack_start;
+#if defined CONFIG_CPU_V7M
+ /* Return to Thread mode with Process stack */
+ childregs->ARM_EXC_RET = 0xfffdUL;
+#endif
} else {
memset(childregs, 0, sizeof(struct pt_regs));
thread->cpu_context.r4 = stk_sz;
pgpzfGXu9IXAA.pgp
Description: PGP signature
Re: [PATCH V2 1/3] mmc: esdhc: enable polling to detect card by itself
On 2012年11月05日 09:54, Shawn Guo wrote: On Fri, Nov 02, 2012 at 08:37:41PM +0800, yongd wrote: I got it. So how do you think of such below partition/reorganization? It looks fine to me for imx. Ok. I will update like this way if we have no other issues. Thanks. Patch-1: For sdhci-esdhc-imx.c, only add MMC_CAP_NEEDS_POLL for ESDHC_CD_NONE. With that improper logic of sdhci_add_host(), this is redundant, but shall be better than something unpleasant you mentioned. Patch-2: For sdhci-s3c.c, do exactly the same thing as Patch-1. Patch-3: For sdhci.c, remove that improper logic of sdhci_add_host(). Patch-4: For sdhci-esdhc-imx.c, set SDHCI_QUIRK_BROKEN_CARD_DETECTION for ESDHC_CD_GPIO. Patch-5: For sdhci-s3c.c, broaden SDHCI_QUIRK_BROKEN_CARD_DETECTION range for all detection types except S3C_SDHCI_CD_INTERNAL. Yes, not equal as before. But you just remind me of one more improper place in our current sdhci.c. Let's review those lines in sdhci_request() which are added by Anton long long ago in commit 68d1fb7e229c6f95be4fbbe3eb46b24e41184924(sdhci: Add support for card-detection polling), /* If polling, assume that the card is always present. */ if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) present = true; else present = sdhci_readl(host, SDHCI_PRESENT_STATE) & SDHCI_CARD_PRESENT; Here before sending command, if we can confirm the card dose not exist, we will return quickly without sending this command.This is a good optimization. But if polling, we can't do such checking, so we can only assume the card is always present. Here is another improper example of using SDHCI_QUIRK_BROKEN_CARD_DETECTION. Exactly the same as sdhci_add_host(), it thinks only polling and host internal card detection methods exist. Maybe we can determine whether and how we can do such card-existence-checking optimization based on our detection type directly rather than an indirect flag which should have its own pure meaning. But Let's do such similar further improvement in future since currently with my patch of setting SDHCI_QUIRK_BROKEN_CARD_DETECTION for ESDHC_CD_GPIO, functionality is OK as before. How do u think? I'm not sure it will function same as before. When I was testing your v2 series, I can not see card removal message with removing card, but can see it show up together with the next card inserting message. Shawn Shawn, From the code logic, without SDHCI_QUIRK_BROKEN_CARD_DETECTION for ESDHC_CD_GPIO, when your card (using GPIO detection) is removed, we can know the card's absence through the fake CARD_PRESENT flag in esdhc_readl_le(). As a result, we can quickly return ENOMEDIUM error without command sending. Finally mmc_rescan can know the card is removed. On the other hand, with SDHCI_QUIRK_BROKEN_CARD_DETECTION for ESDHC_CD_GPIO, we will just send MMC_SEND_STATUS command (cd_irq->sdhci_tasklet_card->mmc_recan->mmc_sd_detect->mmc_sd_alive), and we will find error since the card is already gone. Finally, we shall also know the card is removed. This is really strange why the removal message shows up together with the next card inserting message. Could u pls tell us more about what actually happened when the card is removed with my patches? Did the GPIO interrupt happen? Was mmc_rescan() called? Did mmc_sd_detect() finally find error when it sent MMC_SEND_STATUS? What step did the card removing procedure arrive at? Really really thanks a lot:-) -- 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: mm: NULL ptr deref in anon_vma_interval_tree_verify
On Sun, Nov 4, 2012 at 6:20 PM, Bob Liu wrote: > The loop for each entry of vma->anon_vma_chain in validate_mm() is not > protected by anon_vma lock. > I think that may be the cause. > > Michel, What's your opinion？ Good catch, I think that's it. Somehow it had not occured to me to verify the checker code - as in, who's checking the checker ? :) -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] MODSIGN: Only sign modules if built in-tree
Josh Boyer writes:
> diff --git a/Makefile b/Makefile
> index 14c93b3..7e27d51 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -722,8 +722,14 @@ export mod_strip_cmd
> ifeq ($(CONFIG_MODULE_SIG),y)
> MODSECKEY = ./signing_key.priv
> MODPUBKEY = ./signing_key.x509
> +ifeq ($(KBUILD_EXTMOD),)
> +SIGNFAIL = false
> +else
> +# External builds might not have a signing key, don't break module_install.
> +SIGNFAIL = true
> +endif # KBUILD_EXTMOD
> export MODPUBKEY
> -mod_sign_cmd = perl $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY)
> +mod_sign_cmd = $(SIGNFAIL) || perl $(srctree)/scripts/sign-file $(MODSECKEY)
> $(MODPUBKEY)
> else
> mod_sign_cmd = true
> endif
Huh? 'true || perl' never runs perl due to short circuiting.
Let's do this instead. Tested here, please ack.
Thanks,
Rusty.
modules: don't break modules_install on external modules with no key.
The script still spits out an error ("Can't read private key") but we
don't break modules_install.
Reported-by: Bruno Wolff III
Original-patch-by: Josh Boyer
Signed-off-by: Rusty Russell
diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst
index dda4b2b..ecbb447 100644
--- a/scripts/Makefile.modinst
+++ b/scripts/Makefile.modinst
@@ -16,8 +16,9 @@ PHONY += $(modules)
__modinst: $(modules)
@:
+# Don't stop modules_install if we can't sign external modules.
quiet_cmd_modules_install = INSTALL $@
- cmd_modules_install = mkdir -p $(2); cp $@ $(2) ; $(mod_strip_cmd)
$(2)/$(notdir $@) ; $(mod_sign_cmd) $(2)/$(notdir $@)
+ cmd_modules_install = mkdir -p $(2); cp $@ $(2) ; $(mod_strip_cmd)
$(2)/$(notdir $@) ; $(mod_sign_cmd) $(2)/$(notdir $@) $(patsubst %,||
true,$(KBUILD_EXTMOD))
# Modules built outside the kernel source tree go into extra by default
INSTALL_MOD_DIR ?= extra
--
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 6/9] virtio_mmio: Cast [1].start to ‘unsigned int *’ to rid compiler warning
Lee Jones writes: > drivers/virtio/virtio_mmio.c: In function ‘vm_cmdline_set’: > drivers/virtio/virtio_mmio.c:535:4: warning: format ‘%u’ expects argument of > type ‘unsigned int *’, but argument 4 has type ‘resource_size_t *’ [-Wformat] > > Cc: Rusty Russell > Cc: virtualizat...@lists.linux-foundation.org > Signed-off-by: Lee Jones > --- > drivers/virtio/virtio_mmio.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c > index 6b1b7e1..077e9ca 100644 > --- a/drivers/virtio/virtio_mmio.c > +++ b/drivers/virtio/virtio_mmio.c > @@ -531,7 +531,7 @@ static int vm_cmdline_set(const char *device, > resources[0].end = memparse(device, ) - 1; > > processed = sscanf(str, "@%lli:%u%n:%d%n", > - , [1].start, , > + , (unsigned int *)[1].start, , > _cmdline_id, ); This suppresses a valid warning, leaving our code no less wrong than before. But now it's silently wrong! Do you want to try again? Cheers, 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: [PATCH v2] MODSIGN: Add modules_sign make target
Josh Boyer writes: > On Fri, Nov 02, 2012 at 01:49:14PM +1030, Rusty Russell wrote: >> My comment was more that this relies on eu-strip, because we always >> sign modules on installation, so you need eu-strip to *unsign* them >> (strip won't do it, BTW). > > Really? Which version of binutils are you using? The strip I have here > seems to have no qualms about stripping off the signatures: ... > So that makes me very curious. Hmm, Works For Me too. Searches for evidence... Nope, I'm completely off-base here. I wrote the exact opposite last year: On Sat, 10 Dec 2011 17:31:15 +1030 I wrote: > But objdump doesn't care about appended data. > objcopy and strip will remove it, of course, but without complaining. Sorry for the noise, 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: [PATCH] utilize _Static_assert() for BUILD_BUG_ON() when the compiler supports it
Jan Beulich writes:
> This makes the resulting diagnostics quite a bit more useful.
>
> Signed-off-by: Jan Beulich
Nice. I'm a bit disappointed we can't just treat _Static_assert() as
void, like:
#define BUILD_BUG_ON_ZERO(e) (_Static_assert(!(e), "!(" #e ")"), 0)
> @@ -54,6 +61,15 @@ struct pt_regs;
> */
> #ifndef __OPTIMIZE__
> #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
> +#elif __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3)
> +#define __build_bug_on_failed(n) __build_bug_on_##n##_failed
> +#define _BUILD_BUG_ON(n, condition) \
> + do {\
> + extern void __compiletime_error(#condition) \
> + __build_bug_on_failed(n)(void); \
> + if (condition) __build_bug_on_failed(n)(); \
> + } while(0)
> +#define BUILD_BUG_ON(condition...) _BUILD_BUG_ON(__COUNTER__, ##condition)
> #else
> extern int __build_bug_on_failed;
> #define BUILD_BUG_ON(condition) \
Why does this depend on gcc version? Looks like residue from an attempt
to use _Static_assert here?
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: [PATCH v2] epoll: Support for disabling items, and a self-test app.
On 10/27/2012 05:52 AM, Matt Helsley wrote: > On Thu, Oct 25, 2012 at 12:23:24PM +0200, Michael Kerrisk (man-pages) wrote: >> Hi Pat, >> >> I suppose that I have a concern that goes in the other direction. Is there not some other solution possible that doesn't require the use of EPOLLONESHOT? It seems overly restrictive to require that the caller must employ this flag, and imposes the burden that the caller must re-enable monitoring after each event. Does a solution like the following (with no requirement for EPOLLONESHOT) work? 0. Implement an epoll_ctl() operation EPOLL_CTL_XXX where the name XXX might be chosen based on the decision in 4(a). 1. EPOLL_CTL_XXX employs a private flag, EPOLLUSED, in the per-fd events mask in the ready list. By default, that flag is off. 2. epoll_wait() always clears the EPOLLUSED flag if a file descriptor is found to be ready. 3. If an epoll_ctl(EPOLL_CTL_XXX) discovers that the EPOLLUSED flag is NOT set, then a) it sets the EPOLLUSED flag b) It disables I/O events (as per EPOLL_CTL_DISABLE) (I'm not 100% sure if this is necesary). c) it returns EBUSY to the caller 4. If an epoll_ctl(EPOLL_CTL_XXX) discovers that the EPOLLUSED flag IS set, then it a) either deletes the fd or disables events for the fd (the choice here is a matter of design taste, I think; deletion has the virtue of simplicity; disabling provides the option to re-enable the fd later, if desired) b) returns 0 to the caller. All of the above with suitable locking around the user-space cache. Cheers, Michael >>> >>> >>> I don't believe that proposal will solve the problem. Consider the case >>> where a worker thread has just executed epoll_wait and is about to execute >>> the next line of code (which will access the data associated with the fd >>> receiving the event). If the deletion thread manages to call >>> epoll_ctl(EPOLL_CTL_XXX) for that fd twice in a row before the worker thread >>> is able to execute the next statement, then the deletion thread will >>> mistakenly conclude that it is safe to destroy the data that the worker >>> thread is about to access. >> >> Okay -- I had the idea there might be a hole in my proposal ;-). >> >> By the way, have you been reading the comments in the two LWN articles >> on EPOLL_CTL_DISABLE? >> https://lwn.net/Articles/520012/ >> http://lwn.net/SubscriberLink/520198/fd81ba0ecb1858a2/ >> >> There's some interesting proposals there--some suggesting that an >> entirely user-space solution might be possible. I haven't looked >> deeply into the ideas though. > > Yeah, I became quite interested so I wrote a crude epoll + urcu test. I still think we could use this idea in kernel, actually implement the rcu lock mechanism inside epoll_wait(). Since the epoll_wait() invoked by different threads, we could easily track the status of epi usage by a thread, and DISABLE should return 0 only when all the threads who referenced the epi invoked epoll_wait() again. It's module would like: delete thread: 1. set fd stop flag(user flag) //tell worker don't use fd any more 2. epoll_ctl(DISABLE) 3. if return BUSY, try later //rcu_syn 3. else, do delete worker thread: 1. invoke epoll_wait() 2. if fd stop flag set, epoll_wait() again 3. else, do job on fd in epoll_wait(): 1. epi event arrived 2. if epi stop flag set(kernel flag), don't return it 3. else, record epi usage in current thread and add it's ref count //rcu_lock 4. dec the epi ref count when thread invoke epoll_wait() again //rcu_unlock in epoll_ctl(DISABLE): 1. set epi stop flag(kernel flag) 2. if epi ref count is not 0, return BUSY Please let me know if I miss some thing ;-) Regards, Michael Wang > Since it's RCU review to ensure I've not made any serious mistakes could > be quite helpful: > > #define _LGPL_SOURCE 1 > #define _GNU_SOURCE 1 > > #include > #include > #include > #include > #include > #include > #include > #include > > #include > > /* > * Locking Voodoo: > * > * The globabls prefixed by _ require special care because they will be > * accessed from multiple threads. > * > * The precise locking scheme we use varies whether READERS_USE_MUTEX is > defined > * When we're using userspace RCU the mutex only gets acquired for writes > * to _-prefixed globals. Reads are done inside RCU read side critical > * sections. > * Otherwise the epmutex covers reads and writes to them all and the test > * is not very scalable. > */ > static pthread_mutex_t
Re: [PATCH] crash dump: don't delete non-E820_RAM during init
On 11/05/2012 03:57 AM, Zhang, Jun wrote: > Hello, Anvin > 1) use "memmap=exactmap", which remove all ranges include ram and non-ram > range. So my first patch reserve the non-ram range. > 2)don't use " memmap=exactmap ", so it reserve all ranges. But we only need > non-ram, so we need kernel to remove RAM, just as my second patch. Sorry, you have completely lost me now. You seem to be contradicting yourself from one message to another. -hpa -- 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] crash dump: don't delete non-E820_RAM during init
Hello, Anvin
1) use "memmap=exactmap", which remove all ranges include ram and non-ram
range. So my first patch reserve the non-ram range.
2)don't use " memmap=exactmap ", so it reserve all ranges. But we only need
non-ram, so we need kernel to remove RAM, just as my second patch.
Best Regards!
Jun Zhang
Inet: 8821-4273
Dir.Tel: 86-21-6116-4273
Email: jun.zh...@intel.com
-Original Message-
From: H. Peter Anvin [mailto:h...@zytor.com]
Sent: Monday, November 05, 2012 10:39 AM
To: Zhang, Jun
Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew Morton; Fleming,
Matt; Paul Gortmaker; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] crash dump: don't delete non-E820_RAM during init
On 11/05/2012 02:37 AM, Zhang, Jun wrote:
> Hello, Gortmaker
> I will modify my subject. Thanks!
>
> Hello, Anvin
> from our three options, I think third option is better. But in 3) option,
> there are two choose, 3.1) is like memmap=REMOVERAM, 3.2) is
> memmap=CRASHKDUMP.
> In 3.1) we maybe need ifdef/endif within the { } of the function (like
> exactmap).
> In 3.2) we can remove the ifdef/endif.
> Which one is the better? Maybe you have a better solution, please share it.
> Thanks!
>
> Next is our three option.
> 1) my patch.
> 2) modify kexec, only pass two parameters -- memmap=544K@64K
> memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM
> range.
> 3) add extra optional, 3.1) like memmap=REMOVERAM
>3.2) like memmap=CRASHKDUMP
>
Again, 2 would be better because it is a localized change to kexec. If that
works I don't see why there is any reason to change anything else.
-hpa
Re: [PATCH 0/8] drop if around WARN_ON
On Sun, Nov 4, 2012 at 11:16 AM, Julia Lawall wrote: > I didn't change any cases where the if test contains a function call. The > current definitions of WARN_ON seem to always evaluate the condition > expression, but I was worried that that might not always be the case. And > calling a function (the ones I remember were some kinds of print functions) > seems like something one might not want buried in the argument of a > debugging macro. Makes sense. > WARN_ON_SMP is just WARN_ON if CONFIG_SMP is true, but it is just 0 > otherwise. So in that case it seems important to check that one is not > throwing away something important. Yup, we just need to make sure that the expression being evaluated doesn't have side-effects. > I remember working on the BUG_ON case several years ago, and other people > worked on it too, but I guess some are still there... The current > definitions of BUG_ON seem to keep the condition, but there are quite a few > specialized definitions, so someone at some point might make a version that > does not have that property. It makes sense to keep an eye for such things when converting code. I also don't think we'll get to see a version of BUG_ON which doesn't evaluate the expression since the kernel already has more than enough BUG_ONs that assume the expression will be evaluated: BUG_ON(HYPERVISOR_callback_op(CALLBACKOP_register, )); BUG_ON(gpiochip_add(_gpio_chip)); BUG_ON(clocksource_register_hz(_clocksource, CLOCK_TICK_RATE)); BUG_ON(gpio_request(ZOOM2_HEADSET_MUX_GPIO, "hs_mux") < 0); And so on, so we're probably safe converting to BUG_ON even if the condition is a function, as long as it doesn't create a long and complicated BUG_ON() ofcourse. Thanks, Sasha -- 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] crash dump: don't delete non-E820_RAM during init
On 11/05/2012 02:37 AM, Zhang, Jun wrote:
> Hello, Gortmaker
> I will modify my subject. Thanks!
>
> Hello, Anvin
> from our three options, I think third option is better. But in 3) option,
> there are two choose, 3.1) is like memmap=REMOVERAM, 3.2) is
> memmap=CRASHKDUMP.
> In 3.1) we maybe need ifdef/endif within the { } of the function (like
> exactmap).
> In 3.2) we can remove the ifdef/endif.
> Which one is the better? Maybe you have a better solution, please share it.
> Thanks!
>
> Next is our three option.
> 1) my patch.
> 2) modify kexec, only pass two parameters -- memmap=544K@64K
> memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM
> range.
> 3) add extra optional, 3.1) like memmap=REMOVERAM
>3.2) like memmap=CRASHKDUMP
>
Again, 2 would be better because it is a localized change to kexec. If
that works I don't see why there is any reason to change anything else.
-hpa
--
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: VFS hot tracking: How to calculate data temperature?
On Sat, Nov 3, 2012 at 5:27 AM, Mingming.cao wrote: > On Fri, 2012-11-02 at 14:38 +0800, Zhi Yong Wu wrote: >> Here also has another question. >> >> How to save the file temperature among the umount to be able to >> preserve the file tempreture after reboot? >> >> This above is the requirement from DB product. >> I thought that we can save file temperature in its inode struct, that >> is, add one new field in struct inode, then this info will be written >> to disk with inode. >> >> Any comments or ideas are appreciated, thanks. >> >> > > Maybe could save the last file temperature with extended attributes. It seems that only ext4 has the concept of extended attributes. > Just save the per-inode temperature only for now. > > Mingming >> On Fri, Nov 2, 2012 at 12:04 PM, Zhi Yong Wu wrote: >> > HI, guys >> > >> >VFS hot tracking currently show result as below, and it is very >> > strange and not nice. >> > >> > inode #279, reads 0, writes 1, avg read time 18446744073709551615, >> > avg write time 5251566408153596, temp 109 >> > >> > Do anyone know if there is one simpler but effective way to calculate >> > data temperature? >> > >> > -- >> > Regards, >> > >> > Zhi Yong Wu >> >> >> > > > -- Regards, Zhi Yong Wu -- 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: [v2 PATCH 1/2] Add new uio device for dynamic memory allocation
Hi Geert, On 2012/11/04 22:20, Geert Uytterhoeven wrote: > On Tue, Sep 25, 2012 at 8:09 AM, Damian Hobson-Garcia > wrote: >> are holding the device file open, the address returned to userspace is >> DMA_ERROR_CODE. > > Only a small subset of the architectures > (arm/ia64/microblaze/openrisc/powerpc/sparc/x86) > seem to define DMA_ERROR_CODE, causing everywhere else: > > drivers/uio/uio_dmem_genirq.c: In function ‘uio_dmem_genirq_release’: > drivers/uio/uio_dmem_genirq.c:95: error: ‘DMA_ERROR_CODE’ undeclared > (first use in this function) > drivers/uio/uio_dmem_genirq.c:95: error: (Each undeclared identifier > is reported only once > drivers/uio/uio_dmem_genirq.c:95: error: for each function it appears in.) > drivers/uio/uio_dmem_genirq.c: In function ‘uio_dmem_genirq_probe’: > drivers/uio/uio_dmem_genirq.c:238: error: ‘DMA_ERROR_CODE’ undeclared > (first use in this function) > make[1]: *** [drivers/uio/uio_dmem_genirq.o] Error 1 > make: *** [drivers/uio/] Error 2 > > (e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/7462173/) > > Furthermore, none of them define it in , so DMA_ERROR_CODE is not > part of the userspace API (yet), while it is architecture-specific (some use > 0, > others ~0). > Good points, thank you. In that case, does fixing the value to something like ~0 sound like a better (more portable) solution? Damian -- Damian Hobson-Garcia IGEL Co.,Ltd http://www.igel.co.jp -- 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: VFS hot tracking: How to calculate data temperature?
On Sat, Nov 3, 2012 at 4:10 AM, Darrick J. Wong wrote: > On Fri, Nov 02, 2012 at 04:41:09PM +0800, Zheng Liu wrote: >> On Fri, Nov 02, 2012 at 02:38:29PM +0800, Zhi Yong Wu wrote: >> > Here also has another question. >> > >> > How to save the file temperature among the umount to be able to >> > preserve the file tempreture after reboot? >> > >> > This above is the requirement from DB product. >> > I thought that we can save file temperature in its inode struct, that >> > is, add one new field in struct inode, then this info will be written >> > to disk with inode. >> > >> > Any comments or ideas are appreciated, thanks. >> >> Hi Zhiyong, >> >> I think that we might define a callback function. If a filesystem wants >> to save these data, it can implement a function to save them. The >> filesystem can decide whether adding it or not by themselves. >> >> BTW, actually I don't really care about how to save these data because I >> only want to observe which file is accessed in real time, which is very >> useful for me to track a problem in our product system. > > I _think_ the vfs quota code simply asks the filesystem for a special > inode where it save the quota data in whatever (FS-agnostic) format it wants. > Have you considered something like that? No, but it is one good hint for my issue. thanks. > > (Or, maybe everyone secretly hates doing that? Secret files, yaaay...) ah, do you think of doing that? > > --D >> >> Regards, >> Zheng >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Zhi Yong Wu -- 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: Wakeup latency measured with SCHED_TRACER depends on HZ
On Fri, Nov 02, 2012 at 03:29:50PM +0100, Stanislav Meduna wrote:
> On 31.10.2012 22:41, Stanislav Meduna wrote:
>
> > on an embedded platform using a Freescale i.MX28 ARM processor
> > I am experiencing a strange phenomenon - the latencies reported
> > are dependent of HZ
>
> OK, the problem is that the MXS platform does not setup
> the scheduler clock so the scheduler only sees the HZ one.
>
> The patch in attach fixes this. I can only test the MX28 part -
> I don't have any timrot_is_v1() (MX23) hardware and I don't
> know whether a source that wraps after ~2 seconds is OK at all.
>From my quick testing on imx23 with printk timestamp, it's not OK,
so we may need to leave imx23 out there.
>
> Please Cc: when replying, I am not subscribed to linux-kernel
linux-arm-kernel is better than linux-kernel for this patch.
> (only to linux-rt-users).
>
> Regards
> --
> Stano
>
> From ddeed3c83d48e8ce33b36bd964572756354e7feb Mon Sep 17 00:00:00 2001
> From: Stanislav Meduna
> Date: Fri, 2 Nov 2012 15:00:44 +0100
> Subject: [PATCH] Setup scheduler clock for MXS
>
Generally, empty commit log is not welcomed. Also, please add prefix
"ARM: mxs: " to patch subject.
> ---
> arch/arm/mach-mxs/timer.c | 19 +++
> 1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-mxs/timer.c b/arch/arm/mach-mxs/timer.c
> index 564a632..0ab86a2 100644
> --- a/arch/arm/mach-mxs/timer.c
> +++ b/arch/arm/mach-mxs/timer.c
> @@ -26,6 +26,7 @@
> #include
>
> #include
> +#include
> #include
> #include
>
> @@ -243,6 +244,16 @@ static int __init mxs_clocksource_init(struct clk
> *timer_clk)
> return 0;
> }
>
> +static u32 notrace mxs_read_sched_clock_v1(void)
> +{
> + return timrotv1_get_cycles(_mxs);
> +}
> +
> +static u32 notrace mxs_read_sched_clock_v2(void)
> +{
> + return ~readl_relaxed(mxs_timrot_base + HW_TIMROT_RUNNING_COUNTn(1));
> +}
> +
> void __init mxs_timer_init(struct clk *timer_clk, int irq)
> {
> clk_prepare_enable(timer_clk);
> @@ -285,6 +296,14 @@ void __init mxs_timer_init(struct clk *timer_clk, int
> irq)
> mxs_clocksource_init(timer_clk);
> mxs_clockevent_init(timer_clk);
>
> + /* Register scheduler clocksource */
> + if (timrot_is_v1())
> + setup_sched_clock(mxs_read_sched_clock_v1,
> + 16, clk_get_rate(timer_clk));
> + else
> + setup_sched_clock(mxs_read_sched_clock_v2,
> + 32, clk_get_rate(timer_clk));
> +
It should better be done in mxs_clocksource_init().
Shawn
> /* Make irqs happen */
> setup_irq(irq, _timer_irq);
> }
> --
> 1.7.0.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: VFS hot tracking: How to calculate data temperature?
On Fri, Nov 2, 2012 at 4:41 PM, Zheng Liu wrote: > On Fri, Nov 02, 2012 at 02:38:29PM +0800, Zhi Yong Wu wrote: >> Here also has another question. >> >> How to save the file temperature among the umount to be able to >> preserve the file tempreture after reboot? >> >> This above is the requirement from DB product. >> I thought that we can save file temperature in its inode struct, that >> is, add one new field in struct inode, then this info will be written >> to disk with inode. >> >> Any comments or ideas are appreciated, thanks. > > Hi Zhiyong, > > I think that we might define a callback function. If a filesystem wants > to save these data, it can implement a function to save them. The > filesystem can decide whether adding it or not by themselves. Great idea, temperature saving function is maybe very specific to FS. But i am wondering if we can find one generic way to save temperature info at first. > > BTW, actually I don't really care about how to save these data because I > only want to observe which file is accessed in real time, which is very > useful for me to track a problem in our product system. heh, but other guys or products care about this. > > Regards, > Zheng -- Regards, Zhi Yong Wu -- 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: mm: NULL ptr deref in anon_vma_interval_tree_verify
On Sat, Nov 3, 2012 at 11:51 AM, Sasha Levin wrote: > Ping? > > On Thu, Oct 25, 2012 at 4:26 PM, Sasha Levin wrote: >> On 10/18/2012 06:46 PM, Sasha Levin wrote: >>> Hi all, >>> >>> While fuzzing with trinity inside a KVM tools (lkvm) guest, on today's >>> linux-next kernel, >>> I saw the following: >>> >>> [ 1857.278176] BUG: unable to handle kernel NULL pointer dereference at >>> 0090 >>> [ 1857.283725] IP: [] >>> anon_vma_interval_tree_verify+0xf/0xa0 >>> [ 1857.283725] PGD 6e19e067 PUD 6e19f067 PMD 0 >>> [ 1857.283725] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC >>> [ 1857.283725] Dumping ftrace buffer: >>> [ 1857.283725](ftrace buffer empty) >>> [ 1857.283725] CPU 2 >>> [ 1857.283725] Pid: 15637, comm: trinity-child18 Tainted: GW >>> 3.7.0-rc1-next-20121018-sasha-2-g60a870d-dirty #61 >>> [ 1857.283725] RIP: 0010:[] [] >>> anon_vma_interval_tree_verify+0xf/0xa0 >>> [ 1857.283725] RSP: 0018:88007df0fce8 EFLAGS: 00010296 >>> [ 1857.283725] RAX: 880089db1000 RBX: 880089db0ff0 RCX: >>> 8800869e6928 >>> [ 1857.283725] RDX: RSI: 880089db1008 RDI: >>> 880089db0ff0 >>> [ 1857.283725] RBP: 88007df0fcf8 R08: 88006427d508 R09: >>> 88012bb95f20 >>> [ 1857.283725] R10: 0001 R11: 8800c8525c60 R12: >>> 88006e199370 >>> [ 1857.283725] R13: 88006e199300 R14: R15: >>> 880089db1000 >>> [ 1857.283725] FS: 7f322fd4c700() GS:88004d60() >>> knlGS: >>> [ 1857.283725] CS: 0010 DS: ES: CR0: 80050033 >>> [ 1857.283725] CR2: 0090 CR3: 6e19d000 CR4: >>> 000406e0 >>> [ 1857.283725] DR0: DR1: DR2: >>> >>> [ 1857.283725] DR3: DR6: 0ff0 DR7: >>> 0400 >>> [ 1857.283725] Process trinity-child18 (pid: 15637, threadinfo >>> 88007df0e000, task 88007ac8) >>> [ 1857.283725] Stack: >>> [ 1857.283725] 88007df0fd38 880089db0ff0 88007df0fd48 >>> 81233b58 >>> [ 1857.283725] 88007df0fd38 880089db1000 80d0 >>> 880089db1000 >>> [ 1857.283725] 88012bb95f20 885d97c8 885d97d8 >>> 880089db1000 >>> [ 1857.283725] Call Trace: >>> [ 1857.283725] [] validate_mm+0x58/0x1e0 >>> [ 1857.283725] [] vma_link+0x94/0xe0 >>> [ 1857.283725] [] ? _raw_spin_unlock_irqrestore+0x84/0xb0 >>> [ 1857.283725] [] mmap_region+0x3f5/0x5c0 >>> [ 1857.283725] [] do_mmap_pgoff+0x2b7/0x330 >>> [ 1857.283725] [] ? vm_mmap_pgoff+0x61/0xa0 >>> [ 1857.283725] [] vm_mmap_pgoff+0x7a/0xa0 >>> [ 1857.283725] [] sys_mmap_pgoff+0x182/0x1a0 >>> [ 1857.283725] [] ? syscall_trace_enter+0x20/0x2e0 >>> [ 1857.283725] [] sys_mmap+0x1d/0x20 >>> [ 1857.283725] [] tracesys+0xe1/0xe6 >>> [ 1857.283725] Code: 48 39 ce 77 9e f3 c3 0f 1f 44 00 00 31 c0 c3 66 66 66 >>> 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 53 48 89 fb >>> 48 83 ec 08 48 8b 17 <48> 8b 8a 90 00 00 00 48 39 4f 40 74 34 80 3d a6 82 >>> 5b 04 00 75 >>> [ 1857.283725] RIP [] >>> anon_vma_interval_tree_verify+0xf/0xa0 >>> [ 1857.283725] RSP >>> [ 1857.283725] CR2: 0090 >>> [ 1858.611277] ---[ end trace b51cc425e9b07fc0 ]--- >>> >>> The obvious part is that anon_vma_interval_tree_verify() got called with >>> node == NULL, but when >>> looking at the caller: >>> >>> list_for_each_entry(avc, >anon_vma_chain, same_vma) >>> anon_vma_interval_tree_verify(avc); >>> >>> How it got called with said NULL becomes less obvious. >> >> I've hit a similar one with today's -next. It isn't exactly the same, but >> I suspect it's the same issue. >> >> [ 1523.657950] BUG: unable to handle kernel paging request at >> fff0 >> [ 1523.660022] IP: [] >> anon_vma_interval_tree_verify+0xc/0xa0 >> [ 1523.660022] PGD 4e28067 PUD 4e29067 PMD 0 >> [ 1523.675725] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC >> [ 1523.750066] CPU 0 >> [ 1523.750066] Pid: 9050, comm: trinity-child64 Tainted: GW >> 3.7.0-rc2-next-20121025-sasha-1-g673f98e-dirty #77 >> [ 1523.750066] RIP: 0010:[] [] >> anon_vma_interval_tree_verify+0xc/0xa0 >> [ 1523.750066] RSP: 0018:880045f81d48 EFLAGS: 00010296 >> [ 1523.750066] RAX: RBX: fff0 RCX: >> >> [ 1523.750066] RDX: RSI: 0001 RDI: >> fff0 >> [ 1523.750066] RBP: 880045f81d58 R08: R09: >> 0f14 >> [ 1523.750066] R10: 0f12 R11: R12: >> 8800096c8d70 >> [ 1523.750066] R13: 8800096c8d00 R14: R15: >> 8800095b45e0 >> [ 1523.750066] FS: 7f7a923f3700() GS:88001360() >> knlGS: >> [ 1523.750066] CS: 0010 DS: ES: CR0: 80050033 >> [ 1523.750066] CR2: fff0 CR3: 0969d000 CR4: >> 000406f0 >> [
Re: [BUGFIX] PM: Fix active child counting when disabled and forbidden
On Mon, 5 Nov 2012, Huang Ying wrote: > In current runtime PM implementation, the active child count of the > parent device may be decreased if the runtime PM of the child device > is disabled and forbidden. For example, to unbind a PCI driver with a > PCI device, the following code path is possible: > > pci_device_remove > pm_runtime_set_suspended > __pm_runtime_set_status > atomic_add_unless(>power.child_count, -1, 0) > > That is, the parent device may be suspended, even if the runtime PM of > child device is forbidden to be suspended. This violate the rule that > parent is allowed to be suspended only after all its children are > suspended, and may cause issue. This doesn't sound like a correct description of the situation. The rule is not violated. After pm_runtime_set_suspended runs, the child _is_ suspended. Thus there's no reason not to allow the parent to be suspended. The problem -- if there really is one -- is that a driver can put a device into the suspended state by calling pm_runtime_disable followed by pm_runtime_set_suspended, even if the usage count is > 0. I'm not so sure this should count as a problem. Generally devices aren't disabled for runtime PM unless something is wrong. Under those circumstances, the meaning of pm_runtime_forbid isn't very well defined. Alan Stern -- 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] crash dump: don't delete non-E820_RAM during init
Hello, Gortmaker
I will modify my subject. Thanks!
Hello, Anvin
from our three options, I think third option is better. But in 3) option, there
are two choose, 3.1) is like memmap=REMOVERAM, 3.2) is memmap=CRASHKDUMP.
In 3.1) we maybe need ifdef/endif within the { } of the function (like
exactmap).
In 3.2) we can remove the ifdef/endif.
Which one is the better? Maybe you have a better solution, please share it.
Thanks!
Next is our three option.
1) my patch.
2) modify kexec, only pass two parameters -- memmap=544K@64K
memmap=64964K@32768K, in kernel setup_memory_map, we can remove RAM
range.
3) add extra optional, 3.1) like memmap=REMOVERAM
3.2) like memmap=CRASHKDUMP
Best Regards!
Jun Zhang
Inet: 8821-4273
Dir.Tel: 86-21-6116-4273
Email: jun.zh...@intel.com
-Original Message-
From: H. Peter Anvin [mailto:h...@zytor.com]
Sent: Saturday, November 03, 2012 12:38 AM
To: Zhang, Jun
Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew Morton; Fleming,
Matt; Paul Gortmaker; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] To crash dump, we need keep other memory type except
E820_RAM, because other type come from BIOS or firmware is used by other
code(for example: PCI_MMCONFIG).
On 11/01/2012 01:49 AM, Zhang, Jun wrote:
> Hello, Anvin
>
> Thank for your advice.
>
> Hello, All
>
> the next patch is made by 2), please review it. Thanks!
>
No, it is not.
You are still modifying the behavior of the kernel depending on
CONFIG_CRASH_DUMP.
CONFIG_CRASH_DUMP doesn't mean "we are doing a crash dump". It means "it is
possible to use this kernel to do a crash dump".
Either you are using standard kernel parameters in a standard way which is what
option 2 was supposed to be -- it should require no kernel changes! -- or you
have to put something in a code path specific to a crash dump.
-hpa
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 V2 1/3] mmc: esdhc: enable polling to detect card by itself
On Fri, Nov 02, 2012 at 08:37:41PM +0800, yongd wrote: > I got it. So how do you think of such below partition/reorganization? > It looks fine to me for imx. > Patch-1: > For sdhci-esdhc-imx.c, only add MMC_CAP_NEEDS_POLL for ESDHC_CD_NONE. With > that > improper logic of sdhci_add_host(), this is redundant, but shall be better > than something unpleasant you mentioned. > > Patch-2: > For sdhci-s3c.c, do exactly the same thing as Patch-1. > > Patch-3: > For sdhci.c, remove that improper logic of sdhci_add_host(). > > Patch-4: > For sdhci-esdhc-imx.c, set SDHCI_QUIRK_BROKEN_CARD_DETECTION for > ESDHC_CD_GPIO. > > Patch-5: > For sdhci-s3c.c, broaden SDHCI_QUIRK_BROKEN_CARD_DETECTION range for all > detection > types except S3C_SDHCI_CD_INTERNAL. > Yes, not equal as before. But you just remind me of one more improper place > in our current sdhci.c. > Let's review those lines in sdhci_request() which are added by Anton long > long ago in commit > 68d1fb7e229c6f95be4fbbe3eb46b24e41184924(sdhci: Add support for > card-detection polling), > > /* If polling, assume that the card is always present. */ > if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) > present = true; > else > present = sdhci_readl(host, SDHCI_PRESENT_STATE) & > SDHCI_CARD_PRESENT; > > Here before sending command, if we can confirm the card dose not exist, we > will return quickly without > sending this command.This is a good optimization. But if polling, we can't do > such checking, so we can > only assume the card is always present. > Here is another improper example of using SDHCI_QUIRK_BROKEN_CARD_DETECTION. > Exactly the same as > sdhci_add_host(), it thinks only polling and host internal card detection > methods exist. > Maybe we can determine whether and how we can do such card-existence-checking > optimization based on our > detection type directly rather than an indirect flag which should have its > own pure meaning. But Let's > do such similar further improvement in future since currently with my patch > of setting > SDHCI_QUIRK_BROKEN_CARD_DETECTION for ESDHC_CD_GPIO, functionality is OK as > before. How do u think? > I'm not sure it will function same as before. When I was testing your v2 series, I can not see card removal message with removing card, but can see it show up together with the next card inserting message. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the thermal tree with Linus' tree
On Mon, 2012-11-05 at 11:46 +1100, Stephen Rothwell wrote:
> Hi Zhang,
>
> Today's linux-next merge of the thermal tree got a conflict in
> drivers/thermal/rcar_thermal.c between commit 608f62b996c6 ("thermal:
> solve compilation errors in rcar_thermal") from Linus' tree and commit
> ebbf0f11e7b4 ("Thermal: Pass zone parameters as argument to
> tzd_register") from the thermal tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
the fix looks good to me, Thanks!
-rui
--
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/
[BUGFIX] PM: Fix active child counting when disabled and forbidden
In current runtime PM implementation, the active child count of the
parent device may be decreased if the runtime PM of the child device
is disabled and forbidden. For example, to unbind a PCI driver with a
PCI device, the following code path is possible:
pci_device_remove
pm_runtime_set_suspended
__pm_runtime_set_status
atomic_add_unless(>power.child_count, -1, 0)
That is, the parent device may be suspended, even if the runtime PM of
child device is forbidden to be suspended. This violate the rule that
parent is allowed to be suspended only after all its children are
suspended, and may cause issue.
This issue is fixed via checking the usage count of the child device
because if the runtime PM of the child device is forbidden, the
usage_count of the child device will be non-zero.
Signed-off-by: Huang Ying
---
drivers/base/power/runtime.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -916,7 +916,7 @@ int __pm_runtime_set_status(struct devic
if (status == RPM_SUSPENDED) {
/* It always is possible to set the status to 'suspended'. */
- if (parent) {
+ if (parent && atomic_read(>power.usage_count) == 0) {
atomic_add_unless(>power.child_count, -1, 0);
notify_parent = !parent->power.ignore_children;
}
--
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 RFT RESEND linux-next] hexagon: dma-mapping: support debug_dma_mapping_error
On Fri, Nov 02, 2012 at 10:48:21AM -0600, Shuah Khan wrote:
> On Fri, 2012-10-26 at 09:43 -0600, Shuah Khan wrote:
> > Add support for debug_dma_mapping_error() call to avoid warning from
> > debug_dma_unmap() interface when it checks for mapping error checked
> > status. Without this patch, device driver failed to check map error
> > warning is generated.
> >
> > Signed-off-by: Shuah Khan
> > ---
> > arch/hexagon/include/asm/dma-mapping.h |1 +
> > 1 file changed, 1 insertion(+)
>
> Would you like se this patch go through arch tree or linux-next? Please
> let me know your preference.
>
> -- Shuah
> >
> > diff --git a/arch/hexagon/include/asm/dma-mapping.h
> > b/arch/hexagon/include/asm/dma-mapping.h
> > index 85e9935..1957c4c 100644
> > --- a/arch/hexagon/include/asm/dma-mapping.h
> > +++ b/arch/hexagon/include/asm/dma-mapping.h
> > @@ -65,6 +65,7 @@ static inline int dma_mapping_error(struct device *dev,
> > dma_addr_t dma_addr)
> > {
> > struct dma_map_ops *dma_ops = get_dma_ops(dev);
> >
> > + debug_dma_mapping_error(dev, dma_addr);
> > if (dma_ops->mapping_error)
> > return dma_ops->mapping_error(dev, dma_addr);
> >
>
>
This looks fine; I'm OK with this going through linux-next. Thanks!
Acked-by: Richard Kuo
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the 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/
Re: [rfc net-next v6 2/3] virtio_net: multiqueue support
Jason Wang writes:
> +struct virtnet_info {
> + u16 num_queue_pairs;/* # of RX/TX vq pairs */
> + u16 total_queue_pairs;
> +
> + struct send_queue *sq;
> + struct receive_queue *rq;
> + struct virtqueue *cvq;
> +
> + struct virtio_device *vdev;
> + struct net_device *dev;
> + unsigned int status;
status seems unused?
> +static const struct ethtool_ops virtnet_ethtool_ops;
Strange hoist, but I can't tell from the patch if this is necessary.
Assume it is.
> +static inline int vq2txq(struct virtqueue *vq)
> +{
> + int index = virtqueue_get_queue_index(vq);
> + return index == 1 ? 0 : (index - 3) / 2;
> +}
> +
> +static inline int txq2vq(int txq)
> +{
> + return txq ? 2 * txq + 3 : 1;
> +}
> +
> +static inline int vq2rxq(struct virtqueue *vq)
> +{
> + int index = virtqueue_get_queue_index(vq);
> + return index ? (index - 2) / 2 : 0;
> +}
> +
> +static inline int rxq2vq(int rxq)
> +{
> + return rxq ? 2 * rxq + 2 : 0;
> +}
> +
> static inline struct skb_vnet_hdr *skb_vnet_hdr(struct sk_buff *skb)
I know skb_vnet_hdr() does it, but I generally dislike inline in C
files; gcc is generally smart enough these days, and inline suppresses
unused function warnings.
I guess these mappings have to work even when we're switching from mq to
single queue mode; otherwise we could simplify them using a 'bool mq'
flag.
> +static int virtnet_set_queues(struct virtnet_info *vi)
> +{
> + struct scatterlist sg;
> + struct virtio_net_ctrl_steering s;
> + struct net_device *dev = vi->dev;
> +
> + if (vi->num_queue_pairs == 1) {
> + s.current_steering_rule = VIRTIO_NET_CTRL_STEERING_SINGLE;
> + s.current_steering_param = 1;
> + } else {
> + s.current_steering_rule =
> + VIRTIO_NET_CTRL_STEERING_RX_FOLLOWS_TX;
> + s.current_steering_param = vi->num_queue_pairs;
> + }
(BTW, VIRTIO_NET_CTRL_STEERING_RX_FOLLOWS_TX etc not defined anywhere?)
Hmm, it's not clear that anything other than RX_FOLLOWS_TX will ever
make sense, so this is really just turning mq on and off.
Unfortunately, we can't turn feature bits on and off after startup, so
if we want this level of control (and I think we do), there does need to
be a mechanism.
Michael? I'd prefer this to be further simplfied, to just
disable/enable. We can extend it later, but for now the second
parameter is redundant, ie.:
struct virtio_net_ctrl_steering {
u8 mode; /* 0 == off, 1 == on */
} __attribute__((packed));
> @@ -924,11 +1032,10 @@ static void virtnet_get_ringparam(struct net_device
> *dev,
> {
> struct virtnet_info *vi = netdev_priv(dev);
>
> - ring->rx_max_pending = virtqueue_get_vring_size(vi->rvq);
> - ring->tx_max_pending = virtqueue_get_vring_size(vi->svq);
> + ring->rx_max_pending = virtqueue_get_vring_size(vi->rq[0].vq);
> + ring->tx_max_pending = virtqueue_get_vring_size(vi->sq[0].vq);
> ring->rx_pending = ring->rx_max_pending;
> ring->tx_pending = ring->tx_max_pending;
> -
> }
This assumes all vqs are the same size. I think this should probably
check: for mq mode, use the first vq, otherewise use the 0th.
For bonus points, check this assertion at probe time.
> + /*
> + * We expect 1 RX virtqueue followed by 1 TX virtqueue, followd by
> + * possible control virtqueue, followed by 1 reserved vq, followed
> + * by RX/TX queue pairs used in multiqueue mode.
> + */
> + if (vi->total_queue_pairs == 1)
> + total_vqs = 2 + virtio_has_feature(vi->vdev,
> +VIRTIO_NET_F_CTRL_VQ);
> + else
> + total_vqs = 2 * vi->total_queue_pairs + 2;
What's the allergy to odd numbers? Why the reserved queue?
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> + vi->has_cvq = true;
> +
> + /* Use single tx/rx queue pair as default */
> + vi->num_queue_pairs = 1;
> + vi->total_queue_pairs = num_queue_pairs;
> +
> + /* Allocate/initialize the rx/tx queues, and invoke find_vqs */
> + err = virtnet_setup_vqs(vi);
> if (err)
> goto free_stats;
>
> + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ) &&
> + virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VLAN))
> + dev->features |= NETIF_F_HW_VLAN_FILTER;
We should be using has_cvq here...
> -#ifdef CONFIG_PM
> -static int virtnet_freeze(struct virtio_device *vdev)
> +static void virtnet_stop(struct virtnet_info *vi)
I think you still want this under CONFIG_PM, right? Doesn't seem used
elsewhere.
Cheers,
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: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Fri, Nov 2, 2012 at 4:07 PM, Jason Kridner wrote: >> Take a look at arch/x86/platform/mrst/mrst.c. It's a specific example of >> a platform which parses tables and attaches devices to the right physical >> bus in a manner they can be reliably probed even when the device has no >> sane autodetect. > > I know I *am* the slow person in the room, but doesn't this approach > require the code to be compiled into the kernel to support the devices > ahead of time? While I think it might be reasonable to have hardware > developers provide DT fragments in their EEPROMs, there's no way to > get them to submit code patches in order to get their hardware to > work. They need to ship hardware that works with pre-existing > software, since there will be hundreds of boards created by people > with little to no previous Linux experience (akin to Arduino). I seem > to be missing how that approach would get us there. If it is truly new hardware, then there really is no way around them either a) submitting new kernel drivers or b) driving them from userspace. If it is devices with existing drivers populated onto new custom cape boards, then the DT fragment approach should be sufficient for populating them into the Linux driver model. (assuming of course those drivers are already compiled into the kernel) g. -- 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 thermal tree with Linus' tree
Hi Zhang,
Today's linux-next merge of the thermal tree got a conflict in
drivers/thermal/rcar_thermal.c between commit 608f62b996c6 ("thermal:
solve compilation errors in rcar_thermal") from Linus' tree and commit
ebbf0f11e7b4 ("Thermal: Pass zone parameters as argument to
tzd_register") from the thermal 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/thermal/rcar_thermal.c
index f7a1b57,b13fe5d..000
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@@ -210,8 -210,8 +210,8 @@@ static int rcar_thermal_probe(struct pl
goto error_free_priv;
}
- zone = thermal_zone_device_register("rcar_thermal", 0, priv,
+ zone = thermal_zone_device_register("rcar_thermal", 0, 0, priv,
- _thermal_zone_ops, 0, 0);
+ _thermal_zone_ops, NULL, 0, 0);
if (IS_ERR(zone)) {
dev_err(>dev, "thermal zone device is NULL\n");
ret = PTR_ERR(zone);
pgprk0FINQdWz.pgp
Description: PGP signature
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Fri, Nov 2, 2012 at 12:32 PM, Pantelis Antoniou wrote: > The i2c2 alias cannot be resolved at compile time; there has to be > > a) A DT object format where unresolved aliases (symbols) are tracked > b) A runtime DT linker that will resolve the alias, and will insert the >i2c2-devices child nodes as children in the i2c2 node. > c) A method to trigger platform device creation for the child nodes just >inserted. > > DT core changes aren't bound to be easily accepted, so without having a clear > signal from the DT maintainers that they would consider such a method people > are just hesitant to go down this road. I do agree and will accept such a method. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the v4l-dvb tree
Hi Mauro,
On Mon, 29 Oct 2012 11:14:03 +1100 Stephen Rothwell
wrote:
>
> After merging the v4l-dvb tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/hid/hid-picolcd_cir.c: In function 'picolcd_init_cir':
> drivers/hid/hid-picolcd_cir.c:119:27: error: 'RC_TYPE_ALL' undeclared (first
> use in this function)
>
> Caused by commit c003ab1bedf0 ("[media] rc-core: add separate defines for
> protocol bitmaps and numbers"). The new reference was introduced in
> commit ae08e324146c ("HID: picoLCD: Add support for CIR") which was
> merged by Linus on October 2 into v3.7-rc1 via the hid tree.
>
> I have used the v4l-dvb tree from next-20121026 for today.
I still get this today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpYYbJs06IF8.pgp
Description: PGP signature
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Fri, Nov 2, 2012 at 10:19 AM, Koen Kooi wrote:
> button@1 {
> debounce_interval = <50>;
> linux,code = <105>;
> label = "left";
> gpios = < 16 0x0>;
> gpio-key,wakeup;
> autorepeat;
> };
>
> Is the "linux,code" pure hardware or have there already been exceptions to
> that rule?
I generally push back on "linux,blah" bindings since they have the
tendency to change over time when someone changes the driver. However,
since the keycodes are part of the Linux userspace ABI, and are
therefore pretty much set it stone, I didn't object to the
linux,keycode binding. There are already drivers using it.
g.
--
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: drm i915 hangs on heavy io load
On So, 04 Nov 2012, Dave Airlie wrote:
> Yeah thats fine, bisecting works by going to where commits were
> originally committed, so drm-intel-next was 3.6.0-rc2 at some point
> was only merged into Linus later.
Ok, thanks, didn't know that. Have started the bisect game now,
coming back in about 1 year ;-)
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCOPWICK (n.)
The flap of skin which is torn off you lip when trying to smoke an
untipped cigarette.
--- Douglas Adams, The Meaning of Liff
--
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/3] capebus moving omap_devices to mach-omap2
On Fri, Nov 2, 2012 at 8:43 AM, Pantelis Antoniou wrote: > Assuming that we do work on a DT object format, and that the runtime > resolution mechanism is approved, > then I agree that this part of the capebus patches can be dropped and the > functionality assumed by generic > DT core. > > The question is that this will take time, with no guarantees that this would > be acceptable from > the device tree maintainers. So I am putting them in the CC list, to see what > they think about it. This is actually exactly the direction I want to go with DT, which the ability to load supplemental DT data blobs from either a kernel module or userspace using the firmware loading infrastructure. g. -- 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] Staging: Android: logger: module_exit implementationg
On 04/11/12 04:45, Luca Clementi wrote: > On Fri, Nov 2, 2012 at 11:29 AM, Greg Kroah-Hartman > wrote: >> On Thu, Nov 01, 2012 at 11:15:52PM -0700, Luca Clementi wrote: >>> + vfree(current_log->buffer); >>> + kfree(current_log->misc.name); >>> + kfree(current_log); >>> + } >>> + >>> + return; >>> +} >>> + >>> + >>> +module_init(logger_init); >> >> Is module_init() the same "level" as device_initcall()? Did you test >> this out in an Android system? > > Honestly I haven't tested it on Android, but in include/linux/init.h there is: > > #define module_init(x) __initcall(x); > ... > #define __initcall(fn) device_initcall(fn) > > Which lead me to think that there is not much difference between the two call. The different initcalls run at different times. Often modules run with something other than module_init if there are other dependencies on the module/subsystem (see i2c core/busses for example). You would need to check why logger was using device_initcall and make sure that it works correctly (e.g. doesn't miss some early logs) in order to make this change. It should be done as a separate patch anyway to make it easier to identify any issues with it later. ~Ryan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Android: logger: module_exit implementation
On 02/11/12 17:15, Luca Clementi wrote:
> Created the module_exit for the android logger so that
> it can be loaded and unloaded as a module. Fixed
> module_init and some other minor issues.
>
> Signed-off-by: Luca Clementi
> Cc: Greg Kroah-Hartman
> Cc: Brian Swetland
> ---
> drivers/staging/android/logger.c | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/logger.c
> b/drivers/staging/android/logger.c
> index 1d5ed47..050be01 100644
> --- a/drivers/staging/android/logger.c
> +++ b/drivers/staging/android/logger.c
> @@ -676,4 +676,32 @@ static int __init logger_init(void)
> out:
> return ret;
> }
> -device_initcall(logger_init);
> +
> +static void __exit logger_exit(void)
> +{
> + struct logger_log *current_log, *next_log;
> +
> + list_for_each_entry_safe(current_log, next_log, _list, logs) {
> + /* we have to delete all the entry inside log_list */
> + ret = misc_deregister(_log->misc);
ret is undeclared? Has this been tested?
> + if (unlikely(ret)) {
> + pr_err("failed to deregister misc device for log
> '%s'!\n",
> + current_log->misc.name);
> + }
Don't need braces on single line if statements, and unlikely is not
needed here (it isn't a hotpath). The whole error can probably just be
removed since it looks like misc_deregister already does a WARN_ON if it
fails.
> + pr_info("removed loggger '%s'\n", current_log->misc.name);
Don't spam the log with stuff like this. Either change to pr_debug, or
probably just remove it.
> + vfree(current_log->buffer);
> + kfree(current_log->misc.name);
> + kfree(current_log);
Missing:
list_del(_log->logs);
?
> + }
> +
> + return;
This is pointless.
> +}
> +
> +
> +module_init(logger_init);
> +module_exit(logger_exit);
Nitpick - Blank line here.
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Brian Swetland, ");
Should be Robert Love according to the header comment.
> +MODULE_DESCRIPTION("Android Logger");
> +
> +
Don't need extra blank lines at the end of the file.
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc net-next v6 3/3] virtio-net: change the number of queues through ethtool
Jason Wang writes:
> This patch implement the {set|get}_channels method of ethool to allow user to
> change the number of queues dymaically when the device is running. This would
> let the user to tune the device for specific applications.
...
> + /* Only two modes were support currently */
> + if (queue_pairs == 0)
> + return -EINVAL;
> + if (queue_pairs != vi->total_queue_pairs - 1 && queue_pairs != 1)
> + return -EINVAL;
OK, so you let them do all or nothing, but this three-way test is
pretty unclear.
In fact, the whole total_queue_pairs/num_queue_pairs thing is weird (and
uncommented). I think for "total" you mean "max"; the maximum possible
queue pair number.
Let me go back and review the previous patch again...
Cheers,
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: [rfc net-next v6 2/3] virtio_net: multiqueue support
Jason Wang writes:
> This addes multiqueue support to virtio_net driver. There's two mode
> supported:
> single queue pair mode and multiple queue pairs mode. An obvious
> difference compared with a physical mq card is that virtio-net reserve
> first two virtqueues when it is working in multiqueue mode, this is
> used for implementing adaptive mode switching in the future. The
> virtqueues that were in both mq and sq mode were initialized and only
> one queue pair (single queue mode) were used at default. User could
> use ethtool -L to switch to multiqueue mode withe the next patch.
Hi Jason,
This first patch looks good, but conflates three things
together:
(1) Separate per-queue structures from struct virtnet_info to allow
multiple queues. This is the mechanical part of the patch.
(2) An annotation bugfix, see below.
(3) Enabling mq using a new feature and negotiation.
> @@ -700,7 +767,8 @@ static struct rtnl_link_stats64 *virtnet_stats(struct
> net_device *dev,
> unsigned int start;
>
> for_each_possible_cpu(cpu) {
> - struct virtnet_stats *stats = per_cpu_ptr(vi->stats, cpu);
> + struct virtnet_stats __percpu *stats
> + = per_cpu_ptr(vi->stats, cpu);
> u64 tpackets, tbytes, rpackets, rbytes;
>
> do {
Cheers,
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: [PATCHv8 0/3]virtio_console: Add rproc_serial driver
Sjur Brændeland writes: > From: Sjur Brændeland > > This patch-set introduces a new virtio type "rproc_serial" for communicating > with remote processors over shared memory. The driver depends on the > the remoteproc framework. As preparation for introducing "rproc_serial" > I've done a refactoring of the transmit buffer handling. > > Changes since v7: > - Rebased to virtio-next branch. > - Removed extra added lines. > - Removed superfluous checks before calling reclaim_dma_bufs(). > - Rusty raised some question regarding garbage collection of the > out-vq, so I moved this into a separate patch. OK, I'm not sure that WARN_ON won't fire, but that's not all that harmful. Applied, 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: [PATCH] net/at91_ether: fix the use of macb structure
On 11/03/2012 08:04 PM, David Miller : > From: Nicolas Ferre > Date: Tue, 30 Oct 2012 12:30:28 +0100 > >> Due to the use of common structure in at91_ether and macb drivers, >> change the name of DMA descriptor structures in at91_ether as well: >> dma_desc => macb_dma_desc >> >> Signed-off-by: Nicolas Ferre > > This does not apply to net-next, respin it if this change is > still relevant. This one is not relevant anymore. Best regards, -- Nicolas Ferre -- 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/1] HID: microsoft, fix invalid rdesc for 3k kbd
On 11/04/2012 10:06 PM, Geert Uytterhoeven wrote:
> On Fri, Oct 19, 2012 at 1:28 PM, Jiri Slaby wrote:
>> + if ((quirks & MS_RDESC_3K) && *rsize == 106 &&
>> + !memcmp((char []){ 0x19, 0x00, 0x29, 0xff },
>> + [94], 4)) {
>
> Which version of gcc are you using?
4.7.1. But that indeed fails too if memcmp is a macro. This is of course
not the case for x86, so that I didn't hit that. I will post a patch to
change this to standard array accesses. (This looked prettier though.)
@Greg: please drop that patch from the stable queues for now.
thanks,
--
js
suse labs
--
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] snd-es1968: Add ESS vendor ID to pm_whitelist
Add generic ESS vendor ID to pm_whitelist. This should fix suspend on
all Maestro-2 and Maestro-2E based PCI cards.
Tested on Terratec DMX and SF64-PCE2.
Signed-off-by: Ondrej Zary
--- a/sound/pci/es1968.c
+++ b/sound/pci/es1968.c
@@ -2655,6 +2655,8 @@ static struct ess_device_list pm_whitelist[]
__devinitdata = {
{ TYPE_MAESTRO2E, 0x1179 },
{ TYPE_MAESTRO2E, 0x14c0 }, /* HP omnibook 4150 */
{ TYPE_MAESTRO2E, 0x1558 },
+ { TYPE_MAESTRO2E, 0x125d }, /* a PCI card, e.g. Terratec DMX */
+ { TYPE_MAESTRO2, 0x125d }, /* a PCI card, e.g. SF64-PCE2 */
};
static struct ess_device_list mpu_blacklist[] __devinitdata = {
--
Ondrej Zary
--
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:The patch include fix for "-" during string to long conversion
Namit Gupta wrote:
> API simple_strtol() and simple_strtoul() are giving incorrect result for
> string "-".
> These API's consider "-" as a '-' (negative integer) and return incorrect
> string pointer.
> The API returns pointer next to '-' character. However it should return
> starting pointer of the string.
> Below I have included possible solution for that issue.
> Please review.
tl;dr: Interesting issue. Arguably, but not toally clear that, this is
a bug. However, the proposed fix is broken; better fix below.
Just to clarify, the issue is that when fed the string "-", simple_strtol
is setting endp to cp+1 (and returning 0). I don't think there's actually
anything wrong with simple_strtoul; did you mean simple_strtoull()?
glibc's strtol, for example, returns 0 digits converted when fed strings
that consist of a valid prefix (whitespace plus optional sign) if not
followed by valid digits. (I just checked.)
If you want to follow C89 exactly (even though, by not permitting leading
whitespace or + signs, simple_strtol() obviously *doesn't*), returning
*endp = cp is required. The question is what simple_strtol *should* do.
C89 talks about breaking the input into leading whitespace, a "subject
sequence" of characters beginning with the first non-whitespace, and a
final string of unrecognized characters.
Then C89 defines the "expected form" of the subject sequence as "that
of an integer constant as described in §3.1.3.2, optionally preceded by
a plus or minus sign, but not including an integer suffix." The grammar
in the given section does not permit 0-length strings.
(The above is if base=0; if base != 0, the validity of 0-length
strings is not clear.)
Finally, we get to:
#If the subject sequence is empty or does not have the expected
# form, no conversion is performed; the value of nptr is stored in the
# object pointed to by endptr, provided that endptr is not a null
# pointer.
Thus, since "-" is not of the expected form, *endp = cp is required.
The question is whether a "simple_" variant should be expected to do
lookahead like this, or if it should just do what the strtol man page
says: "strtol() stores the address of the first invalid character in
*endptr."
An important point is that lookahead already exists in the handling of
"0x" prefixes. "0x0" through "0xf" are valid hex numbers, but "0xg"
and the like are 1-digit numbers followed by an unparsed string.
(See _parse_integer_fixup_radix() in lib/kstrtox.c.)
Independent of the above discussion, the proposed fix is definitely
not okay. If you're going to consider this a bug, fix it properly
and also return 0 for "-z" as well; don't special-case the NUL byte.
It's awkward to do by pre-validating cp[1], because the range of valid
digits depends on the base. A simpler fix would let simple_strotul make
that determination:
long simple_strtol(const char *cp, char **endp, unsigned int base)
{
long l;
if (cp[0] != '-')
return simple_strtoul(cp, endp, base);
l = -simple_strtoul(cp+1, endp, base);
/* Return 0 digits converted if - sign is followed by 0 valid digits */
if (endp && *endp == cp+1)
*endp = cp;
return l;
}
(Signed-off-by: George Spelvin if anyone wants to
copy this logic to simple_strtoll and turn it into a proper patch.)
--
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] staging: ste_rmi4: Convert to Type-B support
Hi Alexandra,
Thanks for making changes.
> This patch converts to MT-B because Synaptics touch devices are
> capable of tracking identifiable fingers
>
> This patch was tested on pandaboard, except input_mt_sync_frame(),
> which is a quite new function.
I am not sure how to interpret this. Is the patch untested, or tested
on something different from a pandaboard?
> I changed to use sylpheed as my mail client. Please let me know
> if there is any problem.
> Greatly appreciate your time.
As mentioned, the commit message of the patch should not contain mail
conversation.
> drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c | 122
> -
> 1 files changed, 57 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
> b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
> index 277491a..7876f6b 100644
> --- a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
> +++ b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
> @@ -1,7 +1,7 @@
> /**
> *
> - * Synaptics Register Mapped Interface (RMI4) I2C Physical Layer Driver.
> - * Copyright (c) 2007-2010, Synaptics Incorporated
> + * Synaptics Register Mapped Interface (RMI4) I2C Touchscreen Driver.
> + * Copyright (c) 2007-2012, Synaptics Incorporated
> *
> * Author: Js HA for ST-Ericsson
> * Author: Naveen Kumar G for ST-Ericsson
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
> #include "synaptics_i2c_rmi4.h"
>
> /* TODO: for multiple device support will need a per-device mutex */
> @@ -63,12 +64,11 @@
> #define MASK_4BIT0x0F
> #define MASK_3BIT0x07
> #define MASK_2BIT0x03
> -#define TOUCHPAD_CTRL_INTR 0x8
> +#define TOUCHSCREEN_CTRL_INTR0x8
> #define PDT_START_SCAN_LOCATION (0x00E9)
> #define PDT_END_SCAN_LOCATION(0x000A)
> #define PDT_ENTRY_SIZE (0x0006)
> -#define RMI4_NUMBER_OF_MAX_FINGERS (8)
> -#define SYNAPTICS_RMI4_TOUCHPAD_FUNC_NUM (0x11)
> +#define SYNAPTICS_RMI4_TOUCHSCREEN_FUNC_NUM (0x11)
> #define SYNAPTICS_RMI4_DEVICE_CONTROL_FUNC_NUM (0x01)
>
> /**
> @@ -164,6 +164,7 @@ struct synaptics_rmi4_device_info {
> * @regulator: pointer to the regulator structure
> * @wait: wait queue structure variable
> * @touch_stopped: flag to stop the thread function
> + * @fingers_supported: maximum supported fingers
> *
> * This structure gives the device data information.
> */
> @@ -184,6 +185,7 @@ struct synaptics_rmi4_data {
> struct regulator*regulator;
> wait_queue_head_t wait;
> booltouch_stopped;
> + unsigned char fingers_supported;
> };
>
> /**
> @@ -291,34 +293,33 @@ exit:
> }
>
> /**
> - * synpatics_rmi4_touchpad_report() - reports for the rmi4 touchpad device
> + * synpatics_rmi4_touchscreen_report() - reports for the rmi4 touchscreen
> device
> * @pdata: pointer to synaptics_rmi4_data structure
> * @rfi: pointer to synaptics_rmi4_fn structure
> *
> - * This function calls to reports for the rmi4 touchpad device
> + * This function calls to reports for the rmi4 touchscreen device
> */
> -static int synpatics_rmi4_touchpad_report(struct synaptics_rmi4_data *pdata,
> +static int synpatics_rmi4_touchscreen_report(struct synaptics_rmi4_data
> *pdata,
> struct synaptics_rmi4_fn *rfi)
> {
> /* number of touch points - fingers down in this case */
> int touch_count = 0;
> int finger;
> - int fingers_supported;
> int finger_registers;
> int reg;
> int finger_shift;
> int finger_status;
> int retval;
> + int x, y;
> + int wx, wy;
> unsigned short data_base_addr;
> unsigned short data_offset;
> unsigned char data_reg_blk_size;
> unsigned char values[2];
> unsigned char data[DATA_LEN];
> - int x[RMI4_NUMBER_OF_MAX_FINGERS];
> - int y[RMI4_NUMBER_OF_MAX_FINGERS];
> - int wx[RMI4_NUMBER_OF_MAX_FINGERS];
> - int wy[RMI4_NUMBER_OF_MAX_FINGERS];
> + unsigned char fingers_supported = pdata->fingers_supported;
> struct i2c_client *client = pdata->i2c_client;
> + struct input_dev *input_dev = pdata->input_dev;
The patch is definitely an improvement over the existing code, but I
would very much recommend a follow-up patch which splits this
function.
>
> /* get 2D sensor finger data */
> /*
> @@ -333,7 +334,6 @@ static int synpatics_rmi4_touchpad_report(struct
> synaptics_rmi4_data *pdata,
>* 10 = finger present but data may not be accurate,
>* 11 = reserved for product use.
>*/
> - fingers_supported = rfi->num_of_data_points;
> finger_registers= (fingers_supported + 3)/4;
> data_base_addr = rfi->fn_desc.data_base_addr;
> retval = synaptics_rmi4_i2c_block_read(pdata,
Re: [PATCH 01/13] HW-latency: hardware latency test 0.10
On Mon, Nov 5, 2012 at 2:59 AM, Luming Yu wrote:
>
> This patch is the first step to test some basic hardware functions like
> TSC to help people understand if there is any hardware latency as well
> as throughput problem exposed on bare metal or left behind by BIOS or
> interfered by SMI. Currently the patch tests TSC, CPU Frequency and
> RDRAND which is a new CPU instruction to get random number introduced in
> new CPU like Intel Ivy Bridge in stop_machine context,which is choosen to
> make sure testers fully control their system under test to rule out some
> level of unwanted noise.
>
> Signed-off-by: Luming Yu
> ---
> drivers/misc/Kconfig | 7 +
> drivers/misc/Makefile | 1 +
> drivers/misc/hw_latency_test.c | 833
> +
> 3 files changed, 841 insertions(+)
> create mode 100644 drivers/misc/hw_latency_test.c
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index b151b7c..5ed440b 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -114,6 +114,13 @@ config IBM_ASM
> for information on the specific driver level and support statement
> for your IBM server.
>
> +config HW_LATENCY_TEST
> + tristate "Testing module to detect hardware lattency and throughput"
> + depends on DEBUG_FS
> + depends on RING_BUFFER
> + depends on X86
> + default m
> +
> config PHANTOM
> tristate "Sensable PHANToM (PCI)"
> depends on PCI
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 2129377..c195cce 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -49,3 +49,4 @@ obj-y += carma/
> obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
> obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
> obj-$(CONFIG_INTEL_MEI)+= mei/
> +obj-$(CONFIG_HW_LATENCY_TEST) += hw_latency_test.o
> diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
> new file mode 100644
> index 000..2aa3a74
> --- /dev/null
> +++ b/drivers/misc/hw_latency_test.c
> @@ -0,0 +1,833 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define BUF_SIZE_DEFAULT 262144UL
> +#define BUF_FLAGS (RB_FL_OVERWRITE)
> +#defineU64STR_SIZE 22
> +#define DEBUGFS_BUF_SIZE 1024
> +#define DEBUGFS_NAME_SIZE 32
> +
> +#defineVERSION "0.1.0"
> +#define BANNER "hardware latency test"
> +#define DRVNAME"hw_latency_test"
> +
> +#define DEFAULT_SAMPLE_WINDOW 100
> +#defineDEFAULT_SAMPLE_WIDTH50
> +#defineDEFAULT_LAT_THRESHOLD 10
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Luming Yu ");
> +MODULE_DESCRIPTION("A simple hardware latency test");
> +MODULE_VERSION(VERSION);
>o SNIP
Ok, hopefully this is just an unintentional oversight - but I don't
see where you are acknowledging that the original author of most of
this code is Jon Masters. It's fine for you to work on it, but you
have to somewhere acknowledge where it comes from.
Thanks
John
--
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 01/13] HW-latency: hardware latency test 0.10
Hey, Op 05-11-12 02:59, Luming Yu schreef: > This patch is the first step to test some basic hardware functions like > TSC to help people understand if there is any hardware latency as well > as throughput problem exposed on bare metal or left behind by BIOS or > interfered by SMI. Currently the patch tests TSC, CPU Frequency and > RDRAND which is a new CPU instruction to get random number introduced in > new CPU like Intel Ivy Bridge in stop_machine context,which is choosen to > make sure testers fully control their system under test to rule out some > level of unwanted noise. > > Signed-off-by: Luming Yu > --- > drivers/misc/Kconfig | 7 + > drivers/misc/Makefile | 1 + > drivers/misc/hw_latency_test.c | 833 > + > 3 files changed, 841 insertions(+) > create mode 100644 drivers/misc/hw_latency_test.c > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index b151b7c..5ed440b 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -114,6 +114,13 @@ config IBM_ASM > for information on the specific driver level and support statement > for your IBM server. > > +config HW_LATENCY_TEST > + tristate "Testing module to detect hardware lattency and throughput" > + depends on DEBUG_FS > + depends on RING_BUFFER > + depends on X86 > + default m Is there any reason this tester couldn't easily be made to work for !x86? Also I think it would make more sense to squash all fixes, and submit fixes for the things like '[PATCH 07/13] HW-latency: delete too many "Fast TSC calibration using PIT" in cpufreq sampling' before the actual patch. It seems this is not necessarily a hw-latency specific patch to me. ~Maarten -- 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/1] HID: microsoft, fix invalid rdesc for 3k kbd
On Fri, Oct 19, 2012 at 1:28 PM, Jiri Slaby wrote:
> + if ((quirks & MS_RDESC_3K) && *rsize == 106 &&
> + !memcmp((char []){ 0x19, 0x00, 0x29, 0xff },
> + [94], 4)) {
Which version of gcc are you using?
I'm getting (m68k-linux-gnu-gcc 4.1.2):
drivers/hid/hid-microsoft.c:51:18: error: macro "memcmp" passed 6
arguments, but takes just 3
drivers/hid/hid-microsoft.c: In function ‘ms_report_fixup’:
drivers/hid/hid-microsoft.c:50: error: ‘memcmp’ undeclared (first use
in this function)
drivers/hid/hid-microsoft.c:50: error: (Each undeclared identifier is
reported only once
/drivers/hid/hid-microsoft.c:50: error: for each function it appears in.)
Extracted into this test case:
---snip---
#include
#define memcmp(a, b, c) memcmp((a), (b), (c))
int f(unsigned char *rdesc)
{
return memcmp((char []){ 0x19, 0x00, 0x29, 0xff }, [94], 4);
}
---snip---
it also fails with gcc-3.4/4.1/4.2/4.3/4.4 of Ubuntu 10.04 on amd64.
Interestingly, it doesn't fail if I remove the #define for memcmp. So it seems
to work if memcmp() is a real function, not a #define.
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/
Re: [PATCH] drivers/misc/kgdbts.c: remove eprintk
On Sun, 4 Nov 2012, Arnd Bergmann wrote: On Sunday 04 November 2012, Julia Lawall wrote: Hmm, I did not think that WARN() took a KERN_ERR argument, which should really be implied here. Looking at the code, it really seems to be required at the moment, but only 5 out of 117 callers use it this way. Any idea what is going on here? I'm not sure to understand the 5 and 117. Using grep, I get 30 with KERN_ERR, 61 with some KERN thing, and 1207 without KERN. Right, I was using 'grep -w', which misses a lot of the instances, although I see still much fewer in the last category. If things are set up such that warn_slowpath_fmt is called, then that function adds KERN_WARNING. There is an alternate definition of __WARN_printf that just does a printk. I don't see yet where that KERN_WARNING gets added. Looking at warn_slowpath_common, there are two or three lines that get printed at KERN_WARNING level, followed by the format that got passed into WARN(), which may or may not include a printk level, but I don't see one getting added. OK, I agree. There are lots of KERN_WARNINGs, but not on the string that was passed in. Still, maybe it is not so good to pass a KERN_XXX for some other XXX to WARN. 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: [PATCH] samsung-laptop: Disable if CONFIG_EFI=y
On Sun, 2012-11-04 at 09:47 -0800, Jonathan Nieder wrote: > Matt Fleming wrote: > > > --- a/drivers/platform/x86/Kconfig > > +++ b/drivers/platform/x86/Kconfig > > @@ -717,7 +717,7 @@ config XO15_EBOOK > > > > config SAMSUNG_LAPTOP > > tristate "Samsung Laptop driver" > > - depends on X86 > > + depends on X86 && !EFI > > That means distros would just not get the samsung-laptop driver. > Is there a runtime check that could be used instead? Well, the closest thing we have at the moment is the 'efi_enabled' variable, but that doesn't actually mean "We were booted from EFI?", it means "Do we have EFI runtime services?", and that's not a broad enough check for this case. We don't have access to the EFI runtime services when a 64-bit kernel is booted from 32-bit EFI firmware or vice-versa. Notably the chromebooks use this scheme. And seeing as Samsung make chromebooks, I'm not convinced we won't hit that case. But yeah, you've got a valid point. Clearly we need a way to check this at runtime. I'll repsin this patch. -- Matt Fleming, Intel Open Source Technology Center -- 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] drivers/misc/kgdbts.c: remove eprintk
On Sunday 04 November 2012, Julia Lawall wrote: > > Hmm, I did not think that WARN() took a KERN_ERR argument, which should > > really be implied here. Looking at the code, it really seems to be required > > at the moment, but only 5 out of 117 callers use it this way. > > > > Any idea what is going on here? > > I'm not sure to understand the 5 and 117. Using grep, I get 30 with > KERN_ERR, 61 with some KERN thing, and 1207 without KERN. Right, I was using 'grep -w', which misses a lot of the instances, although I see still much fewer in the last category. > If things are > set up such that warn_slowpath_fmt is called, then that function adds > KERN_WARNING. There is an alternate definition of __WARN_printf that just > does a printk. I don't see yet where that KERN_WARNING gets added. Looking at warn_slowpath_common, there are two or three lines that get printed at KERN_WARNING level, followed by the format that got passed into WARN(), which may or may not include a printk level, but I don't see one getting added. 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 v2 08/11] HID: hid-multitouch: fix Win 8 protocol
Hi Benjamin, > The goal of this patch is to implement in a reliable way Win 8 > multitouch protocol (to avoid quirking many devices). Thanks to the > precision they made in the specification, I think it is feasible: > they add the dynamic part that were missing in Win 7 spec: > """ > When sending data in hybrid or parallel mode, a contact that is > delivered in one report must be delivered in all subsequent reports > until it is lifted off the screen. If time is needed to adequate > determine if the contact was lifted off the surface, the device must > report the last known position of the contact and then deliver the > “UP” state of the contact in a subsequent report. Devices should not > send a report without the information for that contact while trying to > determine its current state. > """ The text seems to say that devices are not required to send touch state information in a separate frame, but if the device needs time to determine the touch state, the touch properties should stay the same during that time. > Thus, the quirk ALWAYS_VALID fits very well with win 8 devices (the > device has to send the touch until it is lifted and out of range, and > the device must send the 'up' state). One could simply add another quirk which fits the win8 case exactly instead. No need to change the existing one. > The problem lies that some devices may reuse contact id 0 within the > frame for the end of the report (my Win8 device doesn't has this kind > of problem): > > With the following hid usages: > I -> contact Id > T -> tip switch > X, Y -> X, Y > S -> scan time > C -> contact count > > a friendly device would report: > > I:1 T:1 X:125 X:130 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:0 C:01 > I:1 T:1 X:130 X:135 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:1 C:01 > I:1 T:1 X:135 X:140 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:2 C:01 > I:1 T:1 X:140 X:145 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:3 C:01 > I:1 T:0 X:140 X:145 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:4 C:01 > > *but*, I've already seen win 7 devices, that do send: > > I:0 T:1 X:125 X:130 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:0 C:01 > I:0 T:1 X:130 X:135 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:1 C:01 > I:0 T:1 X:135 X:140 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:2 C:01 > I:0 T:1 X:140 X:145 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:3 C:01 > I:0 T:0 X:140 X:145 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:4 C:01 I see, more brain-damaged usage. :-) Still, there seems to be a simpler way to distinguish this case: if there are more than one touch with the same id in the frame, use the one with T=1. > The difference lies in the first bit, contact id is 0. > > So, the quirk always valid is not sufficient because the second touch > in the frame will override the values of the first (the valid one). > > As Microsoft says that "the device must report the last known position > of the contact and then deliver the “UP” state of the contact", so we > can safely discard the second touch because X and Y do not match the > current state of the valid touch. > > Then, as exposed in the "How to Design and Test Multitouch Hardware > Solutions for Windows 8" document here: > http://msdn.microsoft.com/en-us/library/windows/hardware/hh872968.aspx > when the device attempt the certification, if the "up" is not valid, > the error "Last move location different" raises, which, I hope will > prevent the device to get the certification. I think it would be too fragile to rely on this assumption. Hopefully the suggestion above will work equally well. Thanks, Henrik -- 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] extcon: arizona: unlock mutex on error path in arizona_micdet()
If regmap_read() failed, arizona_micdet() returns IRQ_NONE
leaving >lock mutex locked as opposed to all other return paths.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/extcon/extcon-arizona.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index cdab9e5..d876a54 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -166,6 +166,7 @@ static irqreturn_t arizona_micdet(int irq, void *data)
ret = regmap_read(arizona->regmap, ARIZONA_MIC_DETECT_3, );
if (ret != 0) {
dev_err(arizona->dev, "Failed to read MICDET: %d\n", ret);
+ mutex_unlock(>lock);
return IRQ_NONE;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging/media: Use dev_ printks in go7007/wis-sony-tuner.c
fixed below checkpatch warning.
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then
pr_info(... to printk(KERN_INFO ...
- WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/media/go7007/wis-sony-tuner.c | 86 -
1 file changed, 42 insertions(+), 44 deletions(-)
diff --git a/drivers/staging/media/go7007/wis-sony-tuner.c
b/drivers/staging/media/go7007/wis-sony-tuner.c
index 8f1b7d4..3e013b9 100644
--- a/drivers/staging/media/go7007/wis-sony-tuner.c
+++ b/drivers/staging/media/go7007/wis-sony-tuner.c
@@ -95,8 +95,8 @@ static int set_freq(struct i2c_client *client, int freq)
band_name = "UHF";
band_select = tun->UHF;
}
- printk(KERN_DEBUG "wis-sony-tuner: tuning to frequency %d.%04d (%s)\n",
- freq / 16, (freq % 16) * 625, band_name);
+ dev_dbg(>dev, "tuning to frequency %d.%04d (%s)\n",
+ freq / 16, (freq % 16) * 625, band_name);
n = freq + tun->IFPCoff;
buffer[0] = n >> 8;
@@ -288,16 +288,16 @@ static int mpx_setup(struct i2c_client *client)
u8 buf1[3], buf2[2];
struct i2c_msg msgs[2];
- printk(KERN_DEBUG "wis-sony-tuner: MPX registers: %04x %04x "
- "%04x %04x %04x %04x %04x %04x\n",
- mpx_audio_modes[t->mpxmode].modus,
- source,
- mpx_audio_modes[t->mpxmode].acb,
- mpx_audio_modes[t->mpxmode].fm_prescale,
- mpx_audio_modes[t->mpxmode].nicam_prescale,
- mpx_audio_modes[t->mpxmode].scart_prescale,
- mpx_audio_modes[t->mpxmode].system,
- mpx_audio_modes[t->mpxmode].volume);
+ dev_dbg(>dev,
+ "MPX registers: %04x %04x %04x %04x %04x %04x %04x
%04x\n",
+ mpx_audio_modes[t->mpxmode].modus,
+ source,
+ mpx_audio_modes[t->mpxmode].acb,
+ mpx_audio_modes[t->mpxmode].fm_prescale,
+ mpx_audio_modes[t->mpxmode].nicam_prescale,
+ mpx_audio_modes[t->mpxmode].scart_prescale,
+ mpx_audio_modes[t->mpxmode].system,
+ mpx_audio_modes[t->mpxmode].volume);
buf1[0] = 0x11;
buf1[1] = 0x00;
buf1[2] = 0x7e;
@@ -310,14 +310,14 @@ static int mpx_setup(struct i2c_client *client)
msgs[1].len = 2;
msgs[1].buf = buf2;
i2c_transfer(client->adapter, msgs, 2);
- printk(KERN_DEBUG "wis-sony-tuner: MPX system: %02x%02x\n",
- buf2[0], buf2[1]);
+ dev_dbg(>dev, "MPX system: %02x%02x\n",
+ buf2[0], buf2[1]);
buf1[0] = 0x11;
buf1[1] = 0x02;
buf1[2] = 0x00;
i2c_transfer(client->adapter, msgs, 2);
- printk(KERN_DEBUG "wis-sony-tuner: MPX status: %02x%02x\n",
- buf2[0], buf2[1]);
+ dev_dbg(>dev, "MPX status: %02x%02x\n",
+ buf2[0], buf2[1]);
}
#endif
return 0;
@@ -375,8 +375,7 @@ static int set_if(struct i2c_client *client)
t->mpxmode = force_mpx_mode;
else
t->mpxmode = default_mpx_mode;
- printk(KERN_DEBUG "wis-sony-tuner: setting MPX to mode %d\n",
- t->mpxmode);
+ dev_dbg(>dev, "setting MPX to mode %d\n", t->mpxmode);
mpx_setup(client);
return 0;
@@ -401,8 +400,8 @@ static int tuner_command(struct i2c_client *client,
unsigned int cmd, void *arg)
if (t->type >= 0) {
if (t->type != *type)
- printk(KERN_ERR "wis-sony-tuner: type already "
- "set to %d, ignoring request for %d\n",
+ dev_err(>dev,
+ "type already set to %d, ignoring
request for %d\n",
t->type, *type);
break;
}
@@ -414,28 +413,28 @@ static int tuner_command(struct i2c_client *client,
unsigned int cmd, void *arg)
case 'B':
case 'g':
case 'G':
- printk(KERN_INFO "wis-sony-tuner: forcing "
- "tuner to PAL-B/G bands\n");
+ dev_info(>dev,
+
[PATCH] staging/media: Use dev_ printks in go7007/go7007-driver.c
fixed below checkpatch warning.
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then
pr_info(... to printk(KERN_INFO ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/media/go7007/go7007-driver.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/go7007/go7007-driver.c
b/drivers/staging/media/go7007/go7007-driver.c
index ece2dd1..c9dfc75 100644
--- a/drivers/staging/media/go7007/go7007-driver.c
+++ b/drivers/staging/media/go7007/go7007-driver.c
@@ -201,7 +201,8 @@ static int init_i2c_module(struct i2c_adapter *adapter,
const char *type,
if (v4l2_i2c_new_subdev(v4l2_dev, adapter, type, addr, NULL))
return 0;
- printk(KERN_INFO "go7007: probing for module i2c:%s failed\n", type);
+ dev_info(>dev,
+"go7007: probing for module i2c:%s failed\n", type);
return -1;
}
@@ -217,7 +218,7 @@ int go7007_register_encoder(struct go7007 *go)
{
int i, ret;
- printk(KERN_INFO "go7007: registering new %s\n", go->name);
+ dev_info(go->dev, "go7007: registering new %s\n", go->name);
mutex_lock(>hw_lock);
ret = go7007_init_encoder(go);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] Platform: x86: Add Chrome OS Laptop driver
Hi Corentin, Thanks for your feedback on this. Indeed, what Olof is saying is correct. In its current form, this driver exists to register i2c devices on our laptops. We have one piece of information (the irq, specifically) that cannot be added to the i2c_board_info when using user space probing. To answer your question about where this driver is going in the future, you can take a look at the current version of the driver in the chromiumos kernel: https://gerrit.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=blob;f=drivers/platform/x86/chromeos_laptop.c;h=f948f61d864a5265f6e144833358512f68b7e467;hb=chromeos-3.4 I added more i2c devices that are registered the same way for a number of other chromeos systems, but there is one platform device (a keyboard backlight) that is added using platform_device_register_simple. Thanks again for reviewing, Benson On Fri, Nov 2, 2012 at 6:32 AM, Corentin Chary wrote: > On Fri, Nov 2, 2012 at 1:09 PM, Olof Johansson wrote: >> On Fri, Nov 2, 2012 at 2:03 PM, Corentin Chary >> wrote: >>> On Fri, Nov 2, 2012 at 12:45 PM, Olof Johansson wrote: On Fri, Oct 26, 2012 at 10:30 AM, Corentin Chary wrote: > Looks better, but I'm curious, what is the final purpose of this driver ? > What ABI will be exposed, who will use it ? > > If it is going to be bigger, it may be a good idea to convert it to a > real platform driver (platform_drivers/platform_device stuff). It's not a driver per se. It's platform glue that, based on the DMI table, registers platform and i2c devices (at this time only i2c devices). Unfortunately there's no way to do this nicely from userspace after boot, since there's limits to how much data you can provide with the simpler userspace-driven i2c probing protocol. So, there's no user-facing ABI on this, and no one is expected to use it from userspace. It's just there to make sure that the un-probably devices on this kind of hardware gets bound to drivers properly. If it's converted to a platform_driver, how do you expect that to probe, where would the platform_device be registered? >>> >>> I guess I would check dmi in the module init method, and then use the >>> probe callback of platform_create_bundle to do more probing if >>> necessary. >> >> Maybe I'm dense but I don't see how that could possibly be better than >> what the code does today. It would just add more overhead and clutter >> by creating a unnecessary dummy device/driver setup just to, in the >> end, register the same i2c devices. >> > > Well that was the point of "If it is going to be bigger". > Of course, as long as it only register those i2c devices, it doesn't > really matter. > > -- > Corentin Chary > http://xf.iksaif.net -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org -- 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/
merging printk and WARN
It looks like these patches were not a good idea, because in each case the printk provides an error level, and WARN then provides another one. Sorry for the noise. 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: sched: SCHED_DEADLINE v6
Nobody knows? This is really obscure for an EDF patch. Making things a bit more accessible should be a priority. I think a lot of enthusiasts would like to have smooth control over stuff, without windows-jitter. If you can do a robot arm, jitter-free with this, then I am very interested. uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$ ./schedtool -E -t 500:1000 3718 ERROR: could not set PID 3718 to E: SCHED_DEADLINE - Function not implemented uwaysi@Millennium:~/Kildekode/sched_deadline-schedtool-dl$ On Sun, 04 Nov 2012 20:02:25 +0100, Uwaysi Bin Kareem wrote: How does the modified schedtool work? There is no updated documentation. http://gitorious.org/sched_deadline/schedtool-dl/commits/latest/2.6.36-dl-V3 If anyone could give an example of a 1000uS period / 500uS time, with schedtool, or any other relevant information. Most examples online use parameters that are no longer supported. Peace Be With You. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/misc/kgdbts.c: remove eprintk
On Sun, 4 Nov 2012, Arnd Bergmann wrote:
On Saturday 03 November 2012, Julia Lawall wrote:
@@ -113,10 +113,6 @@
printk(KERN_INFO a); \
touch_nmi_watchdog(); \
} while (0)
-#define eprintk(a...) do { \
- printk(KERN_ERR a); \
- WARN_ON(1); \
- } while (0)
#define MAX_CONFIG_LEN40
static struct kgdb_io kgdbts_io_ops;
@@ -323,7 +319,7 @@ static int check_and_rewind_pc(char *put_str, char *arg)
v2printk("Emul: rewind hit single step bp\n");
restart_from_top_after_write = 1;
} else if (strcmp(arg, "silent") && ip + offset != addr) {
- eprintk("kgdbts: BP mismatch %lx expected %lx\n",
+ WARN(1, KERN_ERR "kgdbts: BP mismatch %lx expected %lx\n",
ip + offset, addr);
return 1;
}
Hmm, I did not think that WARN() took a KERN_ERR argument, which should
really be implied here. Looking at the code, it really seems to be required
at the moment, but only 5 out of 117 callers use it this way.
Any idea what is going on here?
I'm not sure to understand the 5 and 117. Using grep, I get 30 with
KERN_ERR, 61 with some KERN thing, and 1207 without KERN. If things are
set up such that warn_slowpath_fmt is called, then that function adds
KERN_WARNING. There is an alternate definition of __WARN_printf that just
does a printk.
So if eprintk wants KERN_ERR, then it seems that rewriting it with WARN is
not a good idea. I will check whether this problems arises with the other
printks and WARNs that I suggested to merge.
thanks,
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/
