Searched hist:8803 (Results 1 - 6 of 6) sorted by relevance

/linux-master/drivers/rtc/
H A Drtc-rv8803.cdiff c27fee16 Tue Apr 26 01:10:54 MDT 2022 Ahmad Fatoum <a.fatoum@pengutronix.de> rtc: rv8803: re-initialize all Epson RX8803 registers on voltage loss

The reference manuals of both the RX8803 and RV8803 dictate that
"[On V2F/VLF = ] all registers must be initialized".

The RV-8803 application manual (rev. 1.6) further specifies that crossing
V_LOW2 threshold enables flag V2F and triggers a Power-On reset.
According to table 3.11 in the document, all control registers are
defined to sensible values.

However, The Epson RX-8803 doesn't offer the same guarantees.
It explicitly states:

During the initial power-up, the TEST bit is reset to "0" and the VLF
bit is set to "1".
∗ At this point, all other register values are _undefined_, so be sure to
perform a reset before using the module.

Commit d3700b6b6479 ("rtc: rv8803: Stop the clock while setting the time")
also had this rationale:

Indeed, all the registers must be initialized if the voltage has been
lower than VLOW2 (triggering V2F), but not low enough to trigger a POR.

We should follow the advice and initialize all applicable registers.
We can group the registers into 3 groups:

A) Already correctly handled registers:
* 0B-0Ch | Timer Counter | unused and disabled by clearing TE in 0Dh
* 0Dh | Extension Reg | already initialized in rv8803_regs_configure
* 0Eh | Flag Reg | handled in IRQ handler, except for VLF, VDET
* 0Eh | VLF, VDET | cleared in ->set_time
* 10h | 100th Seconds | Already reset via RESET bit
* 20-21h | Capture Buffer | holds timestamp unused by driver
* 2Fh | Event Control | resets automatically

B) Registers that are hardware initialized on POR, but not on VLF:
* 0Fh | Control Reg
* 2Ch | OSC Offset

C) RAM that is undefined on voltage loss:
* 00-06h | Date/Time
* 07h | RAM
* 08-0Ah | Alarm

This means we should initialize after VLF the registers in group B
(RV8803_CTRL and RV8803_OSC_OFFSET).

Group C is all-zero after voltage loss on the RV-8803, but undefined on
the RX-8803. This is ok for Date/Time because ->get_time returns an
error code for as long as the voltage loss flag is active. It's cleared
on ->set_time however. Zeroing both RAM and alarm ensures a fixed value
is read afterwards.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220426071056.1187235-4-s.hauer@pengutronix.de
diff c27fee16 Tue Apr 26 01:10:54 MDT 2022 Ahmad Fatoum <a.fatoum@pengutronix.de> rtc: rv8803: re-initialize all Epson RX8803 registers on voltage loss

The reference manuals of both the RX8803 and RV8803 dictate that
"[On V2F/VLF = ] all registers must be initialized".

The RV-8803 application manual (rev. 1.6) further specifies that crossing
V_LOW2 threshold enables flag V2F and triggers a Power-On reset.
According to table 3.11 in the document, all control registers are
defined to sensible values.

However, The Epson RX-8803 doesn't offer the same guarantees.
It explicitly states:

During the initial power-up, the TEST bit is reset to "0" and the VLF
bit is set to "1".
∗ At this point, all other register values are _undefined_, so be sure to
perform a reset before using the module.

Commit d3700b6b6479 ("rtc: rv8803: Stop the clock while setting the time")
also had this rationale:

Indeed, all the registers must be initialized if the voltage has been
lower than VLOW2 (triggering V2F), but not low enough to trigger a POR.

We should follow the advice and initialize all applicable registers.
We can group the registers into 3 groups:

A) Already correctly handled registers:
* 0B-0Ch | Timer Counter | unused and disabled by clearing TE in 0Dh
* 0Dh | Extension Reg | already initialized in rv8803_regs_configure
* 0Eh | Flag Reg | handled in IRQ handler, except for VLF, VDET
* 0Eh | VLF, VDET | cleared in ->set_time
* 10h | 100th Seconds | Already reset via RESET bit
* 20-21h | Capture Buffer | holds timestamp unused by driver
* 2Fh | Event Control | resets automatically

B) Registers that are hardware initialized on POR, but not on VLF:
* 0Fh | Control Reg
* 2Ch | OSC Offset

C) RAM that is undefined on voltage loss:
* 00-06h | Date/Time
* 07h | RAM
* 08-0Ah | Alarm

This means we should initialize after VLF the registers in group B
(RV8803_CTRL and RV8803_OSC_OFFSET).

