drivers/leds/leds-acer-a500.c
Source file repositories/reference/linux-study-clean/drivers/leds/leds-acer-a500.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/leds/leds-acer-a500.c- Extension
.c- Size
- 3512 bytes
- Lines
- 130
- Domain
- Driver Families
- Bucket
- drivers/leds
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/leds.hlinux/module.hlinux/platform_device.hlinux/regmap.h
Detected Declarations
struct a500_ledfunction a500_ec_led_brightness_setfunction a500_ec_leds_probe
Annotated Snippet
struct a500_led {
struct led_classdev cdev;
const struct reg_sequence *enable_seq;
struct a500_led *other;
struct regmap *rmap;
};
static const struct reg_sequence a500_ec_leds_reset_seq[] = {
REG_SEQ(REG_RESET_LEDS, 0x0, A500_EC_LED_DELAY_USEC),
REG_SEQ(REG_ANDROID_LEDS_OFF, 0x0, A500_EC_LED_DELAY_USEC),
};
static const struct reg_sequence a500_ec_white_led_enable_seq[] = {
REG_SEQ(REG_POWER_LED_ON, 0x0, A500_EC_LED_DELAY_USEC),
};
static const struct reg_sequence a500_ec_orange_led_enable_seq[] = {
REG_SEQ(REG_CHARGE_LED_ON, 0x0, A500_EC_LED_DELAY_USEC),
};
static int a500_ec_led_brightness_set(struct led_classdev *led_cdev,
enum led_brightness value)
{
struct a500_led *led = container_of(led_cdev, struct a500_led, cdev);
struct reg_sequence control_seq[2];
unsigned int num_regs = 1;
if (value) {
control_seq[0] = led->enable_seq[0];
} else {
/*
* There is no separate controls which can disable LEDs
* individually, there is only RESET_LEDS command that turns
* off both LEDs.
*
* RESET_LEDS turns off both LEDs, thus restore other LED if
* it's turned ON.
*/
if (led->other->cdev.brightness)
num_regs = 2;
control_seq[0] = a500_ec_leds_reset_seq[0];
control_seq[1] = led->other->enable_seq[0];
}
return regmap_multi_reg_write(led->rmap, control_seq, num_regs);
}
static int a500_ec_leds_probe(struct platform_device *pdev)
{
struct a500_led *white_led, *orange_led;
struct regmap *rmap;
int err;
rmap = dev_get_regmap(pdev->dev.parent, "KB930");
if (!rmap)
return -EINVAL;
/* reset and turn off LEDs */
regmap_multi_reg_write(rmap, a500_ec_leds_reset_seq, 2);
white_led = devm_kzalloc(&pdev->dev, sizeof(*white_led), GFP_KERNEL);
if (!white_led)
return -ENOMEM;
white_led->cdev.name = "power:white";
white_led->cdev.brightness_set_blocking = a500_ec_led_brightness_set;
white_led->cdev.flags = LED_CORE_SUSPENDRESUME;
white_led->cdev.max_brightness = 1;
white_led->enable_seq = a500_ec_white_led_enable_seq;
white_led->rmap = rmap;
orange_led = devm_kzalloc(&pdev->dev, sizeof(*orange_led), GFP_KERNEL);
if (!orange_led)
return -ENOMEM;
orange_led->cdev.name = "power:orange";
orange_led->cdev.brightness_set_blocking = a500_ec_led_brightness_set;
orange_led->cdev.flags = LED_CORE_SUSPENDRESUME;
orange_led->cdev.max_brightness = 1;
orange_led->enable_seq = a500_ec_orange_led_enable_seq;
orange_led->rmap = rmap;
white_led->other = orange_led;
orange_led->other = white_led;
err = devm_led_classdev_register(&pdev->dev, &white_led->cdev);
if (err) {
dev_err(&pdev->dev, "failed to register white LED\n");
return err;
Annotation
- Immediate include surface: `linux/leds.h`, `linux/module.h`, `linux/platform_device.h`, `linux/regmap.h`.
- Detected declarations: `struct a500_led`, `function a500_ec_led_brightness_set`, `function a500_ec_leds_probe`.
- Atlas domain: Driver Families / drivers/leds.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.