Re: [PATCH v4 2/3] leds: sy7802: Add support for Silergy SY7802 flash LED controller

2024-06-24 Thread Lee Jones
On Sat, 22 Jun 2024, André Apitzsch wrote:

> Hello Lee,
> 
> Am Freitag, dem 21.06.2024 um 11:26 +0100 schrieb Lee Jones:
> > On Sun, 16 Jun 2024, André Apitzsch via B4 Relay wrote:
> > 
> > > From: André Apitzsch 
> > > 
> > > The SY7802 is a current-regulated charge pump which can regulate
> > > two
> > > current levels for Flash and Torch modes.
> > > 
> > > It is a high-current synchronous boost converter with 2-channel
> > > high
> > > side current sources. Each channel is able to deliver 900mA
> > > current.
> > > 
> > > Signed-off-by: André Apitzsch 
> > > ---
> > >  drivers/leds/flash/Kconfig   |  11 +
> > >  drivers/leds/flash/Makefile  |   1 +
> > >  drivers/leds/flash/leds-sy7802.c | 542
> > > +++
> > >  3 files changed, 554 insertions(+)
> > 
> > Generally very nice.
> > 
> > Just a couple of teensy nits to fix then add my and resubmit please.
> > 
> > Acked-by: Lee Jones 
> > 
> > > [...]
> > > diff --git a/drivers/leds/flash/leds-sy7802.c
> > > b/drivers/leds/flash/leds-sy7802.c
> > > new file mode 100644
> > > index ..c4bea55a62d0
> > > --- /dev/null
> > > +++ b/drivers/leds/flash/leds-sy7802.c
> > > @@ -0,0 +1,542 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Silergy SY7802 flash LED driver with I2C interface
> > 
> > "an I2C interface"
> > 
> > Or
> > 
> > "I2C interfaces"
> > 
> > > + * Copyright 2024 André Apitzsch 
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#define SY7802_MAX_LEDS 2
> > > +#define SY7802_LED_JOINT 2
> > > +
> > > +#define SY7802_REG_ENABLE0x10
> > > +#define SY7802_REG_TORCH_BRIGHTNESS  0xa0
> > > +#define SY7802_REG_FLASH_BRIGHTNESS  0xb0
> > > +#define SY7802_REG_FLASH_DURATION0xc0
> > > +#define SY7802_REG_FLAGS 0xd0
> > > +#define SY7802_REG_CONFIG_1  0xe0
> > > +#define SY7802_REG_CONFIG_2  0xf0
> > > +#define SY7802_REG_VIN_MONITOR   0x80
> > > +#define SY7802_REG_LAST_FLASH0x81
> > > +#define SY7802_REG_VLED_MONITOR  0x30
> > > +#define SY7802_REG_ADC_DELAY 0x31
> > > +#define SY7802_REG_DEV_ID0xff
> > > +
> > > +#define SY7802_MODE_OFF  0
> > > +#define SY7802_MODE_TORCH2
> > > +#define SY7802_MODE_FLASH3
> > > +#define SY7802_MODE_MASK GENMASK(1, 0)
> > > +
> > > +#define SY7802_LEDS_SHIFT3
> > > +#define SY7802_LEDS_MASK(_id)(BIT(_id) << SY7802_LEDS_SHIFT)
> > > +#define SY7802_LEDS_MASK_ALL (SY7802_LEDS_MASK(0) |
> > > SY7802_LEDS_MASK(1))
> > > +
> > > +#define SY7802_TORCH_CURRENT_SHIFT   3
> > > +#define SY7802_TORCH_CURRENT_MASK(_id) \
> > > + (GENMASK(2, 0) << (SY7802_TORCH_CURRENT_SHIFT * (_id)))
> > > +#define SY7802_TORCH_CURRENT_MASK_ALL \
> > > + (SY7802_TORCH_CURRENT_MASK(0) |
> > > SY7802_TORCH_CURRENT_MASK(1))
> > > +
> > > +#define SY7802_FLASH_CURRENT_SHIFT   4
> > > +#define SY7802_FLASH_CURRENT_MASK(_id) \
> > > + (GENMASK(3, 0) << (SY7802_FLASH_CURRENT_SHIFT * (_id)))
> > > +#define SY7802_FLASH_CURRENT_MASK_ALL \
> > > + (SY7802_FLASH_CURRENT_MASK(0) |
> > > SY7802_FLASH_CURRENT_MASK(1))
> > > +
> > > +#define SY7802_TIMEOUT_DEFAULT_US512000U
> > > +#define SY7802_TIMEOUT_MIN_US32000U
> > > +#define SY7802_TIMEOUT_MAX_US1024000U
> > > +#define SY7802_TIMEOUT_STEPSIZE_US   32000U
> > > +
> > > +#define SY7802_TORCH_BRIGHTNESS_MAX 8
> > > +
> > > +#define SY7802_FLASH_BRIGHTNESS_DEFAULT  14
> > > +#define SY7802_FLASH_BRIGHTNESS_MIN  0
> > > +#define SY7802_FLASH_BRIGHTNESS_MAX  15
> > > +#define SY7802_FLASH_BRIGHTNESS_STEP 1
> > > +
> > > +#define SY7802_FLAG_TIMEOUT  BIT(0)
> > > +#define SY7802_FLAG_THERMAL_SHUTDOWN BIT(1)
> > > +#define SY7802_FLAG_LED_FAULTBIT(2)
> > > +#define SY7802_FLAG_TX1_INTERRUPTBIT(3)
> > > +#define SY7802_FLAG_TX2_INTERRUPTBIT(4)
> > > +#define SY7802_FLAG_LED_THERMAL_FAULTBIT(5)
> > > +#define SY7802_FLAG_FLASH_INPUT_VOLTAGE_LOW  BIT(6)
> > > +#define SY7802_FLAG_INPUT_VOLTAGE_LOWBIT(7)
> > > +
> > > +#define SY7802_CHIP_ID   0x51
> > > +
> > > +static const struct reg_default sy7802_regmap_defs[] = {
> > > + { SY7802_REG_ENABLE, SY7802_LEDS_MASK_ALL },
> > > + { SY7802_REG_TORCH_BRIGHTNESS, 0x92 },
> > > + { SY7802_REG_FLASH_BRIGHTNESS,
> > > SY7802_FLASH_BRIGHTNESS_DEFAULT |
> > > + SY7802_FLASH_BRIGHTNESS_DEFAULT <<
> > > SY7802_FLASH_CURRENT_SHIFT },
> > > + { SY7802_REG_FLASH_DURATION, 0x6f },
> > > + { SY7802_REG_FLAGS, 0x0 },
> > > + { SY7802_REG_CONFIG_1, 0x68 },
> > > + { SY7802_REG_CONFIG_2, 0xf0 },
> > 
> > Not your fault, but this interface is frustrating since we have no
> > idea
> > what these register values mean.  IMHO, they should be defined and
> > ORed

Re: [PATCH] powerpc/pseries: Whitelist dtl slub object for copying to userspace

2024-06-24 Thread Michael Ellerman
On Fri, 14 Jun 2024 23:08:44 +0530, Anjali K wrote:
> Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
> results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
> shown below.
> 
> kernel BUG at mm/usercopy.c:102!
> Oops: Exception in kernel mode, sig: 5 [#1]
> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
> scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror 
> dm_region_hash dm_log dm_mod fuse
> CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
> Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf06 
> of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
> NIP:  c05d23d4 LR: c05d23d0 CTR: 006ee6f8
> REGS: c00120c078c0 TRAP: 0700   Not tainted  (6.10.0-rc3)
> MSR:  80029033   CR: 2828220f  XER: 000e
> CFAR: c01fdc80 IRQMASK: 0
> [ ... GPRs omitted ... ]
> NIP [c05d23d4] usercopy_abort+0x78/0xb0
> LR [c05d23d0] usercopy_abort+0x74/0xb0
> Call Trace:
>  usercopy_abort+0x74/0xb0 (unreliable)
>  __check_heap_object+0xf8/0x120
>  check_heap_object+0x218/0x240
>  __check_object_size+0x84/0x1a4
>  dtl_file_read+0x17c/0x2c4
>  full_proxy_read+0x8c/0x110
>  vfs_read+0xdc/0x3a0
>  ksys_read+0x84/0x144
>  system_call_exception+0x124/0x330
>  system_call_vectored_common+0x15c/0x2ec
> --- interrupt: 3000 at 0x7fff81f3ab34
> 
> [...]

Applied to powerpc/fixes.

[1/1] powerpc/pseries: Whitelist dtl slub object for copying to userspace
  https://git.kernel.org/powerpc/c/1a14150e1656f7a332a943154fc486504db4d586

cheers



Re: [PATCH] arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI first

2024-06-24 Thread Will Deacon
On Fri, May 17, 2024 at 01:01:51PM -0700, Doug Anderson wrote:
> On Fri, Apr 12, 2024 at 6:55 AM Will Deacon  wrote:
> > On Thu, Dec 07, 2023 at 05:02:56PM -0800, Douglas Anderson wrote:
> > > In order to do this we also need a slight change in the way we keep
> > > track of which CPUs still need to be stopped. We need to know
> > > specifically which CPUs haven't stopped yet when we fall back to NMI
> > > but in the "crash stop" case the "cpu_online_mask" isn't updated as
> > > CPUs go down. This is why that code path had an atomic of the number
> > > of CPUs left. We'll solve this by making the cpumask into a
> > > global. This has a potential memory implication--with NR_CPUs = 4096
> > > this is 4096/8 = 512 bytes of globals. On the upside in that same case
> > > we take 512 bytes off the stack which could potentially have made the
> > > stop code less reliable. It can be noted that the NMI backtrace code
> > > (lib/nmi_backtrace.c) uses the same approach and that use also
> > > confirms that updating the mask is safe from NMI.
> >
> > Updating the global masks without any synchronisation feels broken though:
> >
> > > @@ -1085,77 +1080,75 @@ void smp_send_stop(void)
> > >  {
> > >   unsigned long timeout;
> > >
> > > - if (num_other_online_cpus()) {
> > > - cpumask_t mask;
> > > + /*
> > > +  * If this cpu is the only one alive at this point in time, online 
> > > or
> > > +  * not, there are no stop messages to be sent around, so just back 
> > > out.
> > > +  */
> > > + if (num_other_online_cpus() == 0)
> > > + goto skip_ipi;
> > >
> > > - cpumask_copy(&mask, cpu_online_mask);
> > > - cpumask_clear_cpu(smp_processor_id(), &mask);
> > > + cpumask_copy(to_cpumask(stop_mask), cpu_online_mask);
> > > + cpumask_clear_cpu(smp_processor_id(), to_cpumask(stop_mask));
> >
> > I don't see what prevents multiple CPUs getting in here concurrently and
> > tripping over the masks. x86 seems to avoid that with an atomic
> > 'stopping_cpu' variable in native_stop_other_cpus(). Do we need something
> > similar?
> 
> Good point. nmi_trigger_cpumask_backtrace(), which my code was based
> on, has a test_and_set() for this and that seems simpler than the
> atomic_try_cmpxchg() from the x86 code.
> 
> If we run into that case, what do you think we should do? I guess x86
> just does a "return", though it feels like at least a warning should
> be printed since we're not doing what the function asked us to do.
> When we return there will be other CPUs running.
> 
> In theory, we could try to help the other processor along? I don't
> know how much complexity to handle here and I could imagine that
> testing some of the corner cases would be extremely hard. I could
> imagine that this might work but maybe it's too complex?
> 
> --
> 
> void smp_send_stop(void)
> {
> unsigned long timeout;
> static unsigned long stop_in_progress;
> 
> /*
>  * If this cpu is the only one alive at this point in time, online or
>  * not, there are no stop messages to be sent around, so just back out.
>  */
> if (num_other_online_cpus() == 0)
> goto skip_ipi;
> 
> /*
>  * If another is already trying to stop and we're here then either the
>  * other CPU hasn't sent us the IPI yet or we have interrupts disabled.
>  * Let's help the other CPU by stopping ourselves.
>  */
> if (test_and_set_bit(0, &stop_in_progress)) {
> /* Wait until the other inits stop_mask */
> while (!test_bit(1, &stop_in_progress)) {
> cpu_relax();
> smp_rmb();
> }
> do_handle_IPI(IPI_CPU_STOP);
> }
> 
> cpumask_copy(to_cpumask(stop_mask), cpu_online_mask);
> cpumask_clear_cpu(smp_processor_id(), to_cpumask(stop_mask));
> 
> /* Indicate that we've initted stop_mask */
> set_bit(1, &stop_in_progress);
> smp_wmb();
> ...
> ...
> 
> --
> 
> Opinions?

I think following the x86 behaviour is probably the best place to start:
the CPU that ends up doing the IPI will spin anyway, so I don't think
there's much to gain by being pro-active on the recipient.

> > Apart from that, I'm fine with the gist of the patch.
> 
> Great. Ironically as I reviewed this patch with fresh eyes and looking
> at the things you brought up, I also found a few issues, I'll respond
> to my post myself so I have context to respond to.

Ok.

> One other question: what did you think about Daniel's suggestion to go
> straight to NMI for crash_stop? I don't feel like I have enough
> experience with crash_stop to have intuition here, but it feels like
> trying IRQ first is still better in that case, but I'm happy to go
> either way.

I don't have a strong preference, but I think I'd prefer a non-NMI first
as it feels like things ought to be more robust in that case and it
should work most of the time.

Will



Re: [PATCH] arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI first

2024-06-24 Thread Will Deacon
On Fri, May 17, 2024 at 01:01:58PM -0700, Doug Anderson wrote:
> On Thu, Dec 7, 2023 at 5:03 PM Douglas Anderson  wrote:
> > local_irq_disable();
> 
> The above local_irq_disable() is not new for my patch but it seems
> wonky for two reasons:
> 
> 1. It feels like it should have been the first thing in the function.
> 
> 2. It feels like it should be local_daif_mask() instead.

Is that to ensure we don't take a pNMI? I think that makes sense, but
let's please add a comment to say why local_irq_disable() is not
sufficient.

Will



[PATCH v5 0/3] Add sy7802 flash led driver

2024-06-24 Thread André Apitzsch via B4 Relay
This series introduces a driver for the Silergy SY7802 charge pump used
in the BQ Aquaris M5 and X5 smartphones.

The implementation is based on information extracted from downstream as
the datasheet provided by a distributor of the hardware didn't include
any information about the i2c register description.

Signed-off-by: André Apitzsch 
---
Changes in v5:
- Fix language in driver description comment
- Unwrap function arguments
- Remove unnecessary empty lines
- Add Acked-by tag to second patch
- Link to v4: 
https://lore.kernel.org/r/20240616-sy7802-v4-0-789994180...@apitzsch.eu

Changes in v4:
- Use for_each_available_child_of_node_scoped() to simplify code
- Use dev_err_probe() to be consistent with the other code in
  sy7802_probe()
- Split devm_add_action() into 2 devm_add_action_or_reset() to simplify
  code and balance regulator_enable()
- Link to v3: 
https://lore.kernel.org/r/20240612-sy7802-v3-0-1e9cc1c79...@apitzsch.eu

Changes in v3:
- Add R-b tag to first patch
- Extend driver commit message
- Improve readability of defines by using BIT()
- Rename some variables/parameters
  * led_no -> led_id
  * level -> brightness
  * curr -> fled_{strobe,torch}_used_tmp
  * mask -> {flash,torch}_mask
  * i -> child_num
- Restructure structs ("Place th big stuff at the top")
- Declare 'child' on a separate line
- Move multi-line assignments out of declaration block
- Update warning/error messages and comments
- Use gotos to handle error path
- Use devm API to cleanup module's resources
- Init mutex before LED class device is registered to avoid race
  condition
- Link to v2: 
https://lore.kernel.org/r/20240401-sy7802-v2-0-1138190a7...@apitzsch.eu

Changes in v2:
- bindings: remove unneeded allOf
- bindings: example: move flash-led-controller under i2c node to fix
  check error
- Cc to phone-devel
- Link to v1: 
https://lore.kernel.org/r/20240327-sy7802-v1-0-db74ab32f...@apitzsch.eu

---
André Apitzsch (3):
  dt-bindings: leds: Add Silergy SY7802 flash LED
  leds: sy7802: Add support for Silergy SY7802 flash LED controller
  arm64: dts: qcom: msm8939-longcheer-l9100: Add rear flash

 .../devicetree/bindings/leds/silergy,sy7802.yaml   | 100 
 .../boot/dts/qcom/msm8939-longcheer-l9100.dts  |  26 +
 drivers/leds/flash/Kconfig |  11 +
 drivers/leds/flash/Makefile|   1 +
 drivers/leds/flash/leds-sy7802.c   | 539 +
 5 files changed, 677 insertions(+)
---
base-commit: 6a03b35e4395eb2d6e89a38aca00a9fe9cb39ba1
change-id: 20240325-sy7802-f40fc6f56525

Best regards,
-- 
André Apitzsch 





[PATCH v5 3/3] arm64: dts: qcom: msm8939-longcheer-l9100: Add rear flash

2024-06-24 Thread André Apitzsch via B4 Relay
From: André Apitzsch 

The phone has a Silergy SY7802 flash LED controller.

Signed-off-by: André Apitzsch 
---
 .../boot/dts/qcom/msm8939-longcheer-l9100.dts  | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts 
b/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
index e3404c4455cf..528737929274 100644
--- a/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
+++ b/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
@@ -159,6 +159,25 @@ led@2 {
};
};
};
+
+   flash-led-controller@53 {
+   compatible = "silergy,sy7802";
+   reg = <0x53>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   enable-gpios = <&tlmm 16 GPIO_ACTIVE_HIGH>;
+
+   pinctrl-0 = <&camera_rear_flash_default>;
+   pinctrl-names = "default";
+
+   led@0 {
+   reg = <0>;
+   function = LED_FUNCTION_FLASH;
+   color = ;
+   led-sources = <0>, <1>;
+   };
+   };
 };
 
 &blsp_i2c3 {
@@ -318,6 +337,13 @@ camera_front_flash_default: 
camera-front-flash-default-state {
bias-disable;
};
 
+   camera_rear_flash_default: camera-rear-flash-default-state {
+   pins = "gpio9", "gpio16", "gpio51";
+   function = "gpio";
+   drive-strength = <2>;
+   bias-disable;
+   };
+
gpio_hall_sensor_default: gpio-hall-sensor-default-state {
pins = "gpio20";
function = "gpio";

-- 
2.45.2





[PATCH v5 2/3] leds: sy7802: Add support for Silergy SY7802 flash LED controller

2024-06-24 Thread André Apitzsch via B4 Relay
From: André Apitzsch 

The SY7802 is a current-regulated charge pump which can regulate two
current levels for Flash and Torch modes.

It is a high-current synchronous boost converter with 2-channel high
side current sources. Each channel is able to deliver 900mA current.

Acked-by: Lee Jones 
Signed-off-by: André Apitzsch 
---
 drivers/leds/flash/Kconfig   |  11 +
 drivers/leds/flash/Makefile  |   1 +
 drivers/leds/flash/leds-sy7802.c | 539 +++
 3 files changed, 551 insertions(+)

diff --git a/drivers/leds/flash/Kconfig b/drivers/leds/flash/Kconfig
index 809b6d98bb3e..f39f0bfe6eef 100644
--- a/drivers/leds/flash/Kconfig
+++ b/drivers/leds/flash/Kconfig
@@ -121,4 +121,15 @@ config LEDS_SGM3140
  This option enables support for the SGM3140 500mA Buck/Boost Charge
  Pump LED Driver.
 
+config LEDS_SY7802
+   tristate "LED support for the Silergy SY7802"
+   depends on I2C && OF
+   depends on GPIOLIB
+   select REGMAP_I2C
+   help
+ This option enables support for the SY7802 flash LED controller.
+ SY7802 includes torch and flash functions with programmable current.
+
+ This driver can be built as a module, it will be called "leds-sy7802".
+
 endif # LEDS_CLASS_FLASH
diff --git a/drivers/leds/flash/Makefile b/drivers/leds/flash/Makefile
index 91d60a4b7952..48860eeced79 100644
--- a/drivers/leds/flash/Makefile
+++ b/drivers/leds/flash/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_LEDS_QCOM_FLASH) += leds-qcom-flash.o
 obj-$(CONFIG_LEDS_RT4505)  += leds-rt4505.o
 obj-$(CONFIG_LEDS_RT8515)  += leds-rt8515.o
 obj-$(CONFIG_LEDS_SGM3140) += leds-sgm3140.o
+obj-$(CONFIG_LEDS_SY7802)  += leds-sy7802.o
diff --git a/drivers/leds/flash/leds-sy7802.c b/drivers/leds/flash/leds-sy7802.c
new file mode 100644
index ..ddac836762af
--- /dev/null
+++ b/drivers/leds/flash/leds-sy7802.c
@@ -0,0 +1,539 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Silergy SY7802 flash LED driver with an I2C interface
+ *
+ * Copyright 2024 André Apitzsch 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SY7802_MAX_LEDS 2
+#define SY7802_LED_JOINT 2
+
+#define SY7802_REG_ENABLE  0x10
+#define SY7802_REG_TORCH_BRIGHTNESS0xa0
+#define SY7802_REG_FLASH_BRIGHTNESS0xb0
+#define SY7802_REG_FLASH_DURATION  0xc0
+#define SY7802_REG_FLAGS   0xd0
+#define SY7802_REG_CONFIG_10xe0
+#define SY7802_REG_CONFIG_20xf0
+#define SY7802_REG_VIN_MONITOR 0x80
+#define SY7802_REG_LAST_FLASH  0x81
+#define SY7802_REG_VLED_MONITOR0x30
+#define SY7802_REG_ADC_DELAY   0x31
+#define SY7802_REG_DEV_ID  0xff
+
+#define SY7802_MODE_OFF0
+#define SY7802_MODE_TORCH  2
+#define SY7802_MODE_FLASH  3
+#define SY7802_MODE_MASK   GENMASK(1, 0)
+
+#define SY7802_LEDS_SHIFT  3
+#define SY7802_LEDS_MASK(_id)  (BIT(_id) << SY7802_LEDS_SHIFT)
+#define SY7802_LEDS_MASK_ALL   (SY7802_LEDS_MASK(0) | SY7802_LEDS_MASK(1))
+
+#define SY7802_TORCH_CURRENT_SHIFT 3
+#define SY7802_TORCH_CURRENT_MASK(_id) \
+   (GENMASK(2, 0) << (SY7802_TORCH_CURRENT_SHIFT * (_id)))
+#define SY7802_TORCH_CURRENT_MASK_ALL \
+   (SY7802_TORCH_CURRENT_MASK(0) | SY7802_TORCH_CURRENT_MASK(1))
+
+#define SY7802_FLASH_CURRENT_SHIFT 4
+#define SY7802_FLASH_CURRENT_MASK(_id) \
+   (GENMASK(3, 0) << (SY7802_FLASH_CURRENT_SHIFT * (_id)))
+#define SY7802_FLASH_CURRENT_MASK_ALL \
+   (SY7802_FLASH_CURRENT_MASK(0) | SY7802_FLASH_CURRENT_MASK(1))
+
+#define SY7802_TIMEOUT_DEFAULT_US  512000U
+#define SY7802_TIMEOUT_MIN_US  32000U
+#define SY7802_TIMEOUT_MAX_US  1024000U
+#define SY7802_TIMEOUT_STEPSIZE_US 32000U
+
+#define SY7802_TORCH_BRIGHTNESS_MAX 8
+
+#define SY7802_FLASH_BRIGHTNESS_DEFAULT14
+#define SY7802_FLASH_BRIGHTNESS_MIN0
+#define SY7802_FLASH_BRIGHTNESS_MAX15
+#define SY7802_FLASH_BRIGHTNESS_STEP   1
+
+#define SY7802_FLAG_TIMEOUTBIT(0)
+#define SY7802_FLAG_THERMAL_SHUTDOWN   BIT(1)
+#define SY7802_FLAG_LED_FAULT  BIT(2)
+#define SY7802_FLAG_TX1_INTERRUPT  BIT(3)
+#define SY7802_FLAG_TX2_INTERRUPT  BIT(4)
+#define SY7802_FLAG_LED_THERMAL_FAULT  BIT(5)
+#define SY7802_FLAG_FLASH_INPUT_VOLTAGE_LOWBIT(6)
+#define SY7802_FLAG_INPUT_VOLTAGE_LOW  BIT(7)
+
+#define SY7802_CHIP_ID 0x51
+
+static const struct reg_default sy7802_regmap_defs[] = {
+   { SY7802_REG_ENABLE, SY7802_LEDS_MASK_ALL },
+   { SY7802_REG_TORCH_BRIGHTNESS, 0x92 },
+   { SY7802_REG_FLASH_BRIGHTNESS, SY7802_FLASH_BRIGHTNESS_DEFAULT |
+   SY7802_FLASH_BRIGHTNESS_DEFAULT << SY7802_FLASH_CURRENT_SHIFT },
+   { SY7802_REG_FLASH_DURATION, 0x6f },
+   { SY7802_REG_FLAGS, 0x0 },
+   { SY7802_REG_CONFIG_1, 0x68 },
+   { SY7802_REG_CONFIG_2, 0xf0

[PATCH v5 1/3] dt-bindings: leds: Add Silergy SY7802 flash LED

2024-06-24 Thread André Apitzsch via B4 Relay
From: André Apitzsch 

Document Silergy SY7802 flash LED driver devicetree bindings.

Reviewed-by: Rob Herring 
Signed-off-by: André Apitzsch 
---
 .../devicetree/bindings/leds/silergy,sy7802.yaml   | 100 +
 1 file changed, 100 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml 
b/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml
new file mode 100644
index ..46b8e5452b62
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/silergy,sy7802.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silergy SY7802 1800mA Boost Charge Pump LED Driver
+
+maintainers:
+  - André Apitzsch 
+
+description: |
+  The SY7802 is a current-regulated charge pump which can regulate two current
+  levels for Flash and Torch modes.
+
+  The SY7802 is a high-current synchronous boost converter with 2-channel
+  high side current sources. Each channel is able to deliver 900mA current.
+
+properties:
+  compatible:
+enum:
+  - silergy,sy7802
+
+  reg:
+maxItems: 1
+
+  enable-gpios:
+maxItems: 1
+description: A connection to the 'EN' pin.
+
+  flash-gpios:
+maxItems: 1
+description: A connection to the 'FLEN' pin.
+
+  vin-supply:
+description: Regulator providing power to the 'VIN' pin.
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^led@[0-1]$":
+type: object
+$ref: common.yaml#
+unevaluatedProperties: false
+
+properties:
+  reg:
+description: Index of the LED.
+minimum: 0
+maximum: 1
+
+  led-sources:
+minItems: 1
+maxItems: 2
+items:
+  minimum: 0
+  maximum: 1
+
+required:
+  - reg
+  - led-sources
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+  - enable-gpios
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+flash-led-controller@53 {
+compatible = "silergy,sy7802";
+reg = <0x53>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+enable-gpios = <&tlmm 16 GPIO_ACTIVE_HIGH>;
+
+led@0 {
+reg = <0>;
+function = LED_FUNCTION_FLASH;
+color = ;
+led-sources = <0>, <1>;
+};
+};
+};

-- 
2.45.2





[PATCH v3] x86/traps: Enable UBSAN traps on x86

2024-06-24 Thread Gatlin Newhouse
Currently ARM architectures output which specific sanitizer caused
the trap, via the encoded data in the trap instruction. Clang on
x86 currently encodes the same data in ud1 instructions but the x86
handle_bug() and is_valid_bugaddr() functions currently only look
at ud2s.

Bring x86 to parity with arm64, similar to commit 25b84002afb9
("arm64: Support Clang UBSAN trap codes for better reporting").
Enable the output of UBSAN type information on x86 architectures
compiled with clang when CONFIG_UBSAN_TRAP=y.

Signed-off-by: Gatlin Newhouse 
---
Changes in v3:
  - Address Thomas's remarks about: change log structure,
get_ud_type() instead of is_valid_bugaddr(), handle_bug()
changes, and handle_ubsan_failure().

Changes in v2:
  - Name the new constants 'LEN_ASOP' and 'INSN_ASOP' instead of
'LEN_REX' and 'INSN_REX'
  - Change handle_ubsan_failure() from enum bug_trap_type to void
function

v1: 
https://lore.kernel.org/linux-hardening/20240529022043.3661757-1-gatlin.newho...@gmail.com/
v2: 
https://lore.kernel.org/linux-hardening/20240601031019.3708758-1-gatlin.newho...@gmail.com/
---
 MAINTAINERS  |  2 ++
 arch/x86/include/asm/bug.h   | 11 ++
 arch/x86/include/asm/ubsan.h | 23 +
 arch/x86/kernel/Makefile |  1 +
 arch/x86/kernel/traps.c  | 40 +++-
 arch/x86/kernel/ubsan.c  | 21 +++
 6 files changed, 93 insertions(+), 5 deletions(-)
 create mode 100644 arch/x86/include/asm/ubsan.h
 create mode 100644 arch/x86/kernel/ubsan.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 28e20975c26f..b8512887ffb1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22635,6 +22635,8 @@ L:  kasan-...@googlegroups.com
 L: linux-hardening@vger.kernel.org
 S: Supported
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
for-next/hardening
+F: arch/x86/include/asm/ubsan.h
+F: arch/x86/kernel/ubsan.c
 F: Documentation/dev-tools/ubsan.rst
 F: include/linux/ubsan.h
 F: lib/Kconfig.ubsan
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index a3ec87d198ac..a363d13c263b 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -13,6 +13,17 @@
 #define INSN_UD2   0x0b0f
 #define LEN_UD22
 
+/*
+ * In clang we have UD1s reporting UBSAN failures on X86, 64 and 32bit.
+ */
+#define INSN_UD1   0xb90f
+#define INSN_UD_MASK   0x
+#define LEN_UD12
+#define INSN_ASOP  0x67
+#define INSN_ASOP_MASK 0x00FF
+#define BUG_UD_NONE0x
+#define BUG_UD20xFFFE
+
 #ifdef CONFIG_GENERIC_BUG
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/include/asm/ubsan.h b/arch/x86/include/asm/ubsan.h
new file mode 100644
index ..ac2080984e83
--- /dev/null
+++ b/arch/x86/include/asm/ubsan.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_UBSAN_H
+#define _ASM_X86_UBSAN_H
+
+/*
+ * Clang Undefined Behavior Sanitizer trap mode support.
+ */
+#include 
+#include 
+#include 
+
+/*
+ * UBSAN uses the EAX register to encode its type in the ModRM byte.
+ */
+#define UBSAN_REG  0x40
+
+#ifdef CONFIG_UBSAN_TRAP
+void handle_ubsan_failure(struct pt_regs *regs, u16 insn);
+#else
+static inline void handle_ubsan_failure(struct pt_regs *regs, u16 insn) { 
return; }
+#endif /* CONFIG_UBSAN_TRAP */
+
+#endif /* _ASM_X86_UBSAN_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 74077694da7d..fe1d9db27500 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -145,6 +145,7 @@ obj-$(CONFIG_UNWINDER_GUESS)+= 
unwind_guess.o
 obj-$(CONFIG_AMD_MEM_ENCRYPT)  += sev.o
 
 obj-$(CONFIG_CFI_CLANG)+= cfi.o
+obj-$(CONFIG_UBSAN_TRAP)   += ubsan.o
 
 obj-$(CONFIG_CALL_THUNKS)  += callthunks.o
 
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 4fa0b17e5043..aef21287e7ed 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -67,6 +67,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -91,6 +92,29 @@ __always_inline int is_valid_bugaddr(unsigned long addr)
return *(unsigned short *)addr == INSN_UD2;
 }
 
+/*
+ * Check for UD1, UD2, with or without Address Size Override Prefixes 
instructions.
+ */
+__always_inline u16 get_ud_type(unsigned long addr)
+{
+   u16 insn;
+
+   if (addr < TASK_SIZE_MAX)
+   return BUG_UD_NONE;
+   insn = *(u16 *)addr;
+   if ((insn & INSN_UD_MASK) == INSN_UD2)
+   return BUG_UD2;
+   if ((insn & INSN_ASOP_MASK) == INSN_ASOP)
+   insn = *(u16 *)(++addr);
+
+   // UBSAN encode the failure type in the two bytes after UD1
+   if ((insn & INSN_UD_MASK) == INSN_UD1)
+   return *(u16 *)(addr + LEN_UD1);
+
+   return BUG_UD_NONE;
+}
+
+
 static nokprobe_inline int
 do_trap_no_signal(struct task_struct *tsk,