Group C is all-zero after voltage loss on the RV-8803, but undefined on
the RX-8803. This is ok for Date/Time because ->get_time returns an
error code for as long as the voltage loss flag is active. It's cleared
on ->set_time however. Zeroing both RAM and alarm ensures a fixed value
is read afterwards.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220426071056.1187235-4-s.hauer@pengutronix.de
diff c27fee16 Tue Apr 26 01:10:54 MDT 2022 Ahmad Fatoum <a.fatoum@pengutronix.de> rtc: rv8803: re-initialize all Epson RX8803 registers on voltage loss

The reference manuals of both the RX8803 and RV8803 dictate that
"[On V2F/VLF = ] all registers must be initialized".

The RV-8803 application manual (rev. 1.6) further specifies that crossing
V_LOW2 threshold enables flag V2F and triggers a Power-On reset.
According to table 3.11 in the document, all control registers are
defined to sensible values.

However, The Epson RX-8803 doesn't offer the same guarantees.
It explicitly states:

During the initial power-up, the TEST bit is reset to "0" and the VLF
bit is set to "1".
∗ At this point, all other register values are _undefined_, so be sure to
perform a reset before using the module.

Commit d3700b6b6479 ("rtc: rv8803: Stop the clock while setting the time")
also had this rationale:

Indeed, all the registers must be initialized if the voltage has been
lower than VLOW2 (triggering V2F), but not low enough to trigger a POR.

We should follow the advice and initialize all applicable registers.
We can group the registers into 3 groups:

A) Already correctly handled registers:
* 0B-0Ch | Timer Counter | unused and disabled by clearing TE in 0Dh
* 0Dh | Extension Reg | already initialized in rv8803_regs_configure
* 0Eh | Flag Reg | handled in IRQ handler, except for VLF, VDET
* 0Eh | VLF, VDET | cleared in ->set_time
* 10h | 100th Seconds | Already reset via RESET bit
* 20-21h | Capture Buffer | holds timestamp unused by driver
* 2Fh | Event Control | resets automatically

B) Registers that are hardware initialized on POR, but not on VLF:
* 0Fh | Control Reg
* 2Ch | OSC Offset

C) RAM that is undefined on voltage loss:
* 00-06h | Date/Time
* 07h | RAM
* 08-0Ah | Alarm

This means we should initialize after VLF the registers in group B
(RV8803_CTRL and RV8803_OSC_OFFSET).

Group C is all-zero after voltage loss on the RV-8803, but undefined on
the RX-8803. This is ok for Date/Time because ->get_time returns an
error code for as long as the voltage loss flag is active. It's cleared
on ->set_time however. Zeroing both RAM and alarm ensures a fixed value
is read afterwards.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220426071056.1187235-4-s.hauer@pengutronix.de
diff c27fee16 Tue Apr 26 01:10:54 MDT 2022 Ahmad Fatoum <a.fatoum@pengutronix.de> rtc: rv8803: re-initialize all Epson RX8803 registers on voltage loss

The reference manuals of both the RX8803 and RV8803 dictate that
"[On V2F/VLF = ] all registers must be initialized".

The RV-8803 application manual (rev. 1.6) further specifies that crossing
V_LOW2 threshold enables flag V2F and triggers a Power-On reset.
According to table 3.11 in the document, all control registers are
defined to sensible values.

However, The Epson RX-8803 doesn't offer the same guarantees.
It explicitly states:

During the initial power-up, the TEST bit is reset to "0" and the VLF
bit is set to "1".
∗ At this point, all other register values are _undefined_, so be sure to
perform a reset before using the module.

Commit d3700b6b6479 ("rtc: rv8803: Stop the clock while setting the time")
also had this rationale:

Indeed, all the registers must be initialized if the voltage has been
lower than VLOW2 (triggering V2F), but not low enough to trigger a POR.

We should follow the advice and initialize all applicable registers.
We can group the registers into 3 groups:

A) Already correctly handled registers:
* 0B-0Ch | Timer Counter | unused and disabled by clearing TE in 0Dh
* 0Dh | Extension Reg | already initialized in rv8803_regs_configure
* 0Eh | Flag Reg | handled in IRQ handler, except for VLF, VDET
* 0Eh | VLF, VDET | cleared in ->set_time
* 10h | 100th Seconds | Already reset via RESET bit
* 20-21h | Capture Buffer | holds timestamp unused by driver
* 2Fh | Event Control | resets automatically

B) Registers that are hardware initialized on POR, but not on VLF:
* 0Fh | Control Reg
* 2Ch | OSC Offset

C) RAM that is undefined on voltage loss:
* 00-06h | Date/Time
* 07h | RAM
* 08-0Ah | Alarm

This means we should initialize after VLF the registers in group B
(RV8803_CTRL and RV8803_OSC_OFFSET).

