02 Jul, 2016

1 commit

  • power_supply_get_property() should ideally return -EAGAIN if it is
    called while the power_supply is being registered. There was no way
    previously to determine if use_cnt == 0 meant that the power_supply
    wasn't fully registered yet, or if it had already been unregistered.

    Add a new boolean to the power_supply struct to simply show if
    registration is completed. Lastly, modify the check in
    power_supply_show_property() to also ignore -EAGAIN when so it
    doesn't complain about not returning the property.

    Signed-off-by: Rhyland Klein
    Signed-off-by: Sebastian Reichel

    Rhyland Klein
     

15 Feb, 2016

1 commit

  • This adds power supply types for USB chargers defined in
    the USB Type-C Specification 1.1 and in the
    USB Power Delivery Specification Revision 2.0 V1.1.

    The following are added :
    POWER_SUPPLY_TYPE_USB_TYPE_C, /* Type C Port */
    POWER_SUPPLY_TYPE_USB_PD, /* Power Delivery Port */
    POWER_SUPPLY_TYPE_USB_PD_DRP, /* PD Dual Role Port */

    Signed-off-by: Benson Leung
    [tomeu: remove the mention to Type C from the comments]
    Signed-off-by: Tomeu Vizoso
    Reviewed-by: Alec Berg
    Reviewed-by: Vincent Palatin
    Reviewed-by: Todd Broch
    Signed-off-by: Sebastian Reichel

    Benson Leung
     

10 Jun, 2015

1 commit

  • The fix for NULL pointer exception related to calling uevent for not
    finished probe caused to set all writeable properties as non-writeable.
    This was caused by checking if property is writeable before the initial
    increase of power supply usage counter and in the same time using
    wrapper over property_is_writeable(). The wrapper returns ENODEV if the
    usage counter is still 0.

    The call trace looked like:
    device probe:
    power_supply_register()
    use_cnt = 0;
    device_add()
    create sysfs entries
    power_supply_attr_is_visible()
    power_supply_property_is_writeable()
    if (use_cnt == 0) return -ENODEV;
    use_cnt++;

    Replace the usage of wrapper with direct call to property_is_writeable()
    from driver. This should be safe call during device probe because
    implementations of this callback just return 0/1 for different
    properties and they do not access any of the driver's internal data.

    Fixes: 8e59c7f23410 ("power_supply: Fix NULL pointer dereference during bq27x00_battery probe")
    Signed-off-by: Krzysztof Kozlowski
    Signed-off-by: Sebastian Reichel

    Krzysztof Kozlowski
     

24 May, 2015

1 commit

  • Use wrappers over get_property() and set_property() internally in power
    supply and for sysfs interface. The wrappers provide safe access if
    power supply is not yet registered or t is being destroyed.

    In case of syfs the theoretical race could happen between ending of
    driver's probe and parallel sysfs access:
    some_driver_probe() userspace
    ==================================== ===========================
    drv->psy = power_supply_register()
    device_add()
    sysfs entries are created
    atomic_inc(&psy->use_cnt);
    store on sysfs attributes
    drv->set_property()
    dereference of drv->psy
    drv->psy = returned psy;

    For leds the race could happen between power supply being destroyed and
    ongoing power_supply_changed_work().

    Signed-off-by: Krzysztof Kozlowski
    Signed-off-by: Sebastian Reichel

    Krzysztof Kozlowski
     

14 Mar, 2015

