| Message ID | 20220919155916.1044219-1-rrangel@chromium.org |
|---|---|
| Headers | show |
| Series | acpi: i2c: Use SharedAndWake and ExclusiveAndWake to enable wake irq | expand |
On Mon, Sep 19, 2022 at 5:59 PM Raul E Rangel <rrangel@chromium.org> wrote: > > Today, i2c drivers are making the assumption that their IRQs can also > be used as wake IRQs. This isn't always the case and it can lead to > spurious wakes. This has recently started to affect AMD Chromebooks. > With the introduction of > d62bd5ce12d7 ("pinctrl: amd: Implement irq_set_wake"), the AMD GPIO > controller gained the capability to set the wake bit on each GPIO. The > ACPI specification defines two ways to inform the system if a device is > wake capable: > 1) The _PRW object defines the GPE that can be used to wake the system. > 2) Setting ExclusiveAndWake or SharedAndWake in the _CRS GpioInt. > > Currently only the first method is supported. The i2c drivers don't have > any indication that the IRQ is wake capable, so they guess. This causes > spurious interrupts, for example: > * We have an ACPI HID device that has `_PR0` and `_PR3`. It doesn't have > `_PRW` or `ExclusiveAndWake` so that means the device can't wake the > system. > * The IRQ line is active level low for this device and is pulled up by > the power resource defined in `_PR0`/`_PR3`. > * The i2c driver will (incorrectly) arm the GPIO for wake by calling > `enable_irq_wake` as part of its suspend hook. > * ACPI will power down the device since it doesn't have a wake GPE > associated with it. > * When the device is powered down, the IRQ line will drop, and it will > trigger a wake event. > > See the following debug log: > [ 42.335804] PM: Suspending system (s2idle) > [ 42.340186] amd_gpio AMD0030:00: RX: Setting wake for pin 89 to enable > [ 42.467736] power-0416 __acpi_power_off : Power resource [PR00] turned off > [ 42.467739] device_pm-0280 device_set_power : Device [H05D] transitioned to D3cold > [ 42.475210] PM: pm_system_irq_wakeup: 11 triggered pinctrl_amd > [ 42.535293] PM: Wakeup unrelated to ACPI SCI > [ 42.535294] PM: resume from suspend-to-idle > > In order to fix this, we need to take into account the wake capable bit > defined on the Interrupt/GpioInt. This is accomplished by: > * Migrating some of the i2c drivers over to using the PM subsystem to > manage the wake IRQ. > * Expose the wake_capable bit from the ACPI Interrupt/GpioInt resource > to the i2c core. > * Use the wake_capable bit in the i2c core to call > `dev_pm_set_wake_irq`. This reuses the existing device tree flow. > * Make the i2c drivers stop calling `dev_pm_set_wake_irq` since it's now > handled by the i2c core. > * Make the ACPI device PM system aware of the wake_irq. This is > necessary so the device doesn't incorrectly get powered down when a > wake_irq is enabled. > > I've tested this code with various combinations of having _PRW, > ExclusiveAndWake and power resources all defined or not defined, but it > would be great if others could test this out on their hardware. > > I'm sure this will surface some devices where the IRQs were not > correctly marked as wake capable. Ideally the firmware can be fixed, but > if not we can work around this in the kernel by providing a board > specific `struct i2c_board_info` with the `I2C_CLIENT_WAKE` flag set. > See `chromeos_laptop.c` for an example of matching DMI properties and > setting the `I2C_CLIENT_WAKE` override. > > Thanks, > Raul > > Changes in v4: > - Added Reviewed-by > - Reformatted with 96 char limit > - Removed unnecessary !! > - Removed unrelated white space change > - Renamed i2c_acpi_add_resource to i2c_acpi_add_irq_resource > - Expanded logic in i2c_acpi_add_i2c_resource to make it easier to read > > Changes in v3: > - Kept `acpi_dev_gpio_irq_get_by` unchanged to avoid having to touch > unrelated drivers. > - Converted wake_capable parameter to bool. > - Fixed bad indent > - Convert wake_capable to bool > - Only update wake_capable pointer once > - Move wake_capable local into local block > > Changes in v2: > - Added elants_i2c to series > - Added raydium_ts_i2c to series > - Fixed call site in mlxbf_gige_probe > - Added ability to extract wake bit from Interrupt/IRQ resources > - Look at wake_cabple bit for IRQ/Interrupt resources > - I chose not to keep the legacy code around since systems without DT or ACPI should be rare. > > Raul E Rangel (13): > HID: i2c-hid: Use PM subsystem to manage wake irq > Input: elan_i2c - Use PM subsystem to manage wake irq > Input: elants_i2c - Use PM subsystem to manage wake irq > Input: raydium_ts_i2c - Use PM subsystem to manage wake irq > gpiolib: acpi: Add wake_capable variants of acpi_dev_gpio_irq_get > ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags > i2c: acpi: Use ACPI wake capability bit to set wake_irq > ACPI: PM: Take wake IRQ into consideration when entering > suspend-to-idle > HID: i2c-hid: acpi: Stop setting wakeup_capable > HID: i2c-hid: Don't set wake_capable and wake_irq > Input: elan_i2c - Don't set wake_capable and wake_irq > Input: elants_i2c - Don't set wake_capable and wake_irq > Input: raydium_ts_i2c - Don't set wake_capable and wake_irq > > drivers/acpi/device_pm.c | 19 +++++++++-- > drivers/acpi/irq.c | 8 +++-- > drivers/acpi/resource.c | 23 ++++++++++---- > drivers/gpio/gpiolib-acpi.c | 15 +++++++-- > drivers/gpio/gpiolib-acpi.h | 2 ++ > drivers/hid/i2c-hid/i2c-hid-acpi.c | 5 --- > drivers/hid/i2c-hid/i2c-hid-core.c | 24 ++------------ > drivers/i2c/i2c-core-acpi.c | 37 ++++++++++++++++------ > drivers/i2c/i2c-core-base.c | 6 +++- > drivers/i2c/i2c-core.h | 4 +-- > drivers/input/mouse/elan_i2c_core.c | 15 +-------- > drivers/input/touchscreen/elants_i2c.c | 13 ++------ > drivers/input/touchscreen/raydium_i2c_ts.c | 7 +--- > drivers/pnp/pnpacpi/rsparser.c | 7 ++-- > include/linux/acpi.h | 23 +++++++++++--- > include/linux/ioport.h | 3 +- > 16 files changed, 117 insertions(+), 94 deletions(-) > For the HID patches (1, 9, 10): Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Feel free to take those through whatever tree is the best, we don't have anything scheduled for i2c-hid for 6.1 right now. Cheers, Benjamin
On Mon, Sep 19, 2022 at 09:59:09AM -0600, Raul E Rangel wrote: > Device tree already has a mechanism to pass the wake_irq. It does this > by looking for the wakeup-source property and setting the > I2C_CLIENT_WAKE flag. This CL adds the ACPI equivalent. It uses the > ACPI interrupt wake flag to determine if the interrupt can be used to > wake the system. Previously the i2c drivers had to make assumptions and > blindly enable the wake IRQ. This can cause spurious wake events. e.g., > If there is a device with an Active Low interrupt and the device gets > powered off while suspending, the interrupt line will go low since it's > no longer powered and wakes the system. For this reason we should > respect the board designers wishes and honor the wake bit defined on the > interrupt. ... > + if (irq_ctx.irq == -ENOENT) > + irq_ctx.irq = acpi_dev_gpio_irq_wake_get(adev, 0, &irq_ctx.wake_capable); I just realized, that there is an inconsistency on how we fill the wake_capable parameter. In some cases we check for IRQ for an error condition (IRQ not found) and in some the wake_capable still be filled. Here the best approach I believe is to add if (irq_ctx.irq < 0) return irq_ctx.irq; I.o.w. we apply the rule "do not fill the output parameters when it's known to be an error condition". > + if (wake_capable) > + *wake_capable = irq_ctx.wake_capable; > + return irq_ctx.irq;
On Tue, Sep 20, 2022 at 6:32 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Sep 19, 2022 at 09:59:09AM -0600, Raul E Rangel wrote: > > Device tree already has a mechanism to pass the wake_irq. It does this > > by looking for the wakeup-source property and setting the > > I2C_CLIENT_WAKE flag. This CL adds the ACPI equivalent. It uses the > > ACPI interrupt wake flag to determine if the interrupt can be used to > > wake the system. Previously the i2c drivers had to make assumptions and > > blindly enable the wake IRQ. This can cause spurious wake events. e.g., > > If there is a device with an Active Low interrupt and the device gets > > powered off while suspending, the interrupt line will go low since it's > > no longer powered and wakes the system. For this reason we should > > respect the board designers wishes and honor the wake bit defined on the > > interrupt. > > ... > > > + if (irq_ctx.irq == -ENOENT) > > + irq_ctx.irq = acpi_dev_gpio_irq_wake_get(adev, 0, &irq_ctx.wake_capable); > > I just realized, that there is an inconsistency on how we fill the wake_capable > parameter. In some cases we check for IRQ for an error condition (IRQ not found) > and in some the wake_capable still be filled. > > Here the best approach I believe is to add > > if (irq_ctx.irq < 0) > return irq_ctx.irq; > > I.o.w. we apply the rule "do not fill the output parameters when it's known > to be an error condition". > > > + if (wake_capable) > > + *wake_capable = irq_ctx.wake_capable; > > > + return irq_ctx.irq; > I applied the following: diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c index ba64e505183595..1618f5619d5ed9 100644 --- a/drivers/i2c/i2c-core-acpi.c +++ b/drivers/i2c/i2c-core-acpi.c @@ -220,7 +220,7 @@ int i2c_acpi_get_irq(struct i2c_client *client, bool *wake_capable) if (irq_ctx.irq == -ENOENT) irq_ctx.irq = acpi_dev_gpio_irq_wake_get(adev, 0, &irq_ctx.wake_capable); - if (wake_capable) + if (irq_ctx.irq > 0 && wake_capable) *wake_capable = irq_ctx.wake_capable; return irq_ctx.irq; Thanks!
On Tue, Sep 20, 2022 at 4:43 AM Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote: > > On Mon, Sep 19, 2022 at 5:59 PM Raul E Rangel <rrangel@chromium.org> wrote: > > > > Today, i2c drivers are making the assumption that their IRQs can also > > be used as wake IRQs. This isn't always the case and it can lead to > > spurious wakes. This has recently started to affect AMD Chromebooks. > > With the introduction of > > d62bd5ce12d7 ("pinctrl: amd: Implement irq_set_wake"), the AMD GPIO > > controller gained the capability to set the wake bit on each GPIO. The > > ACPI specification defines two ways to inform the system if a device is > > wake capable: > > 1) The _PRW object defines the GPE that can be used to wake the system. > > 2) Setting ExclusiveAndWake or SharedAndWake in the _CRS GpioInt. > > > > Currently only the first method is supported. The i2c drivers don't have > > any indication that the IRQ is wake capable, so they guess. This causes > > spurious interrupts, for example: > > * We have an ACPI HID device that has `_PR0` and `_PR3`. It doesn't have > > `_PRW` or `ExclusiveAndWake` so that means the device can't wake the > > system. > > * The IRQ line is active level low for this device and is pulled up by > > the power resource defined in `_PR0`/`_PR3`. > > * The i2c driver will (incorrectly) arm the GPIO for wake by calling > > `enable_irq_wake` as part of its suspend hook. > > * ACPI will power down the device since it doesn't have a wake GPE > > associated with it. > > * When the device is powered down, the IRQ line will drop, and it will > > trigger a wake event. > > > > See the following debug log: > > [ 42.335804] PM: Suspending system (s2idle) > > [ 42.340186] amd_gpio AMD0030:00: RX: Setting wake for pin 89 to enable > > [ 42.467736] power-0416 __acpi_power_off : Power resource [PR00] turned off > > [ 42.467739] device_pm-0280 device_set_power : Device [H05D] transitioned to D3cold > > [ 42.475210] PM: pm_system_irq_wakeup: 11 triggered pinctrl_amd > > [ 42.535293] PM: Wakeup unrelated to ACPI SCI > > [ 42.535294] PM: resume from suspend-to-idle > > > > In order to fix this, we need to take into account the wake capable bit > > defined on the Interrupt/GpioInt. This is accomplished by: > > * Migrating some of the i2c drivers over to using the PM subsystem to > > manage the wake IRQ. > > * Expose the wake_capable bit from the ACPI Interrupt/GpioInt resource > > to the i2c core. > > * Use the wake_capable bit in the i2c core to call > > `dev_pm_set_wake_irq`. This reuses the existing device tree flow. > > * Make the i2c drivers stop calling `dev_pm_set_wake_irq` since it's now > > handled by the i2c core. > > * Make the ACPI device PM system aware of the wake_irq. This is > > necessary so the device doesn't incorrectly get powered down when a > > wake_irq is enabled. > > > > I've tested this code with various combinations of having _PRW, > > ExclusiveAndWake and power resources all defined or not defined, but it > > would be great if others could test this out on their hardware. > > > > I'm sure this will surface some devices where the IRQs were not > > correctly marked as wake capable. Ideally the firmware can be fixed, but > > if not we can work around this in the kernel by providing a board > > specific `struct i2c_board_info` with the `I2C_CLIENT_WAKE` flag set. > > See `chromeos_laptop.c` for an example of matching DMI properties and > > setting the `I2C_CLIENT_WAKE` override. > > > > Thanks, > > Raul > > > > Changes in v4: > > - Added Reviewed-by > > - Reformatted with 96 char limit > > - Removed unnecessary !! > > - Removed unrelated white space change > > - Renamed i2c_acpi_add_resource to i2c_acpi_add_irq_resource > > - Expanded logic in i2c_acpi_add_i2c_resource to make it easier to read > > > > Changes in v3: > > - Kept `acpi_dev_gpio_irq_get_by` unchanged to avoid having to touch > > unrelated drivers. > > - Converted wake_capable parameter to bool. > > - Fixed bad indent > > - Convert wake_capable to bool > > - Only update wake_capable pointer once > > - Move wake_capable local into local block > > > > Changes in v2: > > - Added elants_i2c to series > > - Added raydium_ts_i2c to series > > - Fixed call site in mlxbf_gige_probe > > - Added ability to extract wake bit from Interrupt/IRQ resources > > - Look at wake_cabple bit for IRQ/Interrupt resources > > - I chose not to keep the legacy code around since systems without DT or ACPI should be rare. > > > > Raul E Rangel (13): > > HID: i2c-hid: Use PM subsystem to manage wake irq > > Input: elan_i2c - Use PM subsystem to manage wake irq > > Input: elants_i2c - Use PM subsystem to manage wake irq > > Input: raydium_ts_i2c - Use PM subsystem to manage wake irq > > gpiolib: acpi: Add wake_capable variants of acpi_dev_gpio_irq_get > > ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags > > i2c: acpi: Use ACPI wake capability bit to set wake_irq > > ACPI: PM: Take wake IRQ into consideration when entering > > suspend-to-idle > > HID: i2c-hid: acpi: Stop setting wakeup_capable > > HID: i2c-hid: Don't set wake_capable and wake_irq > > Input: elan_i2c - Don't set wake_capable and wake_irq > > Input: elants_i2c - Don't set wake_capable and wake_irq > > Input: raydium_ts_i2c - Don't set wake_capable and wake_irq > > > > drivers/acpi/device_pm.c | 19 +++++++++-- > > drivers/acpi/irq.c | 8 +++-- > > drivers/acpi/resource.c | 23 ++++++++++---- > > drivers/gpio/gpiolib-acpi.c | 15 +++++++-- > > drivers/gpio/gpiolib-acpi.h | 2 ++ > > drivers/hid/i2c-hid/i2c-hid-acpi.c | 5 --- > > drivers/hid/i2c-hid/i2c-hid-core.c | 24 ++------------ > > drivers/i2c/i2c-core-acpi.c | 37 ++++++++++++++++------ > > drivers/i2c/i2c-core-base.c | 6 +++- > > drivers/i2c/i2c-core.h | 4 +-- > > drivers/input/mouse/elan_i2c_core.c | 15 +-------- > > drivers/input/touchscreen/elants_i2c.c | 13 ++------ > > drivers/input/touchscreen/raydium_i2c_ts.c | 7 +--- > > drivers/pnp/pnpacpi/rsparser.c | 7 ++-- > > include/linux/acpi.h | 23 +++++++++++--- > > include/linux/ioport.h | 3 +- > > 16 files changed, 117 insertions(+), 94 deletions(-) > > > > For the HID patches (1, 9, 10): > Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> > > Feel free to take those through whatever tree is the best, we don't > have anything scheduled for i2c-hid for 6.1 right now. > > Cheers, > Benjamin > Great thanks! I'll include your Acked-By in the next round.
On Wed, Sep 21, 2022 at 09:18:34AM -0600, Raul Rangel wrote: > On Tue, Sep 20, 2022 at 6:32 AM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Sep 19, 2022 at 09:59:09AM -0600, Raul E Rangel wrote: ... > > > + if (irq_ctx.irq == -ENOENT) > > > + irq_ctx.irq = acpi_dev_gpio_irq_wake_get(adev, 0, &irq_ctx.wake_capable); > > > > I just realized, that there is an inconsistency on how we fill the wake_capable > > parameter. In some cases we check for IRQ for an error condition (IRQ not found) > > and in some the wake_capable still be filled. > > > > Here the best approach I believe is to add > > > > if (irq_ctx.irq < 0) > > return irq_ctx.irq; > > > > I.o.w. we apply the rule "do not fill the output parameters when it's known > > to be an error condition". > > > > > + if (wake_capable) > > > + *wake_capable = irq_ctx.wake_capable; > > > > > + return irq_ctx.irq; > > > > I applied the following: > diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c > index ba64e505183595..1618f5619d5ed9 100644 > --- a/drivers/i2c/i2c-core-acpi.c > +++ b/drivers/i2c/i2c-core-acpi.c > @@ -220,7 +220,7 @@ int i2c_acpi_get_irq(struct i2c_client *client, > bool *wake_capable) > if (irq_ctx.irq == -ENOENT) > irq_ctx.irq = acpi_dev_gpio_irq_wake_get(adev, 0, > &irq_ctx.wake_capable); > > - if (wake_capable) > + if (irq_ctx.irq > 0 && wake_capable) > *wake_capable = irq_ctx.wake_capable; > > return irq_ctx.irq; While it's working solution it is not so flexible since basically any addition of a new code will require if (irq > 0), that's why I'm in favour of my proposal rather than yours approach.
Today, i2c drivers are making the assumption that their IRQs can also be used as wake IRQs. This isn't always the case and it can lead to spurious wakes. This has recently started to affect AMD Chromebooks. With the introduction of d62bd5ce12d7 ("pinctrl: amd: Implement irq_set_wake"), the AMD GPIO controller gained the capability to set the wake bit on each GPIO. The ACPI specification defines two ways to inform the system if a device is wake capable: 1) The _PRW object defines the GPE that can be used to wake the system. 2) Setting ExclusiveAndWake or SharedAndWake in the _CRS GpioInt. Currently only the first method is supported. The i2c drivers don't have any indication that the IRQ is wake capable, so they guess. This causes spurious interrupts, for example: * We have an ACPI HID device that has `_PR0` and `_PR3`. It doesn't have `_PRW` or `ExclusiveAndWake` so that means the device can't wake the system. * The IRQ line is active level low for this device and is pulled up by the power resource defined in `_PR0`/`_PR3`. * The i2c driver will (incorrectly) arm the GPIO for wake by calling `enable_irq_wake` as part of its suspend hook. * ACPI will power down the device since it doesn't have a wake GPE associated with it. * When the device is powered down, the IRQ line will drop, and it will trigger a wake event. See the following debug log: [ 42.335804] PM: Suspending system (s2idle) [ 42.340186] amd_gpio AMD0030:00: RX: Setting wake for pin 89 to enable [ 42.467736] power-0416 __acpi_power_off : Power resource [PR00] turned off [ 42.467739] device_pm-0280 device_set_power : Device [H05D] transitioned to D3cold [ 42.475210] PM: pm_system_irq_wakeup: 11 triggered pinctrl_amd [ 42.535293] PM: Wakeup unrelated to ACPI SCI [ 42.535294] PM: resume from suspend-to-idle In order to fix this, we need to take into account the wake capable bit defined on the Interrupt/GpioInt. This is accomplished by: * Migrating some of the i2c drivers over to using the PM subsystem to manage the wake IRQ. * Expose the wake_capable bit from the ACPI Interrupt/GpioInt resource to the i2c core. * Use the wake_capable bit in the i2c core to call `dev_pm_set_wake_irq`. This reuses the existing device tree flow. * Make the i2c drivers stop calling `dev_pm_set_wake_irq` since it's now handled by the i2c core. * Make the ACPI device PM system aware of the wake_irq. This is necessary so the device doesn't incorrectly get powered down when a wake_irq is enabled. I've tested this code with various combinations of having _PRW, ExclusiveAndWake and power resources all defined or not defined, but it would be great if others could test this out on their hardware. I'm sure this will surface some devices where the IRQs were not correctly marked as wake capable. Ideally the firmware can be fixed, but if not we can work around this in the kernel by providing a board specific `struct i2c_board_info` with the `I2C_CLIENT_WAKE` flag set. See `chromeos_laptop.c` for an example of matching DMI properties and setting the `I2C_CLIENT_WAKE` override. Thanks, Raul Changes in v4: - Added Reviewed-by - Reformatted with 96 char limit - Removed unnecessary !! - Removed unrelated white space change - Renamed i2c_acpi_add_resource to i2c_acpi_add_irq_resource - Expanded logic in i2c_acpi_add_i2c_resource to make it easier to read Changes in v3: - Kept `acpi_dev_gpio_irq_get_by` unchanged to avoid having to touch unrelated drivers. - Converted wake_capable parameter to bool. - Fixed bad indent - Convert wake_capable to bool - Only update wake_capable pointer once - Move wake_capable local into local block Changes in v2: - Added elants_i2c to series - Added raydium_ts_i2c to series - Fixed call site in mlxbf_gige_probe - Added ability to extract wake bit from Interrupt/IRQ resources - Look at wake_cabple bit for IRQ/Interrupt resources - I chose not to keep the legacy code around since systems without DT or ACPI should be rare. Raul E Rangel (13): HID: i2c-hid: Use PM subsystem to manage wake irq Input: elan_i2c - Use PM subsystem to manage wake irq Input: elants_i2c - Use PM subsystem to manage wake irq Input: raydium_ts_i2c - Use PM subsystem to manage wake irq gpiolib: acpi: Add wake_capable variants of acpi_dev_gpio_irq_get ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags i2c: acpi: Use ACPI wake capability bit to set wake_irq ACPI: PM: Take wake IRQ into consideration when entering suspend-to-idle HID: i2c-hid: acpi: Stop setting wakeup_capable HID: i2c-hid: Don't set wake_capable and wake_irq Input: elan_i2c - Don't set wake_capable and wake_irq Input: elants_i2c - Don't set wake_capable and wake_irq Input: raydium_ts_i2c - Don't set wake_capable and wake_irq drivers/acpi/device_pm.c | 19 +++++++++-- drivers/acpi/irq.c | 8 +++-- drivers/acpi/resource.c | 23 ++++++++++---- drivers/gpio/gpiolib-acpi.c | 15 +++++++-- drivers/gpio/gpiolib-acpi.h | 2 ++ drivers/hid/i2c-hid/i2c-hid-acpi.c | 5 --- drivers/hid/i2c-hid/i2c-hid-core.c | 24 ++------------ drivers/i2c/i2c-core-acpi.c | 37 ++++++++++++++++------ drivers/i2c/i2c-core-base.c | 6 +++- drivers/i2c/i2c-core.h | 4 +-- drivers/input/mouse/elan_i2c_core.c | 15 +-------- drivers/input/touchscreen/elants_i2c.c | 13 ++------ drivers/input/touchscreen/raydium_i2c_ts.c | 7 +--- drivers/pnp/pnpacpi/rsparser.c | 7 ++-- include/linux/acpi.h | 23 +++++++++++--- include/linux/ioport.h | 3 +- 16 files changed, 117 insertions(+), 94 deletions(-)