Group C is all-zero after voltage loss on the RV-8803, but undefined on
the RX-8803. This is ok for Date/Time because ->get_time returns an
error code for as long as the voltage loss flag is active. It's cleared
on ->set_time however. Zeroing both RAM and alarm ensures a fixed value
is read afterwards.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220426071056.1187235-4-s.hauer@pengutronix.de
diff d3700b6b Wed Jul 20 16:41:31 MDT 2016 Benoît Thébaudeau <benoit@wsystem.com> rtc: rv8803: Stop the clock while setting the time

According to the application manual of the RX8900, the RESET bit must be
set to 1 to prevent a timer update while setting the time. This also
resets the subsecond counter. The application manual of the RV-8803 does
not mention such a requirement, and it says that the 100th Seconds
register is cleared when writing to the Seconds register, but using the
RESET bit for the RV-8803 too should not be an issue and is probably
safer.

This change also ensures that the RESET bit is initialized properly in
all cases. Indeed, all the registers must be initialized if the voltage
has been lower than VLOW2 (triggering V2F), but not low enough to
trigger a POR.

Signed-off-by: Benoît Thébaudeau <benoit@wsystem.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
diff d3700b6b Wed Jul 20 16:41:31 MDT 2016 Benoît Thébaudeau <benoit@wsystem.com> rtc: rv8803: Stop the clock while setting the time

According to the application manual of the RX8900, the RESET bit must be
set to 1 to prevent a timer update while setting the time. This also
resets the subsecond counter. The application manual of the RV-8803 does
not mention such a requirement, and it says that the 100th Seconds
register is cleared when writing to the Seconds register, but using the
RESET bit for the RV-8803 too should not be an issue and is probably
safer.

This change also ensures that the RESET bit is initialized properly in
all cases. Indeed, all the registers must be initialized if the voltage
has been lower than VLOW2 (triggering V2F), but not low enough to
trigger a POR.

Signed-off-by: Benoît Thébaudeau <benoit@wsystem.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
diff d522649e Wed Jul 20 16:41:30 MDT 2016 Benoît Thébaudeau <benoit@wsystem.com> rtc: rv8803: Always apply the I²C workaround

The I²C NACK issue of the RV-8803 may occur after any I²C START
condition, depending on the timings. Consequently, the workaround must
be applied for all the I²C transfers.

This commit abstracts the I²C transfer code into register access
functions. This avoids duplicating the I²C workaround everywhere. This
also avoids the duplication of the code handling the return value of
i2c_smbus_read_i2c_block_data(). Error messages are issued in case of
definitive register access failures (if the workaround fails). This
change also makes the I²C transfer return value checks consistent.

Signed-off-by: Benoît Thébaudeau <benoit@wsystem.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
/linux-master/drivers/usb/gadget/function/
H A Df_uac1.cdiff 254cb1e0 Mon Mar 01 04:49:35 MST 2021 Ruslan Bilovol <ruslan.bilovol@gmail.com> usb: gadget: f_uac1: disable IN/OUT ep if unused

User can configure f_uac1 function via p_chmask/c_chmask
whether uac1 shall support playback and/or capture,
but it has only effect on the created ALSA device,
but not on the USB descriptor.

This patch adds playback/capture descriptors
dependent on that parameter. It is similar to
the same conversion done earlier for f_uac2

Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Link: https://lore.kernel.org/r/1614599375-8803-6-git-send-email-ruslan.bilovol@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
diff a59c68a6 Mon Mar 01 04:49:34 MST 2021 Ruslan Bilovol <ruslan.bilovol@gmail.com> usb: gadget: f_uac1: validate input parameters

Currently user can configure UAC1 function with
parameters that violate UAC1 spec or are not supported
by UAC1 gadget implementation.

This can lead to incorrect behavior if such gadget
is connected to the host - like enumeration failure
or other issues depending on host's UAC1 driver
implementation, bringing user to a long hours
of debugging the issue.

Instead of silently accept these parameters, throw
an error if they are not valid.

Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Link: https://lore.kernel.org/r/1614599375-8803-5-git-send-email-ruslan.bilovol@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
diff cc2ac63d Mon Mar 01 04:49:32 MST 2021 Ruslan Bilovol <ruslan.bilovol@gmail.com> usb: gadget: f_uac1: stop playback on function disable

There is missing playback stop/cleanup in case of
gadget's ->disable callback that happens on
events like USB host resetting or gadget disconnection

Fixes: 0591bc236015 ("usb: gadget: add f_uac1 variant based on a new u_audio api")
Cc: <stable@vger.kernel.org> # 4.13+
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Link: https://lore.kernel.org/r/1614599375-8803-3-git-send-email-ruslan.bilovol@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
H A Df_uac2.cdiff 3713d5ce Mon Mar 01 04:49:33 MST 2021 Ruslan Bilovol <ruslan.bilovol@gmail.com> usb: gadget: f_uac2: validate input parameters

Currently user can configure UAC2 function with
parameters that violate UAC2 spec or are not supported
by UAC2 gadget implementation.