2 commits

  • Change the ownership of power_supply structure from each driver
    implementing the class to the power supply core.

    The patch changes power_supply_register() function thus all drivers
    implementing power supply class are adjusted.

    Each driver provides the implementation of power supply. However it
    should not be the owner of power supply class instance because it is
    exposed by core to other subsystems with power_supply_get_by_name().
    These other subsystems have no knowledge when the driver will unregister
    the power supply. This leads to several issues when driver is unbound -
    mostly because user of power supply accesses freed memory.

    Instead let the core own the instance of struct 'power_supply'. Other
    users of this power supply will still access valid memory because it
    will be freed when device reference count reaches 0. Currently this
    means "it will leak" but power_supply_put() call in next patches will
    solve it.

    This solves invalid memory references in following race condition
    scenario:

    Thread 1: charger manager
    Thread 2: power supply driver, used by charger manager

    THREAD 1 (charger manager) THREAD 2 (power supply driver)
    ========================== ==============================
    psy = power_supply_get_by_name()
    Driver unbind, .remove
    power_supply_unregister()
    Device fully removed
    psy->get_property()

    The 'get_property' call is executed in invalid context because the driver was
    unbound and struct 'power_supply' memory was freed.

    This could be observed easily with charger manager driver (here compiled
    with max17040 fuel gauge):

    $ cat /sys/devices/virtual/power_supply/cm-battery/capacity &
    $ echo "1-0036" > /sys/bus/i2c/drivers/max17040/unbind
    [ 55.725123] Unable to handle kernel NULL pointer dereference at virtual address 00000000
    [ 55.732584] pgd = d98d4000
    [ 55.734060] [00000000] *pgd=5afa2831, *pte=00000000, *ppte=00000000
    [ 55.740318] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
    [ 55.746210] Modules linked in:
    [ 55.749259] CPU: 1 PID: 2936 Comm: cat Tainted: G W 3.19.0-rc1-next-20141226-00048-gf79f475f3c44-dirty #1496
    [ 55.760190] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
    [ 55.766270] task: d9b76f00 ti: daf54000 task.ti: daf54000
    [ 55.771647] PC is at 0x0
    [ 55.774182] LR is at charger_get_property+0x2f4/0x36c
    [ 55.779201] pc : [] lr : [] psr: 60000013
    [ 55.779201] sp : daf55e90 ip : 00000003 fp : 00000000
    [ 55.790657] r10: 00000000 r9 : c06e2878 r8 : d9b26c68
    [ 55.795865] r7 : dad81610 r6 : daec7410 r5 : daf55ebc r4 : 00000000
    [ 55.802367] r3 : 00000000 r2 : daf55ebc r1 : 0000002a r0 : d9b26c68
    [ 55.808879] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
    [ 55.815994] Control: 10c5387d Table: 598d406a DAC: 00000015
    [ 55.821723] Process cat (pid: 2936, stack limit = 0xdaf54210)
    [ 55.827451] Stack: (0xdaf55e90 to 0xdaf56000)
    [ 55.831795] 5e80: 60000013 c01459c4 0000002a c06f8ef8
    [ 55.839956] 5ea0: db651000 c06f8ef8 daebac00 c04cb668 daebac08 c0346864 00000000 c01459c4
    [ 55.848115] 5ec0: d99eaa80 c06f8ef8 00000fff 00001000 db651000 c027f25c c027f240 d99eaa80
    [ 55.856274] 5ee0: d9a06c00 c0146218 daf55f18 00001000 d99eaa80 db4c18c0 00000001 00000001
    [ 55.864468] 5f00: daf55f80 c0144c78 c0144c54 c0107f90 00015000 d99eaab0 00000000 00000000
    [ 55.872603] 5f20: 000051c7 00000000 db4c18c0 c04a9370 00015000 00001000 daf55f80 00001000
    [ 55.880763] 5f40: daf54000 00015000 00000000 c00e53dc db4c18c0 c00e548c 0000000d 00008124
    [ 55.888937] 5f60: 00000001 00000000 00000000 db4c18c0 db4c18c0 00001000 00015000 c00e5550
    [ 55.897099] 5f80: 00000000 00000000 00001000 00001000 00015000 00000003 00000003 c000f364
    [ 55.905239] 5fa0: 00000000 c000f1a0 00001000 00015000 00000003 00015000 00001000 0001333c
    [ 55.913399] 5fc0: 00001000 00015000 00000003 00000003 00000002 00000000 00000000 00000000
    [ 55.921560] 5fe0: 7fffe000 be999850 0000a225 b6f3c19c 60000010 00000003 00000000 00000000
    [ 55.929744] [] (charger_get_property) from [] (power_supply_show_property+0x48/0x20c)
    [ 55.939286] [] (power_supply_show_property) from [] (dev_attr_show+0x1c/0x48)
    [ 55.948130] [] (dev_attr_show) from [] (sysfs_kf_seq_show+0x84/0x104)
    [ 55.956298] [] (sysfs_kf_seq_show) from [] (kernfs_seq_show+0x24/0x28)
    [ 55.964536] [] (kernfs_seq_show) from [] (seq_read+0x1b0/0x484)
    [ 55.972172] [] (seq_read) from [] (__vfs_read+0x18/0x4c)
    [ 55.979188] [] (__vfs_read) from [] (vfs_read+0x7c/0x100)
    [ 55.986304] [] (vfs_read) from [] (SyS_read+0x40/0x8c)
    [ 55.993164] [] (SyS_read) from [] (ret_fast_syscall+0x0/0x48)
    [ 56.000626] Code: bad PC value
    [ 56.011652] ---[ end trace 7b64343fbdae8ef1 ]---

    Signed-off-by: Krzysztof Kozlowski
    Reviewed-by: Bartlomiej Zolnierkiewicz

    [for the nvec part]
    Reviewed-by: Marc Dietrich

    [for compal-laptop.c]
    Acked-by: Darren Hart

    [for the mfd part]
    Acked-by: Lee Jones

    [for the hid part]
    Acked-by: Jiri Kosina

    [for the acpi part]
    Acked-by: Rafael J. Wysocki

    Signed-off-by: Sebastian Reichel

    Krzysztof Kozlowski
     
  • Replace direct calls to power supply function attributes with wrappers.
    Wrappers provide safe access in case of unregistering the power
    supply (e.g. by removing the driver). Replace:
    - get_property -> power_supply_get_property
    - set_property -> power_supply_set_property
    - property_is_writeable -> power_supply_property_is_writeable

    Signed-off-by: Krzysztof Kozlowski
    Acked-by: Jonghwa Lee
    Acked-by: Pavel Machek
    Reviewed-by: Bartlomiej Zolnierkiewicz
    Reviewed-by: Sebastian Reichel
    Signed-off-by: Sebastian Reichel

    Krzysztof Kozlowski
     

