pwm: atmel-hlcdc: Fix frequency output being half of expected#6
Open
kay54068 wants to merge 1 commit intolinux4microchip:linux-6.12-mchpfrom
Open
pwm: atmel-hlcdc: Fix frequency output being half of expected#6kay54068 wants to merge 1 commit intolinux4microchip:linux-6.12-mchpfrom
kay54068 wants to merge 1 commit intolinux4microchip:linux-6.12-mchpfrom
Conversation
The atmel-hlcdc PWM driver generates an output frequency that is exactly half of the value requested in the device tree. For example, a request for 1000 Hz results in a 500 Hz output. This is caused by an incorrect prescaler calculation. The driver's formula for the clock divider did not match the hardware, which uses a division factor of 2^(pres + 1). The driver was missing the "+1", causing the output period to be doubled. This patch corrects the calculation to `2^(pres + 1)`, aligning it with the hardware's behavior and ensuring the generated frequency is correct.
cristibirsan
pushed a commit
that referenced
this pull request
Feb 12, 2026
[ Upstream commit 2939203 ] In the current implementation, the enetc_xdp_xmit() always transmits redirected XDP frames even if the link is down, but the frames cannot be transmitted from TX BD rings when the link is down, so the frames are still kept in the TX BD rings. If the XDP program is uninstalled, users will see the following warning logs. fsl_enetc 0000:00:00.0 eno0: timeout for tx ring #6 clear More worse, the TX BD ring cannot work properly anymore, because the HW PIR and CIR are not equal after the re-initialization of the TX BD ring. At this point, the BDs between CIR and PIR are invalid, which will cause a hardware malfunction. Another reason is that there is internal context in the ring prefetch logic that will retain the state from the first incarnation of the ring and continue prefetching from the stale location when we re-initialize the ring. The internal context is only reset by an FLR. That is to say, for LS1028A ENETC, software cannot set the HW CIR and PIR when initializing the TX BD ring. It does not make sense to transmit redirected XDP frames when the link is down. Add a link status check to prevent transmission in this condition. This fixes part of the issue, but more complex cases remain. For example, the TX BD ring may still contain unsent frames when the link goes down. Those situations require additional patches, which will build on this one. Fixes: 9d2b68c ("net: enetc: add support for XDP_REDIRECT") Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Hariprasad Kelam <hkelam@marvell.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20251211020919.121113-1-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
cristibirsan
pushed a commit
that referenced
this pull request
Feb 12, 2026
commit c943bfc upstream. After a copy pair swap the block device's "device" symlink points to the secondary CCW device, but the gendisk's parent remained the primary, leaving /sys/block/<dasdx> under the wrong parent. Move the gendisk to the secondary's device with device_move(), keeping the sysfs topology consistent after the swap. Fixes: 413862c ("s390/dasd: add copy pair swap capability") Cc: stable@vger.kernel.org #6.1 Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The atmel-hlcdc PWM driver generates an output frequency that is
exactly half of the value requested in the device tree. For example,
a request for 1000 Hz results in a 500 Hz output.
This is caused by an incorrect prescaler calculation. The driver's
formula for the clock divider did not match the hardware, which uses
a division factor of 2^(pres + 1). The driver was missing the "+1",
causing the output period to be doubled.
This patch corrects the calculation to
2^(pres + 1), aligning itwith the hardware's behavior and ensuring the generated frequency is
correct.