Searched hist:8803 (Results 1 - 6 of 6) sorted by relevance
/linux-master/drivers/rtc/ | ||
H A D | rtc-rv8803.c | 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 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 D | f_uac1.c | diff 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 D | f_uac2.c | diff 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 D | filter.h | diff 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 D | dm-rq.c | diff 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 D | ahci.c | diff 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