16 Sep, 2014

1 commit


07 Sep, 2014

1 commit

  • Usually PMIC's come with coulomb counting mechanism which can be
    used to implement a Fuel Gauginig solution in Software itself.
    One of key input to these SW Fuel Gauge solutioons is the boot up
    parameters like boot voltage and boot current.

    This patch adds the VOLTAGE_BOOT and CURRENT_BOOT power supply attributes
    to report bootup voltage and current.

    This patch also adds CALIBRATE power supply attribute which useful is
    for calibrating the battery/coulomb counter.

    Signed-off-by: Ramakrishna Pallala
    Signed-off-by: Sebastian Reichel

    Ramakrishna Pallala
     

19 Jul, 2014

1 commit

  • Add new power supply properties for input current, charge termination
    current, min and max temperature

    POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature
    POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature

    POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT - input current limit programmed
    by charger. Indicates the input current for a charging source.

    POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT - Charge termination current used
    to detect the end of charge condition

    Signed-off-by: Jenny TC
    Acked-by: Pavel Machek
    Signed-off-by: Sebastian Reichel

    Jenny TC
     

10 Aug, 2013

1 commit


06 Jan, 2013

1 commit

  • As most of the charger chips come with two kinds of safety features
    related to timing:

    1. Watchdog Timer (interms of seconds/mins)
    2. Safety Timer (interms of hours)

    This patch adds these to fault causes in POWER_SUPPLY_PROP_HEALTH_* enums
    so that whenever there is either watchdog timeout or safety timer timeout
    driver could notify the user space accurately about the fault and will
    also be helpful for debug.

    Signed-off-by: Ramakrishna Pallala
    Signed-off-by: Anton Vorontsov

    Ramakrishna Pallala
     

18 Nov, 2012

1 commit


23 Aug, 2012

2 commits

  • There are different types of chargers avalibale like AC, Solar, USB,
    etc.. Even in USB we have different types SDP/DCP/CDP/ACA and all these
    chargers have different o/p ratings. For example SDP supports only 500mA
    of charge current whereas AC charger can support upto 8A or more.

    Similarly batteries also come with charge current and voltage ratings
    and these ratings vary depending on its capacity and the technology
    used.

    This patch adds two new power supply properties
    CONSTANT_CHARGE_CURRENT_MAX and CONSTANT_CHARGE_CURRENT_MAX.

    Signed-off-by: Ramakrishna Pallala
    Signed-off-by: Anton Vorontsov

    Ramakrishna Pallala
     
  • It is possible that users can use non-standard chargers or use invalid
    batteries especially with mobile devices.

    This patch adds a new power supply property called 'AUTHENTIC' to
    indicate this to the user(user space).

    Signed-off-by: Ramakrishna Pallala
    Signed-off-by: Anton Vorontsov

    Ramakrishna Pallala
     

14 Jul, 2012

1 commit

  • Minimum and maximum alerts on power supply properties will help or allow
    the user space to "proactively" create policies like connect/disconnect
    charger or stop/start the user apps based on capacity or temperature
    parameters.

    These parameters can be used to avoid unnecessary polling from user space
    and even from kernel space if the underlying HW can support INT triggers
    (ex: max17042/47).

    This patch adds the following power supply alert type properties:

    CAPACITY_ALERT_MIN
    CAPACITY_ALERT_MAX
    TEMP_ALERT_MIN
    TEMP_ALERT_MAX
    TEMP_AMBIENT_ALERT_MIN
    TEMP_AMBIENT_ALERT_MAX

    Signed-off-by: Ramakrishna Pallala
    Signed-off-by: Anton Vorontsov

    Ramakrishna Pallala
     