This can lead to incorrect behavior if such gadget
is connected to the host - like enumeration failure
or other issues depending on host's UAC2 driver
implementation, bringing user to a long hours
of debugging the issue.

Instead of silently accept these parameters, throw
an error if they are not valid.

Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Link: https://lore.kernel.org/r/1614599375-8803-4-git-send-email-ruslan.bilovol@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
diff 789ea773 Mon Mar 01 04:49:31 MST 2021 Ruslan Bilovol <ruslan.bilovol@gmail.com> usb: gadget: f_uac2: always increase endpoint max_packet_size by one audio slot

As per UAC2 Audio Data Formats spec (2.3.1.1 USB Packets),
if the sampling rate is a constant, the allowable variation
of number of audio slots per virtual frame is +/- 1 audio slot.

It means that endpoint should be able to accept/send +1 audio
slot.

Previous endpoint max_packet_size calculation code
was adding sometimes +1 audio slot due to DIV_ROUND_UP
behaviour which was rounding up to closest integer.
However this doesn't work if the numbers are divisible.

It had no any impact with Linux hosts which ignore
this issue, but in case of more strict Windows it
caused rejected enumeration

Thus always add +1 audio slot to endpoint's max packet size

Fixes: 913e4a90b6f9 ("usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth")
Cc: Peter Chen <peter.chen@freescale.com>
Cc: <stable@vger.kernel.org> #v4.3+
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Link: https://lore.kernel.org/r/1614599375-8803-2-git-send-email-ruslan.bilovol@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
/linux-master/drivers/net/ethernet/sfc/
H A Dfilter.hdiff 8803e150 Mon Nov 19 16:08:20 MST 2012 Ben Hutchings <bhutchings@solarflare.com> sfc: Add flag for stack-owned RX MAC filters

MAC filters inserted on request from the stack (ndo_set_rx_mode)
should allow manual steering but not removal. Currently we have a
special case for Siena's all-multicast and all-unicast MAC filters,
but on EF10 we need to allow for steering of precise MAC filters as
well.

The EFX_FILTER_FLAG_RX_STACK flag changes the behaviour of replacement
and removal requests:

- Replacement *of* a filter with this flag never clears the flag but
does change steering and saved priority
- Replacement *by* a filter with this flag only sets the flag but does
not change steering
- Removal with priority < EFX_FILTER_PRI_REQUIRED really resets RX
steering and saved priority

This could support precise MAC filtering on Siena in future.

As a side-benefit, the default MAC filters are hidden from ethtool
until they are steered.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
/linux-master/drivers/md/
H A Ddm-rq.cdiff 8803c89f Tue Feb 15 03:05:39 MST 2022 Christoph Hellwig <hch@lst.de> dm: remove useless code from dm_dispatch_clone_request

Both ->start_time_ns and the RQF_IO_STAT are set when the request is
allocated using blk_mq_alloc_request by dm-mpath in blk_mq_rq_ctx_init.
The block layer also ensures ->start_time_ns is only set when actually
needed.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Link: https://lore.kernel.org/r/20220215100540.3892965-5-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
/linux-master/drivers/ata/
H A Dahci.cdiff 2a2df98e Tue Aug 29 05:33:58 MDT 2023 Werner Fischer <devlists@wefi.net> ata: ahci: Add Elkhart Lake AHCI controller

Elkhart Lake is the successor of Apollo Lake and Gemini Lake. These
CPUs and their PCHs are used in mobile and embedded environments.

With this patch I suggest that Elkhart Lake SATA controllers [1] should
use the default LPM policy for mobile chipsets.
The disadvantage of missing hot-plug support with this setting should
not be an issue, as those CPUs are used in embedded environments and
not in servers with hot-plug backplanes.

We discovered that the Elkhart Lake SATA controllers have been missing
in ahci.c after a customer reported the throttling of his SATA SSD
after a short period of higher I/O. We determined the high temperature
of the SSD controller in idle mode as the root cause for that.

Depending on the used SSD, we have seen up to 1.8 Watt lower system
idle power usage and up to 30°C lower SSD controller temperatures in
our tests, when we set med_power_with_dipm manually. I have provided a
table showing seven different SATA SSDs from ATP, Intel/Solidigm and
Samsung [2].

Intel lists a total of 3 SATA controller IDs (4B60, 4B62, 4B63) in [1]
for those mobile PCHs.
This commit just adds 0x4b63 as I do not have test systems with 0x4b60
and 0x4b62 SATA controllers.
I have tested this patch with a system which uses 0x4b63 as SATA
controller.

[1] https://sata-io.org/product/8803
[2] https://www.thomas-krenn.com/en/wiki/SATA_Link_Power_Management#Example_LES_v4

Signed-off-by: Werner Fischer <devlists@wefi.net>
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>

Completed in 410 milliseconds