20 Jun, 2012

1 commit

  • Constant Charge Current(CC) is charging parameter which limit the
    maximum current which can be pumped into the battery during charge cycle.

    Constant Charge Voltage(CV) is also charging parameter which limit the
    maximum voltage that battery can reach during charge cycle.

    It is very common practice that at low or high temperatures we
    do not charge the batteries upto it's fullest charge voltage
    to avoid battery and user safety issues.

    These sysfs properties will be useful for debug and to implement
    certain user space policies like "Charging limited due to OverTemp".

    Signed-off-by: Ramakrishna Pallala
    Signed-off-by: Anton Vorontsov

    Ramakrishna Pallala
     

05 May, 2012

1 commit


12 Mar, 2012

1 commit

  • For files that are actively using linux/device.h, make sure
    that they call it out. This will allow us to clean up some
    of the implicit uses of linux/device.h within include/*
    without introducing build regressions.

    Yes, this was created by "cheating" -- i.e. the headers were
    cleaned up, and then the fallout was found and fixed, and then
    the two commits were reordered. This ensures we don't introduce
    build regressions into the git history.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

12 Jan, 2012

1 commit

  • * git://git.infradead.org/battery-2.6: (68 commits)
    power_supply: Mark da9052 driver as broken
    power_supply: Drop usage of nowarn variant of sysfs_create_link()
    s3c_adc_battery: Average over more than one adc sample
    power_supply: Add DA9052 battery driver
    isp1704_charger: Fix missing check
    jz4740-battery: Fix signedness bug
    power_supply: Assume mains power by default
    sbs-battery: Fix devicetree match table
    ARM: rx51: Add bq27200 i2c board info
    sbs-battery: Change power supply name
    devicetree-bindings: Propagate bq20z75->sbs rename to dt bindings
    devicetree-bindings: Add vendor entry for Smart Battery Systems
    sbs-battery: Rename internals to new name
    bq20z75: Rename to sbs-battery
    wm97xx_battery: Use DEFINE_MUTEX() for work_lock
    max8997_charger: Remove duplicate module.h
    lp8727_charger: Some minor fixes for the header
    lp8727_charger: Add header file
    power_supply: Convert drivers/power/* to use module_platform_driver()
    power_supply: Add "unknown" in power supply type
    ...

    Linus Torvalds
     

04 Jan, 2012

3 commits


10 Dec, 2011

1 commit

  • This adds a "scope" attribute to a power_supply, which indicates how
    much of the system it powers. It appears in sysfs as "scope" or in
    the uevent file as POWER_SUPPLY_SCOPE=. There are presently three
    possible values:
    Unknown - unknown power topology
    System - the power supply powers the whole system
    Device - it powers a specific device, or tree of devices

    A power supply which doesn't have a "scope" attribute should be assumed to
    have "System" scope.

    In general, usermode should assume that loss of all System-scoped power
    supplies will power off the whole system, but any single one is sufficient
    to power the system.

    Signed-off-by: Jeremy Fitzhardinge
    Cc: Richard Hughes

    Jeremy Fitzhardinge
     

01 Nov, 2011

1 commit

  • It was actually getting this before by a tangled mess of implict
    includes that is going to be cleaned up. Fix it now, so we don't
    get this after the cleanup.

    power_supply_sysfs.c: In function ‘power_supply_attr_is_visible’:
    power_supply_sysfs.c:184: error: ‘S_IRUSR’ undeclared (first use in this function)
    power_supply_sysfs.c:184: error: (Each undeclared identifier is reported only once
    power_supply_sysfs.c:184: error: for each function it appears in.)
    power_supply_sysfs.c:184: error: ‘S_IRGRP’ undeclared (first use in this function)
    power_supply_sysfs.c:184: error: ‘S_IROTH’ undeclared (first use in this function)
    power_supply_sysfs.c:196: error: ‘S_IWUSR’ undeclared (first use in this function)
    make[3]: *** [drivers/power/power_supply_sysfs.o] Error 1

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

23 Aug, 2011

1 commit


20 Aug, 2011

1 commit

  • Don't tell the system about the battery charger if it's not enabled, we
    can reasonably assume that if the charger is not enabled then no battery
    will ever be connected so reporting state is at best going to waste time
    and at worst going to cause confusing information in the UI.

    For simplicity and robustness we continue to register and handle interrupts
    from the charger.

    Signed-off-by: Mark Brown
    Signed-off-by: Anton Vorontsov

    Mark Brown
     

22 Feb, 2011

1 commit

  • Sometimes a driver can not report a meaningful value for a certain property
    and returns -ENODATA.

    Currently when generating a uevent and a property return -ENODATA it is
    treated as an error an no uevent is generated at all. This is not an
    desirable behavior.

    This patch adds a special case for -ENODATA and ignores properties which
    return this error code when generating the uevent.

    Signed-off-by: Lars-Peter Clausen
    Tested-by: Grazvydas Ignotas

    Lars-Peter Clausen
     

06 Oct, 2010

2 commits


25 May, 2010

1 commit

  • Commit 5f487cd34f4337f9bc27ca19da72a39d1b0a0ab4 (power_supply: Use
    attribute groups) causes a regression the power supply core does not
    export the 'type' attribute anymore.

    POWER_SUPPLY_PROP_TYPE is handled by the power supply core without the
    low-level driver, so power_supply_attr_is_visible() must always return
    the entry as readable.

    Reported-by: Rafael J. Wysocki
    Signed-off-by: Daniel Mack
    Tested-by: Rafael J. Wysocki
    Signed-off-by: Anton Vorontsov

    Daniel Mack
     

19 May, 2010

2 commits

  • This patch adds support for writeable power supply properties and
    exposes them as writeable to sysfs.

    A power supply implementation must implement two new function calls in
    order to use that feature:

    int set_property(struct power_supply *psy,
    enum power_supply_property psp,
    const union power_supply_propval *val);

    int property_is_writeable(struct power_supply *psy,
    enum power_supply_property psp);

    Signed-off-by: Daniel Mack
    Cc: David Woodhouse
    Cc: Alexey Starikovskiy
    Cc: Len Brown
    Cc: Mark Brown
    Cc: Matt Reimer
    Cc: Evgeniy Polyakov
    Cc: Tejun Heo
    Signed-off-by: Anton Vorontsov

    Daniel Mack
     
  • This fixes a race between power supply device and initial
    attributes creation, plus makes it possible to implement
    writable properties.

    [Daniel Mack - removed superflous return statement
    and dropped .mode attribute from POWER_SUPPLY_ATTR]

    Suggested-by: Greg KH
    Suggested-by: Kay Sievers
    Signed-off-by: Anton Vorontsov
    Tested-by: Daniel Mack

    Anton Vorontsov
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

16 Jan, 2010

1 commit


03 Dec, 2009

1 commit


02 Jul, 2009

1 commit


01 Jul, 2009

1 commit

  • This reverts commit 8efe444038a205e79b38b7ad03878824901849a8 and
    4cbc76eadf56399cd11fb736b33c53aec9caab8c.

    Richard@laptop.org was apparently using CAPACITY_LEVEL for debugging
    battery/EC problems, and was upset that it was removed. This readds it.

    Conflicts:

    Documentation/power_supply_class.txt

    Signed-off-by: Andres Salomon
    Signed-off-by: Anton Vorontsov

    Andres Salomon
     

28 Mar, 2009

1 commit


04 Jan, 2009

1 commit


20 Oct, 2008

1 commit

  • Tejun's commit 7b595756ec1f49e0049a9e01a1298d53a7faaa15 made sysfs
    attribute->owner unnecessary. But the field was left in the structure to
    ease the merge. It's been over a year since that change and it is now
    time to start killing attribute->owner along with its users - one arch at
    a time!

    This patch is attempt #1 to get rid of attribute->owner only for
    CONFIG_X86_64 or CONFIG_X86_32 . We will deal with other arches later on
    as and when possible - avr32 will be the next since that is something I
    can test. Compile (make allyesconfig / make allmodconfig / custom config)
    and boot tested.

    akpm: the idea is that we put the declaration of sttribute.owner inside
    `#ifndef CONFIG_X86'. But that proved to be too ambitious for now because
    new usages kept on turning up in subsystem trees.

    [akpm: remove the ifdef for now]
    Signed-off-by: Parag Warudkar
    Cc: Greg KH
    Cc: Ingo Molnar
    Cc: Tejun Heo
    Cc: Len Brown
    Cc: Jens Axboe
    Cc: Jean Delvare
    Cc: Roland Dreier
    Cc: David Brownell
    Cc: Alessandro Zummo
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Parag Warudkar