Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
> On Jan 16, 2021, at 8:41 PM, Yu Zhao wrote: > > On Tue, Jan 12, 2021 at 09:43:38PM +, Will Deacon wrote: >> On Tue, Jan 12, 2021 at 12:38:34PM -0800, Nadav Amit wrote: On Jan 12, 2021, at 11:56 AM, Yu Zhao wrote: On Tue, Jan 12, 2021 at 11:15:43AM -0800, Nadav Amit wrote: > I will send an RFC soon for per-table deferred TLB flushes tracking. > The basic idea is to save a generation in the page-struct that tracks > when deferred PTE change took place, and track whenever a TLB flush > completed. In addition, other users - such as mprotect - would use > the tlb_gather interface. > > Unfortunately, due to limited space in page-struct this would only > be possible for 64-bit (and my implementation is only for x86-64). I don't want to discourage you but I don't think this would end up well. PPC doesn't necessarily follow one-page-struct-per-table rule, and I've run into problems with this before while trying to do something similar. >>> >>> Discourage, discourage. Better now than later. >>> >>> It will be relatively easy to extend the scheme to be per-VMA instead of >>> per-table for architectures that prefer it this way. It does require >>> TLB-generation tracking though, which Andy only implemented for x86, so I >>> will focus on x86-64 right now. >> >> Can you remind me of what we're missing on arm64 in this area, please? I'm >> happy to help get this up and running once you have something I can build >> on. > > I noticed arm/arm64 don't support ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH. > Would it be something worth pursuing? Arm has been using mm_cpumask, > so it might not be too difficult I guess? [ +Mel Gorman who implemented ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH ] IIUC, there are at least two bugs in x86 implementation. First, there is a missing memory barrier in tlbbatch_add_mm() between inc_mm_tlb_gen() and the read of mm_cpumask(). Second, try_to_unmap_flush() clears flush_required after flushing. Another thread can call set_tlb_ubc_flush_pending() after the flush and before flush_required is cleared, and the indication that a TLB flush is pending can be lost. I am working on addressing these issues among others, but, as you already saw, I am a bit slow. On a different but related topic: Another thing that I noticed that Arm does not do is batching TLB flushes across VMAs. Since Arm does not have its own tlb_end_vma(), it uses the default tlb_end_vma(), which flushes each VMA separately. Peter Zijlstra’s comment says that there are advantages in flushing each VMA separately, but I am not sure it is better or intentional (especially since x86 does not do so). I am trying to remove the arch-specific tlb_end_vma() and have a config option to control this behavior. Again, sorry for being slow. I hope to send an RFC soon.
Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors
Hi Jonathan,
Can you clarify one thing ? If we go with option 2 which is using
IIO_AVAIL_RANGE for min,step,high using IIO_VAL_INT then how will it
ensure the possible floating value for step as we are using int type?
Thanks,
Jyoti
On Sat, Jan 16, 2021 at 11:33 AM Jonathan Cameron wrote:
>
> On Mon, 11 Jan 2021 13:17:51 -0800
> Jyoti Bhayana wrote:
>
> > Hi Jonathan,
> >
> > I know it is a bit confusing. Let me try to explain it with some
> > examples to hopefully clarify some things here.
> > SCMI Platform talks to the native/actual sensor, gets the raw values
> > from the native sensor and applies the scale and then sends those
> > values to the SCMI agent and the SCMI IIO driver.
> > Since the sensor readings which SCMI IIO driver gets are integer, to
> > convert them to float , we need to apply scale to these sensor values
> > which is the unit_exponent(power-of-10 multiplier in two’s-complement
> > format) specified in the SCMI specification
> >
> > Native Sensor -> SCMI platform->SCMI Agent->SCMI IIO Driver
> >
> > So if Native Sensor gets the sensor value
> > 32767 and the scale the SCMI Platform is using is 0.002392.
> > SCMI platform does the calculation of 32767 * 0.002392 = 78.378664
> > and send the sensor value as 78378664 and the scale as .01 to the
> > SCMI agent and SCMI IIO driver
> >
> > so for SCMI IIO driver the sensor reading = 78378664 and scale = .01
> > and the sensor value is sensor_reading * scale = 78378664 * .01
> > = 78.378664
> > and the resolution which the SCMI Platform sends to the SCMI agent is
> > 0.002392.
> > In the SCMI IIO driver, scale which is .01 is applied to the min
> > range/max range and the actual sensor values.
> > sensor resolution which is 0.002392 is just passed to the userspace
> > layer so that they know the Native sensor resolution/scale
> > being applied by the SCMI platform.
>
> That was pretty much where I'd gotten to.
> Whilst the reasoning might be different it is equivalent to a sensor
> providing info on expected noise by giving a 'valid resolution'.
> In that case as well you have a sensor providing a number that looks to have
> more precision than it actually does.
>
> Anyhow, that similarity doesn't really matter here.
>
> I'll also add that a design that applies scale in two places is inherently
> less than ideal. A cleaner design would have maintained the separation
> between scale and raw value all the way up the stack. That would result
> in 0 loss of information and also be a cleaner interface.
> Ah well, we live with what we have :)
>
> >
> > Regarding your comments in the previous email, when you mentioned
> > "what we actually
> > need is non standard ABI for resolution"? Does that mean that it is ok
> > to have sensor resolution
> > as the IIO attribute shown below?
> >
> > static IIO_DEVICE_ATTR(sensor_resolution, 0444,
> > scmi_iio_get_sensor_resolution,
> > NULL, 0);
>
> We could do something new (see later for why I don't think we need to)
> Would need to clearly reflect what it applies to and I'm not sure resolution
> is even an unambiguous name given sensor resolution is often described as 8bit
> 10bit etc. E.g. this selection table from Maxim for ADCs.
> https://www.maximintegrated.com/en/products/parametric/search.html?fam=prec_adc=master=Precision%20ADCs%20(%20%205Msps)=270
> Of course sometimes it's also used for what you want here.
>
> Hohum. So we might be still be able to do this with standard ABI but we
> are going to need to do some maths in the driver.
> So if we were to express it via
>
> in_accel_raw_avail for example we could use the [low step high] form.
>
> low and high are straight forward as those are expressed directly from
> axis_min_range and axis_max_range which I think are in the same units
> as the _raw channel itself.
>
> For resolution, we have it expressed as [res] x 10^res_exponent
> and if we just put that in as the 'step' above it would have the wrong
> exponent (as we'd expect to still have to apply your 0.1 from above
> example).
>
> Hence we express it as [res] x 10^(res_exponent - exponent)
>
> I'm going to slightly modify your example above because the two exponents
> are the same so it's hard to tell if I have them right way around.
> Hence let res = 0.00293 = 293 x 10^(-5) (I just dropped the trailing 2)
>
> scale = 10^(-6) exponent = -6
>
> So step = 2392 x 10^(-5 + 6) = 2390
> giving us
>
> [min 2390 max] for _raw_available
>
> Hence when userspace comes along and wants this in relevant base units (here
> m/sec^2) it applies the x10^(-6) mutliplier from _scale we get out expected
> value
> of 0.00239 m/sec^2
>
> That should work for any case we see but the maths done in the driver will
> have
> to cope with potential negative exponents for step.
>
> One catch will be the 64 bit potential values for min and max :(
>
> >
> > static struct attribute *scmi_iio_attributes[] = {
> >_dev_attr_sensor_resolution.dev_attr.attr,
> >
Re: [PATCH] bcache: consider the fragmentation when update the writeback rate
Hi Dongdong,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Dongdong-Tao/bcache-consider-the-fragmentation-when-update-the-writeback-rate/20210105-110903
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
config: i386-randconfig-a002-20200806 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/fef68d1401235db42dd0d59c5c3dba3d42d3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Dongdong-Tao/bcache-consider-the-fragmentation-when-update-the-writeback-rate/20210105-110903
git checkout fef68d1401235db42dd0d59c5c3dba3d42d3
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
ld: drivers/md/bcache/writeback.o: in function `__update_writeback_rate':
>> drivers/md/bcache/writeback.c:106: undefined reference to `__divdi3'
>> ld: drivers/md/bcache/writeback.c:120: undefined reference to `__divdi3'
vim +106 drivers/md/bcache/writeback.c
60
61 static void __update_writeback_rate(struct cached_dev *dc)
62 {
63 /*
64 * PI controller:
65 * Figures out the amount that should be written per second.
66 *
67 * First, the error (number of sectors that are dirty beyond our
68 * target) is calculated. The error is accumulated (numerically
69 * integrated).
70 *
71 * Then, the proportional value and integral value are scaled
72 * based on configured values. These are stored as inverses to
73 * avoid fixed point math and to make configuration easy-- e.g.
74 * the default value of 40 for writeback_rate_p_term_inverse
75 * attempts to write at a rate that would retire all the dirty
76 * blocks in 40 seconds.
77 *
78 * The writeback_rate_i_inverse value of 1 means that
1/1th
79 * of the error is accumulated in the integral term per second.
80 * This acts as a slow, long-term average that is not subject to
81 * variations in usage like the p term.
82 */
83 int64_t target = __calc_target_rate(dc);
84 int64_t dirty = bcache_dev_sectors_dirty(>disk);
85 int64_t error = dirty - target;
86 int64_t proportional_scaled =
87 div_s64(error, dc->writeback_rate_p_term_inverse);
88 int64_t integral_scaled;
89 uint32_t new_rate;
90
91 /*
92 * We need to consider the number of dirty buckets as well
93 * when calculating the proportional_scaled, Otherwise we might
94 * have an unreasonable small writeback rate at a highly
fragmented situation
95 * when very few dirty sectors consumed a lot dirty buckets, the
96 * worst case is when dirty_data reached writeback_percent and
97 * dirty buckets reached to cutoff_writeback_sync, but the rate
98 * still will be at the minimum value, which will cause the
write
99 * stuck at a non-writeback mode.
100 */
101 struct cache_set *c = dc->disk.c;
102
103 int64_t dirty_buckets = c->nbuckets - c->avail_nbuckets;
104
105 if (c->gc_stats.in_use > BCH_WRITEBACK_FRAGMENT_THRESHOLD_LOW
&& dirty > 0) {
> 106 int64_t fragment = (dirty_buckets *
> c->cache->sb.bucket_size) / dirty;
107 int64_t fp_term;
108 int64_t fps;
109
110 if (c->gc_stats.in_use <=
BCH_WRITEBACK_FRAGMENT_THRESHOLD_MID) {
111 fp_term = dc->writeback_rate_fp_term_low *
112 (c->gc_stats.in_use -
BCH_WRITEBACK_FRAGMENT_THRESHOLD_LOW);
113 } else if (c->gc_stats.in_use <=
BCH_WRITEBACK_FRAGMENT_THRESHOLD_HIGH) {
114 fp_term = dc->writeback_rate_fp_term_mid *
115 (c->gc_stats.in_use -
BCH_WRITEBACK_FRAGMENT_THRESHOLD_MID);
116 } else {
117 fp_term = dc->writeback_rate_fp_term_high *
118 (c->gc_stats.in_use -
BCH_WRITEBACK_FRAGMENT_THRESHOLD_HIGH);
119 }
> 120
[PATCH] MAINTAINERS: ioat: remove dmaengine susbstem files
[1] mentions the IOAT entry contains dmaengine subsystem file. So update the entry and remove the dmaengine files 1: https://lwn.net/Articles/842415/ Signed-off-by: Vinod Koul --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0d62310a31f8..49647c6a03fd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2872,9 +2872,7 @@ S:Odd fixes W: http://sourceforge.net/projects/xscaleiop F: Documentation/crypto/async-tx-api.rst F: crypto/async_tx/ -F: drivers/dma/ F: include/linux/async_tx.h -F: include/linux/dmaengine.h AT24 EEPROM DRIVER M: Bartosz Golaszewski -- 2.26.2
Re: [PATCH v2 0/2] Add support for USB3 PHY on SDX55
On 11-01-21, 17:00, Manivannan Sadhasivam wrote: > Hello, > > This series adds USB3 PHY support for SDX55 platform. The USB3 PHY is of > type QMP and revision 4.0.0. In this revision, "com_aux" clock is not > utilized. > > This series has been tested on SDX55-MTP along with the relevant DT node. Applied, thanks -- ~Vinod
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
Re: [PATCH] dmaengine: qcom: gpi: Remove unneeded semicolon
On 15-01-21, 10:00, Xu Wang wrote: > fix semicolon.cocci warning: > drivers/dma/qcom/gpi.c:1703:2-3: Unneeded semicolon Applied, thanks -- ~Vinod
Re: Splicing to/from a tty
On Sun Jan 17, 2021 at 5:46 AM NZDT, Johannes Berg wrote:
> On Sat, 2021-01-16 at 20:35 +1300, Oliver Giles wrote:
> > Commit 36e2c7421f02 (fs: don't allow splice read/write without
> > explicit ops) broke my userspace application which talks to an SSL VPN
> > by splice()ing between "openssl s_client" and "pppd". The latter
> > operates over a pty, and since that commit there is no fallback for
> > splice()ing between a pipe and a pty, or any tty for that matter.
> >
> > The above commit mentions switching them to the iter ops and using
> > generic_file_splice_read. IIUC, this would require implementing iter
> > ops also on the line disciplines, which sounds pretty disruptive.
> >
> > For my case, I attempted to instead implement splice_write and
> > splice_read in tty_fops; I managed to get splice_write working calling
> > ld->ops->write, but splice_read is not so simple because the
> > tty_ldisc_ops read method expects a userspace buffer. So I cannot see
> > how to implement this without either (a) using set_fs, or (b)
> > implementing iter ops on all line disciplines.
> >
> > Is splice()ing between a tty and a pipe worth supporting at all? Not a
> > big deal for my use case at least, but it used to work.
>
> Is it even strictly related to the tty?
>
> I was just now looking into why my cgit/fcgi/nginx setup no longer
> works, and the reason is getting -EINVAL from sendfile() when the input
> is a file and the output is a pipe().
>
> So I wrote a simple test program (below) and that errors out on kernel
> 5.10.4, while it works fine on the 5.9.16 I currently have. Haven't
> tried reverting anything yet, but now that I haev a test program it
> should be simple to even bisect.
>
> johannes
>
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char **argv)
> {
> int in = open(argv[0], O_RDONLY);
> int p[2], out;
> off_t off = 0;
> int err;
>
> assert(in >= 0);
> assert(pipe(p) >= 0);
> out = p[1];
> err = sendfile(out, in, , 1024);
> if (err < 0)
> perror("sendfile");
> assert(err == 1024);
>
> return 0;
> }
I can confirm the behaviour you see, and that it starts occurring from the same
commit 36e2c7421f02a22 (fs: don't allow splice read/write without explicit ops).
In my tty case, it is clear that removing the default fallback would cause this
to fail, but assuming the sendfile() source is on a regular filesystem, I am
unsure why splice cannot find the appropriate splice_write method. Could be
connected to the fact that the message from warn_unsupported in fs/splice.c
outputs "splice write not supported for file (pid: 983819 comm:
test-sendfile)",
i.e. the file path is blank. In my case of directly calling splice on a pty, I
do see a path such as /ptyp0 in that error before implementing
splice_(read/write)
callbacks. Maybe splice is getting a bogus file pointer from sendfile?
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
Re: [PATCH v11 0/2] Add Intel LGM SoC DMA support
On 15-01-21, 17:56, Amireddy Mallikarjuna reddy wrote: > Add DMA controller driver for Lightning Mountain (LGM) family of SoCs. > > The main function of the DMA controller is the transfer of data from/to any > peripheral to/from the memory. A memory to memory copy capability can also > be configured. This ldma driver is used for configure the device and channnels > for data and control paths. > > These controllers provide DMA capabilities for a variety of on-chip > devices such as SSC, HSNAND and GSWIP (Gigabit Switch IP). > > - > Future Plans: > - > LGM SOC also supports Hardware Memory Copy engine. > The role of the HW Memory copy engine is to offload memory copy operations > from the CPU. ?? Please send updates against already applied patches and not an updated series! -- ~Vinod
Re: [PATCH next 12/15] arm64: dts: mediatek: mt8183: fix dtbs_check warning
On Sun, Jan 17, 2021 at 9:58 AM Nicolas Boichat wrote:
>
> On Sat, Jan 16, 2021 at 5:07 PM Chunfeng Yun
> wrote:
> >
> > Harmonize node names, compatibles and properties.
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 9 -
> > 1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > index 5b782a4769e7..a69a033a68ac 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > @@ -865,7 +865,7 @@
> > ranges;
> > status = "disabled";
> >
> > - usb_host: xhci@1120 {
> > + usb_host: usb@1120 {
> > compatible = "mediatek,mt8183-xhci",
> > "mediatek,mtk-xhci";
> > reg = <0 0x1120 0 0x1000>;
> > @@ -908,11 +908,11 @@
> > status = "disabled";
> > };
> >
> > - mipi_tx0: mipi-dphy@11e5 {
> > + mipi_tx0: dsi-phy@11e5 {
> > compatible = "mediatek,mt8183-mipi-tx";
> > reg = <0 0x11e5 0 0x1000>;
> > clocks = < CLK_APMIXED_MIPID0_26M>;
> > - clock-names = "ref_clk";
> > + clock-names = "ref";
> > #clock-cells = <0>;
> > #phy-cells = <0>;
> > clock-output-names = "mipi_tx0_pll";
>
> This is unrelated to USB, so this should probably be a separate patch.
Actually, after looking again at the complete stack of patches, I
think this might be ok as part of this overall cleanup (I'll let the
maintainer speak up).
>
> > @@ -931,11 +931,10 @@
> > };
> > };
> >
> > - u3phy: usb-phy@11f4 {
> > + u3phy: t-phy@11f4 {
> > compatible = "mediatek,mt8183-tphy",
> > "mediatek,generic-tphy-v2";
> > #address-cells = <1>;
> > - #phy-cells = <1>;
> > #size-cells = <1>;
> > ranges = <0 0 0x11f4 0x1000>;
> > status = "okay";
> > --
> > 2.18.0
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [RFC PATCH v3 1/2] iommu: Add capability IOMMU_CAP_VIOMMU
On Sat, Jan 16, 2021 at 04:47:40PM +0800, Lu Baolu wrote:
> Hi Leon,
>
> On 2021/1/16 16:39, Leon Romanovsky wrote:
> > On Sat, Jan 16, 2021 at 09:20:16AM +0800, Lu Baolu wrote:
> > > Hi,
> > >
> > > On 2021/1/15 14:31, Leon Romanovsky wrote:
> > > > On Fri, Jan 15, 2021 at 07:49:47AM +0800, Lu Baolu wrote:
> > > > > Hi Leon,
> > > > >
> > > > > On 1/14/21 9:26 PM, Leon Romanovsky wrote:
> > > > > > On Thu, Jan 14, 2021 at 09:30:02AM +0800, Lu Baolu wrote:
> > > > > > > Some vendor IOMMU drivers are able to declare that it is running
> > > > > > > in a VM
> > > > > > > context. This is very valuable for the features that only want to
> > > > > > > be
> > > > > > > supported on bare metal. Add a capability bit so that it could be
> > > > > > > used.
> > > > > >
> > > > > > And how is it used? Who and how will set it?
> > > > >
> > > > > Use the existing iommu_capable(). I should add more descriptions about
> > > > > who and how to use it.
> > > >
> > > > I want to see the code that sets this capability.
> > >
> > > Currently we have Intel VT-d and the virt-iommu setting this capability.
> > >
> > > static bool intel_iommu_capable(enum iommu_cap cap)
> > > {
> > > if (cap == IOMMU_CAP_CACHE_COHERENCY)
> > > return domain_update_iommu_snooping(NULL) == 1;
> > > if (cap == IOMMU_CAP_INTR_REMAP)
> > > return irq_remapping_enabled == 1;
> > > + if (cap == IOMMU_CAP_VIOMMU)
> > > + return caching_mode_enabled();
> > >
> > > return false;
> > > }
> > >
> > > And,
> > >
> > > +static bool viommu_capable(enum iommu_cap cap)
> > > +{
> > > + if (cap == IOMMU_CAP_VIOMMU)
> > > + return true;
> > > +
> > > + return false;
> > > +}
> >
> > These two functions are reading this cap and not setting.
> > Where can I see code that does "cap = IOMMU_CAP_VIOMMU" and not "=="?
>
> The iommu_capable() is a generic IOMMU interface to query IOMMU
> capabilities. It takes @bus and @cap as input, and calls the callback
> of vendor iommu. If the vendor iommu driver supports the specific
> capability, it returns true. Otherwise, it returns false.
>
> bool iommu_capable(struct bus_type *bus, enum iommu_cap cap)
> {
> if (!bus->iommu_ops || !bus->iommu_ops->capable)
> return false;
>
> return bus->iommu_ops->capable(cap);
> }
> EXPORT_SYMBOL_GPL(iommu_capable);
>
> In the vendor iommu's callback, it checks the capability and returns a
> value according to its capability, just as showed above.
Ohh, sorry.
I missed "iommu_capable(dev->bus, IOMMU_CAP_VIOMMU)" from second patch.
Thanks
>
> Best regards,
> baolu
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
hppa64-linux-ld: kernel/bpf/net_namespace.o(.ref.text+0x68): cannot reach bpf_prog_put
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0da0a8a0a0e1845f495431c3d8d733d2bbf9e9e5 commit: b27f7bb590ba835b32ef122389db158e44cfda1e flow_dissector: Move out netns_bpf prog callbacks date: 8 months ago config: parisc-randconfig-r005-20210117 (attached as .config) compiler: hppa64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b27f7bb590ba835b32ef122389db158e44cfda1e git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout b27f7bb590ba835b32ef122389db158e44cfda1e # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): hppa64-linux-ld: kernel/trace/trace_output.o(.text+0x34fc): cannot reach __udivdi3 hppa64-linux-ld: kernel/trace/trace_output.o(.text+0x388c): cannot reach __umoddi3 hppa64-linux-ld: kernel/trace/trace_output.o(.text+0x38a8): cannot reach __udivdi3 hppa64-linux-ld: kernel/trace/trace_output.o(.text+0x38c4): cannot reach __umoddi3 hppa64-linux-ld: kernel/trace/trace_output.o(.text+0x38e0): cannot reach __udivdi3 hppa64-linux-ld: kernel/trace/trace_output.o(.text+0x3be8): cannot reach down_read hppa64-linux-ld: kernel/trace/trace_output.o(.text+0x3cd8): cannot reach down_write hppa64-linux-ld: kernel/trace/trace_output.o(.text+0x4268): cannot reach down_write hppa64-linux-ld: kernel/trace/trace_output.o(.text.exit+0x18): cannot reach __gcov_exit hppa64-linux-ld: kernel/trace/trace_events.o(.text+0xb64): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0xc98): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0xda8): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0xec8): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0xf30): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x1500): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x1534): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x15a0): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x16ac): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x17cc): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x1ac0): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x1b18): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x1ba8): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x1c64): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x1c90): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x1cc0): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x2648): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x2684): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x28bc): cannot reach preempt_schedule hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x2b70): cannot reach preempt_schedule hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x2bac): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x2e18): cannot reach preempt_schedule_notrace hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x2f90): cannot reach preempt_schedule_notrace hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x3418): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x3440): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x354c): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x356c): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x36b0): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x36cc): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x3764): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x4298): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x42d8): cannot reach mutex_unlock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x4694): cannot reach mutex_lock hppa64-linux-ld: kernel/trace/trace_events.o(.text+0x4734): cannot reach mutex_unlock
Re: Change eats memory on my server
On Fri, Jan 15, 2021 at 10:03:50AM +0100, Thomas Zimmermann wrote:
>
> Could you please double-check that 3fb91f56aea4 ("drm/udl: Retrieve USB
> device from struct drm_device.dev") works correctly
Checked again, it does not seem to leak.
> and that 823efa922102
> ("drm/cma-helper: Remove empty drm_gem_cma_prime_vunmap()") is broken?
>
Yes, this one leaks, as does the one preceding it:
1086db71a1db ("drm/vram-helper: Remove invariant parameters from internal kmap
function")
> For one of the broken commits, could you please send us the output of
>
> dmesg | grep -i drm
>
> after most of the memory got leaked?
>
I ran the following script in the shell:
while true; do cat /proc/meminfo | grep MemFree:; sleep 5; done
and this is what I saw before I got disconnected from the shell:
MemFree: 148208 kB
MemFree: 148304 kB
MemFree: 146660 kB
Connection to nps-server-24 closed by remote host.
Connection to nps-server-24 closed.
I also mointored the output of dmesg | grep -i drm
The last output I was able to save on disk is this:
[ 46.140720] ast :03:00.0: [drm] Using P2A bridge for configuration
[ 46.140737] ast :03:00.0: [drm] AST 2500 detected
[ 46.140754] ast :03:00.0: [drm] Analog VGA only
[ 46.140772] ast :03:00.0: [drm] dram MCLK=800 Mhz type=7 bus_width=16
[ 46.153553] [drm] Initialized ast 0.1.0 20120228 for :03:00.0 on minor 0
[ 46.165097] fbcon: astdrmfb (fb0) is primary device
[ 46.391381] ast :03:00.0: [drm] fb0: astdrmfb frame buffer device
[ 56.097697] systemd[1]: Starting Load Kernel Module drm...
[ 56.343556] systemd[1]: modprobe@drm.service: Succeeded.
[ 56.350382] systemd[1]: Finished Load Kernel Module drm.
[13319.469462] [ 2683] 70889 268355586073728 138
0 tdrm
[13320.658386] [ 2683] 70889 268355586073728 138
0 tdrm
[13321.800970] [ 2683] 70889 268355586073728 138
0 tdrm
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
Re: [PATCH v3 0/4] initrd: Use unified initrd reserve function in ARM/RISCV
Correct Russell's mail address (from li...@armlinux.org.uk to rmk+ker...@armlinux.org.uk, should update the MAINTAINERS) On 2021/1/15 13:46, Kefeng Wang wrote: Use the same implementation of initrd reserve to avoid duplication. v3: - split into four patches, suggested-by Palmer Dabbelt v2: - fix build error found by kernel test robot Kefeng Wang (4): initrd: Add the preprocessor guard in initrd.h initramfs: Provide a common initrd reserve function ARM: Covert to reserve_initrd_mem() riscv: Covert to reserve_initrd_mem() arch/arm/mm/init.c | 43 + arch/riscv/mm/init.c | 54 +- include/linux/initrd.h | 11 + init/initramfs.c | 45 +++ 4 files changed, 58 insertions(+), 95 deletions(-)
Re: [PATCH v3 3/4] ARM: Covert to reserve_initrd_mem()
update Russell's mail address.
On 2021/1/15 13:46, Kefeng Wang wrote:
Covert to the generic reserve_initrd_mem() function.
Signed-off-by: Kefeng Wang
---
arch/arm/mm/init.c | 43 +--
1 file changed, 1 insertion(+), 42 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 828a2561b229..a29e14cd626c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -153,47 +153,6 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size,
phys_addr_t align)
return phys;
}
-static void __init arm_initrd_init(void)
-{
-#ifdef CONFIG_BLK_DEV_INITRD
- phys_addr_t start;
- unsigned long size;
-
- initrd_start = initrd_end = 0;
-
- if (!phys_initrd_size)
- return;
-
- /*
-* Round the memory region to page boundaries as per free_initrd_mem()
-* This allows us to detect whether the pages overlapping the initrd
-* are in use, but more importantly, reserves the entire set of pages
-* as we don't want these pages allocated for other purposes.
-*/
- start = round_down(phys_initrd_start, PAGE_SIZE);
- size = phys_initrd_size + (phys_initrd_start - start);
- size = round_up(size, PAGE_SIZE);
-
- if (!memblock_is_region_memory(start, size)) {
- pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - disabling
initrd\n",
- (u64)start, size);
- return;
- }
-
- if (memblock_is_region_reserved(start, size)) {
- pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory region -
disabling initrd\n",
- (u64)start, size);
- return;
- }
-
- memblock_reserve(start, size);
-
- /* Now convert initrd to virtual addresses */
- initrd_start = __phys_to_virt(phys_initrd_start);
- initrd_end = initrd_start + phys_initrd_size;
-#endif
-}
-
#ifdef CONFIG_CPU_ICACHE_MISMATCH_WORKAROUND
void check_cpu_icache_size(int cpuid)
{
@@ -215,7 +174,7 @@ void __init arm_memblock_init(const struct machine_desc
*mdesc)
/* Register the kernel text, kernel data and initrd with memblock. */
memblock_reserve(__pa(KERNEL_START), KERNEL_END - KERNEL_START);
- arm_initrd_init();
+ reserve_initrd_mem();
arm_mm_memblock_reserve();
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Tue, Jan 12, 2021 at 09:43:38PM +, Will Deacon wrote: > On Tue, Jan 12, 2021 at 12:38:34PM -0800, Nadav Amit wrote: > > > On Jan 12, 2021, at 11:56 AM, Yu Zhao wrote: > > > On Tue, Jan 12, 2021 at 11:15:43AM -0800, Nadav Amit wrote: > > >> I will send an RFC soon for per-table deferred TLB flushes tracking. > > >> The basic idea is to save a generation in the page-struct that tracks > > >> when deferred PTE change took place, and track whenever a TLB flush > > >> completed. In addition, other users - such as mprotect - would use > > >> the tlb_gather interface. > > >> > > >> Unfortunately, due to limited space in page-struct this would only > > >> be possible for 64-bit (and my implementation is only for x86-64). > > > > > > I don't want to discourage you but I don't think this would end up > > > well. PPC doesn't necessarily follow one-page-struct-per-table rule, > > > and I've run into problems with this before while trying to do > > > something similar. > > > > Discourage, discourage. Better now than later. > > > > It will be relatively easy to extend the scheme to be per-VMA instead of > > per-table for architectures that prefer it this way. It does require > > TLB-generation tracking though, which Andy only implemented for x86, so I > > will focus on x86-64 right now. > > Can you remind me of what we're missing on arm64 in this area, please? I'm > happy to help get this up and running once you have something I can build > on. I noticed arm/arm64 don't support ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH. Would it be something worth pursuing? Arm has been using mm_cpumask, so it might not be too difficult I guess?
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
[PATCH] sched/fair: Trivial fix for comment of check_preempt_tick
From: Jiang Biao check_preempt_tick() is not just for newly woken task preemption, and check_preempt_wakeup() is instead. The current comment of check_preempt_tick() is a little confusing. Signed-off-by: Jiang Biao --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 04a3ce20da67..c0374c1152e0 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4360,7 +4360,7 @@ dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags) } /* - * Preempt the current task with a newly woken task if needed: + * Preempt the current task with the leftmost task if needed: */ static void check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr) -- 2.21.0
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
Re: [PATCH v6 2/2] Documentation: fpga: dfl: Add description for DFL UIO support
Hi Xu, On Wed, Jan 13, 2021 at 09:54:08AM +0800, Xu Yilun wrote: > This patch adds description for UIO support for dfl devices on DFL > bus. > > Signed-off-by: Xu Yilun > --- > v2: no doc in v1, add it for v2. > v3: some documentation fixes. > v4: documentation change since the driver matching is changed. > v5: no change. > v6: improve the title of the userspace driver support section. > some word improvement. > --- > Documentation/fpga/dfl.rst | 24 > 1 file changed, 24 insertions(+) > > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst > index 0404fe6..c33b6d0 100644 > --- a/Documentation/fpga/dfl.rst > +++ b/Documentation/fpga/dfl.rst > @@ -7,6 +7,7 @@ Authors: > - Enno Luebbers > - Xiao Guangrong > - Wu Hao > +- Xu Yilun > > The Device Feature List (DFL) FPGA framework (and drivers according to > this framework) hides the very details of low layer hardwares and provides > @@ -502,6 +503,29 @@ FME Partial Reconfiguration Sub Feature driver (see > drivers/fpga/dfl-fme-pr.c) > could be a reference. > > > +Userspace driver support for DFL devices > + > +The purpose of an FPGA is to be reprogrammed with newly developed hardware > +components. New hardware can instantiate a new private feature in the DFL, > and > +then get a DFL device in their system. In some cases users may need a > userspace > +driver for the DFL device: > + > +* Users may need to run some diagnostic test for their hardwares. > +* Users may prototype the kernel driver in user space. > +* Some hardware is designed for specific purposes and does not fit into one > of > + the standard kernel subsystems. > + > +This requires direct access to MMIO space and interrupt handling from > +userspace. The dfl-uio-pdev module exposes the UIO device interfaces for this > +purpose. It adds the uio_pdrv_genirq platform device with the resources of > +the DFL feature, and lets the generic UIO platform device driver provide UIO > +support to userspace. > + > +FPGA_DFL_UIO_PDEV should be selected to enable the dfl-uio-pdev module > driver. > +To support a new DFL feature been directly accessed via UIO, its feature id > +should be added to the driver's id_table. > + > + > Open discussion > === > FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial > reconfiguration > -- > 2.7.4 > Looks fine to me, can you resend with changes for the other patch? - Moritz
Re: [PATCH v6 1/2] fpga: dfl: add the userspace I/O device support for DFL devices
Hi Xu,
On Wed, Jan 13, 2021 at 09:54:07AM +0800, Xu Yilun wrote:
> This patch supports the DFL drivers be written in userspace. This is
> realized by exposing the userspace I/O device interfaces.
>
> The driver leverages the uio_pdrv_genirq, it adds the uio_pdrv_genirq
> platform device with the DFL device's resources, and let the generic UIO
> platform device driver provide support to userspace access to kernel
> interrupts and memory locations.
>
> The driver now supports the ether group feature. To support a new DFL
> feature been directly accessed via UIO, its feature id should be added to
> the driver's id_table.
>
> Signed-off-by: Xu Yilun
> Reviewed-by: Tom Rix
> Acked-by: Wu Hao
> ---
> v2: switch to the new matching algorithem. It matches DFL devices which
> could not be handled by other DFL drivers.
> refacor the code about device resources filling.
> fix some comments.
> v3: split the dfl.c changes out of this patch.
> some minor fixes
> v4: drop the idea of a generic matching algorithem, instead we specify
> each matching device in id_table.
> to make clear that only one irq is supported, the irq handling code
> is refactored.
> v5: refactor the irq resource code.
> v6: fix the res[] zero initialization issue.
> improve the return code for probe().
> ---
> drivers/fpga/Kconfig| 10 +
> drivers/fpga/Makefile | 1 +
> drivers/fpga/dfl-uio-pdev.c | 93
> +
> 3 files changed, 104 insertions(+)
> create mode 100644 drivers/fpga/dfl-uio-pdev.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index 5ff9438..61445be 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -203,6 +203,16 @@ config FPGA_DFL_NIOS_INTEL_PAC_N3000
> the card. It also instantiates the SPI master (spi-altera) for
> the card's BMC (Board Management Controller).
>
> +config FPGA_DFL_UIO_PDEV
> + tristate "FPGA DFL Driver for Userspace I/O platform devices"
> + depends on FPGA_DFL && UIO_PDRV_GENIRQ
> + help
> + Enable this to allow some DFL drivers be written in userspace. It
Nit: Enable this to allow DFL drivers to be written in userspace.
> + adds the uio_pdrv_genirq platform device with the DFL feature's
> + resources, and lets the generic UIO platform device driver provide
> + support for userspace access to kernel interrupts and memory
> + locations.
> +
> config FPGA_DFL_PCI
> tristate "FPGA DFL PCIe Device Driver"
> depends on PCI && FPGA_DFL
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 18dc9885..8847fe0 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -45,6 +45,7 @@ dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o
> dfl-afu-dma-region.o
> dfl-afu-objs += dfl-afu-error.o
>
> obj-$(CONFIG_FPGA_DFL_NIOS_INTEL_PAC_N3000) += dfl-n3000-nios.o
> +obj-$(CONFIG_FPGA_DFL_UIO_PDEV) += dfl-uio-pdev.o
>
> # Drivers for FPGAs which implement DFL
> obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
> diff --git a/drivers/fpga/dfl-uio-pdev.c b/drivers/fpga/dfl-uio-pdev.c
> new file mode 100644
> index 000..12b47bf
> --- /dev/null
> +++ b/drivers/fpga/dfl-uio-pdev.c
> @@ -0,0 +1,93 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DFL driver for Userspace I/O platform devices
> + *
> + * Copyright (C) 2020 Intel Corporation, Inc.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "dfl-uio-pdev"
> +
> +static int dfl_uio_pdev_probe(struct dfl_device *ddev)
> +{
> + struct platform_device_info pdevinfo = { 0 };
> + struct resource res[2] = { { 0 } };
> + struct uio_info uio_pdata = { 0 };
> + struct platform_device *uio_pdev;
> + struct device *dev = >dev;
> + unsigned int num_res = 1;
> +
> + res[0].parent = >mmio_res;
> + res[0].flags = IORESOURCE_MEM;
> + res[0].start = ddev->mmio_res.start;
> + res[0].end = ddev->mmio_res.end;
> +
> + if (ddev->num_irqs) {
> + if (ddev->num_irqs > 1)
> + dev_warn(>dev,
> + "%d irqs for %s, but UIO only supports the
> first one\n",
> + ddev->num_irqs, dev_name(>dev));
> +
> + res[1].flags = IORESOURCE_IRQ;
> + res[1].start = ddev->irqs[0];
> + res[1].end = ddev->irqs[0];
> + num_res++;
> + }
> +
> + uio_pdata.name = DRIVER_NAME;
> + uio_pdata.version = "0";
> +
> + pdevinfo.name = "uio_pdrv_genirq";
> + pdevinfo.res = res;
> + pdevinfo.num_res = num_res;
> + pdevinfo.parent = >dev;
> + pdevinfo.id = PLATFORM_DEVID_AUTO;
> + pdevinfo.data = _pdata;
> + pdevinfo.size_data = sizeof(uio_pdata);
> +
> + uio_pdev = platform_device_register_full();
It looks like:
platform_device_register_resndata(>dev, "uio_pdrv_genirq",
Re: [PATCH v2] selftests: drivers: fpga: A test for interrupt support
Hi Tom,
On Sat, Jan 16, 2021 at 11:33:21AM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> Check that the ioctl DFL_FPGA_PORT_ERR_GET_IRQ_NUM returns
> an expected result.
>
> Tested on vf device 0xbcc1
>
> Sample run with
> # make -C tools/testing/selftests TARGETS=drivers/fpga run_tests
> ...
> TAP version 13
> 1..1
> # selftests: drivers/fpga: intr
> # TAP version 13
> # 1..1
> # # Starting 1 tests from 1 test cases.
> # # RUN global.afu_intr ...
> # #OK global.afu_intr
> # ok 1 global.afu_intr
> # # PASSED: 1 / 1 tests passed.
> # # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
> ok 1 selftests: drivers/fpga: intr
>
> Signed-off-by: Tom Rix
> ---
> v1: Convert to kselftest_harness.h framework
> ---
> MAINTAINERS | 1 +
> tools/testing/selftests/Makefile | 1 +
> tools/testing/selftests/drivers/fpga/Makefile | 7
> tools/testing/selftests/drivers/fpga/config | 1 +
> tools/testing/selftests/drivers/fpga/intr.c | 36 +++
> 5 files changed, 46 insertions(+)
> create mode 100644 tools/testing/selftests/drivers/fpga/Makefile
> create mode 100644 tools/testing/selftests/drivers/fpga/config
> create mode 100644 tools/testing/selftests/drivers/fpga/intr.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index de610a06cb5c..7ed3ce58d95e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6973,6 +6973,7 @@ F: Documentation/driver-api/fpga/
> F: Documentation/fpga/
> F: drivers/fpga/
> F: include/linux/fpga/
> +F: tools/testing/selftests/drivers/fpga/
>
> FPGA SECURITY MANAGER DRIVERS
> M: Russ Weight
> diff --git a/tools/testing/selftests/Makefile
> b/tools/testing/selftests/Makefile
> index afbab4aeef3c..aad4763ec348 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -9,6 +9,7 @@ TARGETS += core
> TARGETS += cpufreq
> TARGETS += cpu-hotplug
> TARGETS += drivers/dma-buf
> +TARGETS += drivers/fpga
> TARGETS += efivarfs
> TARGETS += exec
> TARGETS += filesystems
> diff --git a/tools/testing/selftests/drivers/fpga/Makefile
> b/tools/testing/selftests/drivers/fpga/Makefile
> new file mode 100644
> index ..eba35c405d5b
> --- /dev/null
> +++ b/tools/testing/selftests/drivers/fpga/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +CFLAGS += -I../../../../../usr/include/
> +CFLAGS += -I../../../../../include/uapi/
> +
> +TEST_GEN_PROGS := intr
> +
> +include ../../lib.mk
> diff --git a/tools/testing/selftests/drivers/fpga/config
> b/tools/testing/selftests/drivers/fpga/config
> new file mode 100644
> index ..e2111b81d8d7
> --- /dev/null
> +++ b/tools/testing/selftests/drivers/fpga/config
> @@ -0,0 +1 @@
> +CONFIG_FPGA_DFL_AFU=m
> diff --git a/tools/testing/selftests/drivers/fpga/intr.c
> b/tools/testing/selftests/drivers/fpga/intr.c
> new file mode 100644
> index ..b362fb1f788d
> --- /dev/null
> +++ b/tools/testing/selftests/drivers/fpga/intr.c
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "../../kselftest_harness.h"
Is that how it works with selftests?
> +
> +TEST(afu_intr)
> +{
> + int devfd, status;
> + struct dfl_fpga_port_info port_info;
> + uint32_t irq_num = UINT32_MAX;
Can you order those?
xx
x
> +
> + devfd = open("/dev/dfl-port.0", O_RDONLY);
> + if (devfd < 0)
> + SKIP(0, "no fpga afu device 0");
> + /*
> + * From fpga-dl.h :
> + * Currently hardware supports up to 1 irq.
> + * Return: 0 on success, -errno on failure.
> + */
> + status = ioctl(devfd, DFL_FPGA_PORT_ERR_GET_IRQ_NUM, _num);
> + ASSERT_EQ(0, status) {
> + TH_LOG("ioctl() failed to get the number irqs");
> + }
> + ASSERT_LT(irq_num, 256) {
> + TH_LOG("unexpeced number of irqs");
> + }
> + close(devfd);
> +}
> +
> +TEST_HARNESS_MAIN
> --
> 2.27.0
>
Thanks for starting this, I don't know a lot about selftests (yet).
So we probably want to get a look at this from corresponding maintainers.
- Moritz
[git pull] vfs.git fixes
Several assorted fixes. I still think that audit ->d_name race is better fixed that way for the benefit of backports, with any fancier variants done on top of that. The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes for you to fetch changes up to d36a1dd9f77ae1e72da48f4123ed35627848507d: dump_common_audit_data(): fix racy accesses to ->d_name (2021-01-16 15:11:35 -0500) Al Viro (2): umount(2): move the flag validity checks first dump_common_audit_data(): fix racy accesses to ->d_name Christoph Hellwig (1): iov_iter: fix the uaccess area in copy_compat_iovec_from_user fs/namespace.c | 7 +-- lib/iov_iter.c | 2 +- security/lsm_audit.c | 7 +-- 3 files changed, 11 insertions(+), 5 deletions(-)
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
Re: [PATCH net-next 7/7] net: ipa: allow arbitrary number of interconnects
On Fri, 15 Jan 2021 06:50:50 -0600 Alex Elder wrote: > Currently we assume that the IPA hardware has exactly three > interconnects. But that won't be guaranteed for all platforms, > so allow any number of interconnects to be specified in the > configuration data. > > For each platform, define an array of interconnect data entries > (still associated with the IPA clock structure), and record the > number of entries initialized in that array. > > Loop over all entries in this array when initializing, enabling, > disabling, or tearing down the set of interconnects. > > With this change we no longer need the ipa_interconnect_id > enumerated type, so get rid of it. Okay, all the platforms supported as of the end of the series still have 3 interconnects, or there is no upstream user of this functionality, if you will. What's the story?
Re: [PATCH] net: mscc: ocelot: Remove unneeded semicolon
Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Fri, 15 Jan 2021 09:55:44 + you wrote: > fix semicolon.cocci warnings: > drivers/net/ethernet/mscc/ocelot_net.c:460:2-3: Unneeded semicolon > > Signed-off-by: Xu Wang > --- > drivers/net/ethernet/mscc/ocelot_net.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Here is the summary with links: - net: mscc: ocelot: Remove unneeded semicolon https://git.kernel.org/netdev/net-next/c/20efd2c79afb You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH v2 net] skbuff: back tiny skbs with kmalloc() in __netdev_alloc_skb() too
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Fri, 15 Jan 2021 15:04:40 + you wrote:
> Commit 3226b158e67c ("net: avoid 32 x truesize under-estimation for
> tiny skbs") ensured that skbs with data size lower than 1025 bytes
> will be kmalloc'ed to avoid excessive page cache fragmentation and
> memory consumption.
> However, the fix adressed only __napi_alloc_skb() (primarily for
> virtio_net and napi_get_frags()), but the issue can still be achieved
> through __netdev_alloc_skb(), which is still used by several drivers.
> Drivers often allocate a tiny skb for headers and place the rest of
> the frame to frags (so-called copybreak).
> Mirror the condition to __netdev_alloc_skb() to handle this case too.
>
> [...]
Here is the summary with links:
- [v2,net] skbuff: back tiny skbs with kmalloc() in __netdev_alloc_skb() too
https://git.kernel.org/netdev/net/c/66c556025d68
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH v3] proc_sysctl: fix oops caused by incorrect command parameters.
On 2021/1/12 19:42, Vlastimil Babka wrote: On 1/12/21 8:24 AM, Michal Hocko wrote: If we're going to do a separate "patch: make process_sysctl_arg() return an errno instead of 0" then fine, we can discuss that. But it's conceptually a different work from fixing this situation. . However, are the logs generated by process_sysctl_arg() clearer and more accurate than parse_args()? Should the logs generated by process_sysctl_arg() be deleted? I think the individual logs are very useful and should be retained. Yes, other sysfs specific error messages are likely useful. I just fail to see why a missing value should be handled here when there is an existing handling in the caller. Not sure whether a complete shadow reporting in process_sysctl_arg is a deliberate decision or not. Vlastimil? Yes, it's a way to have more useful sysctl-specific reports than the generic ones. And I think I was inspired by some other existing code, but don't remember exactly. The options are: 1) the current sysctl-specific reports, return 0 as the values are only consumed 2) be silent and return error, invent new error codes to have generic report be more useful for sysctl, but inevitably lose some nuances anyway 3) a mix where 2) is used for situations where generic report is sufficient enough, 1) where not Patch v2 went with option 1), v3 with option 3). I think it's down to preferences. I would personally go with v2 and message similar to the existing ones, i.e.: "Failed to set sysctl parameter '%s': no value given\n" Also we seem to be silently doing nothing when strlen(val) == 0, i.e. "hung_task_panic=" was passed. Worth reporting the same error. But v3 is fine with me as well. The generic error message works. We could just add "if (!len) return -EINVAL" below the strlen() call. Also please Cc: stable. Anyway one way or the other, all I care about is to have a reporting in place because this shouldn't be a silent failure. The current v2 is already in the linux-next branch and throws a new error: https://lore.kernel.org/lkml/cb54e349-7147-0a1f-a349-1e16ba603...@infradead.org/ This bug has been mentioned in the previous discussion and has been fixed in the current v3 patch. https://lore.kernel.org/linux-fsdevel/20210149.20A58E1@keescook/ What am I supposed to do now? - Resend V3? - Rewrite a new fix patch based on the current code of linux-next. - Develop a new V4 patch: Use V2 to discuss how to use the Patch4 solution. https://lore.kernel.org/linux-fsdevel/bc098af4-c0cd-212e-d09d-46d617d0a...@huawei.com/#t Thanks Xiaoming Ni
Re: [PATCH v3 net-next] net: bridge: check vlan with eth_type_vlan() method
On Thu, 14 Jan 2021 20:41:31 -0800 menglong8.d...@gmail.com wrote:
> - if (data[IFLA_BR_VLAN_PROTOCOL]) {
> - switch (nla_get_be16(data[IFLA_BR_VLAN_PROTOCOL])) {
> - case htons(ETH_P_8021Q):
> - case htons(ETH_P_8021AD):
> - break;
> - default:
> - return -EPROTONOSUPPORT;
> - }
> + if (data[IFLA_BR_VLAN_PROTOCOL] &&
> + !eth_type_vlan(nla_get_be16(data[IFLA_BR_VLAN_PROTOCOL]))) {
> + return -EPROTONOSUPPORT;
> }
The curly brackets are no longer necessary here, since it's a single
line expression.
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
Re: [PATCH 2/2] io_uring: fix uring_flush in exit_files() warning
On 17/01/2021 02:31, Hillf Danton wrote:
> On Sat, 16 Jan 2021 05:32:30 + Pavel Begunkov wrote:
>>
>> @@ -9126,7 +9126,10 @@ static int io_uring_flush(struct file *file, void
>> *data)
>>
>> if (ctx->flags & IORING_SETUP_SQPOLL) {
>> /* there is only one file note, which is owned by sqo_task */
>> -WARN_ON_ONCE((ctx->sqo_task == current) ==
>> +WARN_ON_ONCE(ctx->sqo_task != current &&
>> + xa_load(>xa, (unsigned long)file));
>> +/* sqo_dead check is for when this happens after cancellation */
>> +WARN_ON_ONCE(ctx->sqo_task == current && !ctx->sqo_dead &&
>> !xa_load(>xa, (unsigned long)file));
>>
>> io_disable_sqo_submit(ctx);
>
> The added sqo_dead flag can not only quiesce a warning but save a
> disabling dryrun.
Don't think I get the sentence. Do you see any issue?
sqo_dead has a practical meaning, it prevents SQPOLL task from poking
into the creator task when it's racy. But yes, also in some cases makes
draining and killing rings nicer.
--
Pavel Begunkov
Re: [PATCH net 0/2] ipv6: fixes for the multicast routes
On Sat, Jan 16, 2021 at 5:41 AM David Ahern wrote:
>
> On 1/15/21 4:12 PM, Matteo Croce wrote:
> > On Fri, Jan 15, 2021 at 11:50 PM Jakub Kicinski wrote:
> >>
> >> On Fri, 15 Jan 2021 19:42:07 +0100 Matteo Croce wrote:
> >>> From: Matteo Croce
> >>>
> >>> Fix two wrong flags in the IPv6 multicast routes created
> >>> by the autoconf code.
> >>
> >> Any chance for Fixes tags here?
> >
> > Right.
> > For 1/2 I don't know exactly, that code was touched last time in
> > 86872cb57925 ("[IPv6] route: FIB6 configuration using struct
> > fib6_config"), but it was only refactored. Before 86872cb57925, it was
> > pushed in the git import commit by Linus: 1da177e4c3f4
> > ("Linux-2.6.12-rc2").
> > BTW, according the history repo, it entered the tree in the 2.4.0
> > import, so I'd say it's here since the beginning.
> >
> > While for 2/2 I'd say:
> >
> > Fixes: e8478e80e5a7 ("net/ipv6: Save route type in rt6_info")
> >
>
> As I recall (memory jogging from commit description) my patch only moved
> the setting from ip6_route_info_create default to here.
>
> The change is correct, just thinking it goes back beyond 4.16. If
> someone has a system running a 4.14 or earlier kernel it should be easy
> to know if this was the default prior.
Indeed, it was the same long before 4.14:
# uname -a
Linux ubuntu 4.4.0-142-generic #168~14.04.1-Ubuntu SMP Sat Jan 19
11:26:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
# ip -6 -d route show table local dev eth0
unicast ff00::/8 proto boot scope global metric 256 pref medium
Regards,
--
per aspera ad upstream
Re: [RESEND v2 0/7] Rid W=1 warnings in Ethernet
Hello: This series was applied to netdev/net-next.git (refs/heads/master): On Fri, 15 Jan 2021 20:08:58 + you wrote: > Resending the stragglers again. > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > No changes since v2, just a rebase onto net-next. > > [...] Here is the summary with links: - [1/7] net: ethernet: smsc: smc91x: Fix function name in kernel-doc header https://git.kernel.org/netdev/net-next/c/7d2a92445e3f - [2/7] net: xen-netback: xenbus: Demote nonconformant kernel-doc headers https://git.kernel.org/netdev/net-next/c/090c7ae8e0d0 - [3/7] net: ethernet: ti: am65-cpsw-qos: Demote non-conformant function header https://git.kernel.org/netdev/net-next/c/935888cda820 - [4/7] net: ethernet: ti: am65-cpts: Document am65_cpts_rx_enable()'s 'en' parameter https://git.kernel.org/netdev/net-next/c/e49e4647f3e2 - [5/7] net: ethernet: ibm: ibmvnic: Fix some kernel-doc misdemeanours https://git.kernel.org/netdev/net-next/c/807086021bf5 - [6/7] net: ethernet: toshiba: ps3_gelic_net: Fix some kernel-doc misdemeanours https://git.kernel.org/netdev/net-next/c/b51036321461 - [7/7] net: ethernet: toshiba: spider_net: Document a whole bunch of function parameters https://git.kernel.org/netdev/net-next/c/e242d5989965 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
Re: [PATCH v2] fs/cifs: Simplify bool comparison.
The patch wouldn't merge (probably fixed with an earlier patch) so I
removed the second part of it (ie the change around line 3740) - see
below and merged the smaller change below into cifs-2.6.git for-next
commit d1639d92fc762bf80273aaf52d87eb780711714c (HEAD -> for-next,
origin/for-next)
Author: Jiapeng Zhong
Date: Thu Jan 14 18:02:23 2021 +0800
fs/cifs: Simplify bool comparison.
Fix the follow warnings:
./fs/cifs/connect.c: WARNING: Comparison of 0/1 to bool variable
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Zhong
Signed-off-by: Steve French
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 7c3325c0fadc..c8ef24bac94f 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2628,7 +2628,7 @@ void reset_cifs_unix_caps(unsigned int xid,
struct cifs_tcon *tcon,
} else if (ctx)
tcon->unix_ext = 1; /* Unix Extensions supported */
- if (tcon->unix_ext == 0) {
+ if (!tcon->unix_ext) {
cifs_dbg(FYI, "Unix extensions disabled so not set on
reconnect\n");
return;
}
On Thu, Jan 14, 2021 at 4:07 AM Jiapeng Zhong
wrote:
>
> Fix the follow warnings:
>
> ./fs/cifs/connect.c: WARNING: Comparison of 0/1 to bool variable
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Zhong
>
> ---
> Changes in v2:
> -Modified subject.
>
> fs/cifs/connect.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index b9df855..b7869a2 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -2628,7 +2628,7 @@ void reset_cifs_unix_caps(unsigned int xid, struct
> cifs_tcon *tcon,
> } else if (ctx)
> tcon->unix_ext = 1; /* Unix Extensions supported */
>
> - if (tcon->unix_ext == 0) {
> + if (!tcon->unix_ext) {
> cifs_dbg(FYI, "Unix extensions disabled so not set on
> reconnect\n");
> return;
> }
> @@ -3740,7 +3740,7 @@ static void delayed_free(struct rcu_head *p)
>
> if (!ses->binding) {
> ses->capabilities = server->capabilities;
> - if (linuxExtEnabled == 0)
> + if (!linuxExtEnabled)
> ses->capabilities &= (~server->vals->cap_unix);
>
> if (ses->auth_key.response) {
> --
> 1.8.3.1
>
--
Thanks,
Steve
Re: [PATCH v2 bpf-next 2/2] selftests: bpf: Add a new test for bare tracepoints
On 1/16/21 10:21 AM, Qais Yousef wrote:
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
---
.../bpf/bpf_testmod/bpf_testmod-events.h | 6 +
.../selftests/bpf/bpf_testmod/bpf_testmod.c | 21 ++-
.../selftests/bpf/bpf_testmod/bpf_testmod.h | 6 +
.../selftests/bpf/prog_tests/module_attach.c | 27 +++
.../selftests/bpf/progs/test_module_attach.c | 10 +++
5 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod-events.h
b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod-events.h
index b83ea448bc79..89c6d58e5dd6 100644
--- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod-events.h
+++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod-events.h
@@ -28,6 +28,12 @@ TRACE_EVENT(bpf_testmod_test_read,
__entry->pid, __entry->comm, __entry->off, __entry->len)
);
+/* A bare tracepoint with no event associated with it */
+DECLARE_TRACE(bpf_testmod_test_write_bare,
+ TP_PROTO(struct task_struct *task, struct bpf_testmod_test_write_ctx
*ctx),
+ TP_ARGS(task, ctx)
+);
+
#endif /* _BPF_TESTMOD_EVENTS_H */
#undef TRACE_INCLUDE_PATH
diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
index 2df19d73ca49..e900adad2276 100644
--- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
+++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
@@ -28,9 +28,28 @@ bpf_testmod_test_read(struct file *file, struct kobject
*kobj,
EXPORT_SYMBOL(bpf_testmod_test_read);
ALLOW_ERROR_INJECTION(bpf_testmod_test_read, ERRNO);
+noinline ssize_t
+bpf_testmod_test_write(struct file *file, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t len)
+{
+ struct bpf_testmod_test_write_ctx ctx = {
+ .buf = buf,
+ .off = off,
+ .len = len,
+ };
+
+ trace_bpf_testmod_test_write_bare(current, );
+
+ return -EIO; /* always fail */
+}
+EXPORT_SYMBOL(bpf_testmod_test_write);
+ALLOW_ERROR_INJECTION(bpf_testmod_test_write, ERRNO);
+
static struct bin_attribute bin_attr_bpf_testmod_file __ro_after_init = {
Do we need to remove __ro_after_init?
- .attr = { .name = "bpf_testmod", .mode = 0444, },
+ .attr = { .name = "bpf_testmod", .mode = 0666, },
.read = bpf_testmod_test_read,
+ .write = bpf_testmod_test_write,
};
static int bpf_testmod_init(void)
diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.h
b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.h
index b81adfedb4f6..b3892dc40111 100644
--- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.h
+++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.h
@@ -11,4 +11,10 @@ struct bpf_testmod_test_read_ctx {
size_t len;
};
+struct bpf_testmod_test_write_ctx {
+ char *buf;
+ loff_t off;
+ size_t len;
+};
+
#endif /* _BPF_TESTMOD_H */
diff --git a/tools/testing/selftests/bpf/prog_tests/module_attach.c
b/tools/testing/selftests/bpf/prog_tests/module_attach.c
index 50796b651f72..e4605c0b5af1 100644
--- a/tools/testing/selftests/bpf/prog_tests/module_attach.c
+++ b/tools/testing/selftests/bpf/prog_tests/module_attach.c
@@ -21,9 +21,34 @@ static int trigger_module_test_read(int read_sz)
return 0;
}
+static int trigger_module_test_write(int write_sz)
+{
+ int fd, err;
Init err = 0?
+ char *buf = malloc(write_sz);
+
+ if (!buf)
+ return -ENOMEM;
Looks like we already non-negative value, so return ENOMEM?
+
+ memset(buf, 'a', write_sz);
+ buf[write_sz-1] = '\0';
+
+ fd = open("/sys/kernel/bpf_testmod", O_WRONLY);
+ err = -errno;
+ if (CHECK(fd < 0, "testmod_file_open", "failed: %d\n", err))
+ goto out;
Change the above to
fd = open("/sys/kernel/bpf_testmod", O_WRONLY);
if (CHECK(fd < 0, "testmod_file_open", "failed: %d\n", errno)) {
err = -errno;
goto out;
}
+
+ write(fd, buf, write_sz);
+ close(fd);
+out:
+ free(buf);
+
No need for extra line here.
+ return 0;
return err.
+}
+
void test_module_attach(void)
{
const int READ_SZ = 456;
+ const int WRITE_SZ = 457;
struct test_module_attach* skel;
struct test_module_attach__bss *bss;
int err;
@@ -48,8 +73,10 @@ void test_module_attach(void)
/* trigger tracepoint */
ASSERT_OK(trigger_module_test_read(READ_SZ), "trigger_read");
+ ASSERT_OK(trigger_module_test_write(WRITE_SZ), "trigger_write");
ASSERT_EQ(bss->raw_tp_read_sz, READ_SZ, "raw_tp");
+ ASSERT_EQ(bss->raw_tp_bare_write_sz, WRITE_SZ, "raw_tp_bare");
Re: [PATCH] fs/cifs: Assign boolean values to a bool variable
merged into cifs-2.6.git for-next On Thu, Jan 14, 2021 at 3:11 AM Jiapeng Zhong wrote: > > Fix the following coccicheck warnings: > > ./fs/cifs/connect.c:3386:2-21: WARNING: Assignment of 0/1 to > bool variable. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Zhong > --- > fs/cifs/connect.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c > index b9df855..8fbb5ea 100644 > --- a/fs/cifs/connect.c > +++ b/fs/cifs/connect.c > @@ -2195,7 +2195,7 @@ static int match_tcon(struct cifs_tcon *tcon, struct > smb3_fs_context *ctx) > if (ses->server->capabilities & SMB2_GLOBAL_CAP_DIRECTORY_LEASING) > tcon->nohandlecache = ctx->nohandlecache; > else > - tcon->nohandlecache = 1; > + tcon->nohandlecache = true; > tcon->nodelete = ctx->nodelete; > tcon->local_lease = ctx->local_lease; > INIT_LIST_HEAD(>pending_opens); > -- > 1.8.3.1 > -- Thanks, Steve
Re: [PATCH v2 bpf-next 1/2] trace: bpf: Allow bpf to attach to bare tracepoints
On 1/16/21 10:21 AM, Qais Yousef wrote: Some subsystems only have bare tracepoints (a tracepoint with no associated trace event) to avoid the problem of trace events being an ABI that can't be changed. From bpf presepective, bare tracepoints are what it calls RAW_TRACEPOINT(). Since bpf assumed there's 1:1 mapping, it relied on hooking to DEFINE_EVENT() macro to create bpf mapping of the tracepoints. Since bare tracepoints use DECLARE_TRACE() to create the tracepoint, bpf had no knowledge about their existence. By teaching bpf_probe.h to parse DECLARE_TRACE() in a similar fashion to DEFINE_EVENT(), bpf can find and attach to the new raw tracepoints. Enabling that comes with the contract that changes to raw tracepoints don't constitute a regression if they break existing bpf programs. We need the ability to continue to morph and modify these raw tracepoints without worrying about any ABI. Update Documentation/bpf/bpf_design_QA.rst to document this contract. Signed-off-by: Qais Yousef Acked-by: Yonghong Song
Re: [PATCH next 12/15] arm64: dts: mediatek: mt8183: fix dtbs_check warning
On Sat, Jan 16, 2021 at 5:07 PM Chunfeng Yun wrote:
>
> Harmonize node names, compatibles and properties.
>
> Signed-off-by: Chunfeng Yun
> ---
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 5b782a4769e7..a69a033a68ac 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -865,7 +865,7 @@
> ranges;
> status = "disabled";
>
> - usb_host: xhci@1120 {
> + usb_host: usb@1120 {
> compatible = "mediatek,mt8183-xhci",
> "mediatek,mtk-xhci";
> reg = <0 0x1120 0 0x1000>;
> @@ -908,11 +908,11 @@
> status = "disabled";
> };
>
> - mipi_tx0: mipi-dphy@11e5 {
> + mipi_tx0: dsi-phy@11e5 {
> compatible = "mediatek,mt8183-mipi-tx";
> reg = <0 0x11e5 0 0x1000>;
> clocks = < CLK_APMIXED_MIPID0_26M>;
> - clock-names = "ref_clk";
> + clock-names = "ref";
> #clock-cells = <0>;
> #phy-cells = <0>;
> clock-output-names = "mipi_tx0_pll";
This is unrelated to USB, so this should probably be a separate patch.
> @@ -931,11 +931,10 @@
> };
> };
>
> - u3phy: usb-phy@11f4 {
> + u3phy: t-phy@11f4 {
> compatible = "mediatek,mt8183-tphy",
> "mediatek,generic-tphy-v2";
> #address-cells = <1>;
> - #phy-cells = <1>;
> #size-cells = <1>;
> ranges = <0 0 0x11f4 0x1000>;
> status = "okay";
> --
> 2.18.0
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
lib/zstd/compress.c:1393:1: warning: the frame size of 1436 bytes is larger than 1280 bytes
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0da0a8a0a0e1845f495431c3d8d733d2bbf9e9e5
commit: 6d25a633ea68a103c7293d16eb69a7d4689075ad lib: Prepare zstd for preboot
environment, improve performance
date: 6 months ago
config: parisc-randconfig-r026-20210117 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6d25a633ea68a103c7293d16eb69a7d4689075ad
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 6d25a633ea68a103c7293d16eb69a7d4689075ad
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=parisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
lib/zstd/compress.c:434:8: warning: no previous prototype for
'ZSTD_noCompressBlock' [-Wmissing-prototypes]
434 | size_t ZSTD_noCompressBlock(void *dst, size_t dstCapacity, const
void *src, size_t srcSize)
|^~~~
lib/zstd/compress.c:2252:6: warning: no previous prototype for
'ZSTD_compressBlock_greedy_extDict' [-Wmissing-prototypes]
2252 | void ZSTD_compressBlock_greedy_extDict(ZSTD_CCtx *ctx, const void
*src, size_t srcSize) { ZSTD_compressBlock_lazy_extDict_generic(ctx, src,
srcSize, 0, 0); }
| ^
lib/zstd/compress.c:2982:15: warning: no previous prototype for
'ZSTD_createCStream_advanced' [-Wmissing-prototypes]
2982 | ZSTD_CStream *ZSTD_createCStream_advanced(ZSTD_customMem customMem)
| ^~~
In file included from lib/zstd/compress.c:23:
lib/zstd/zstd_internal.h:83:21: warning: 'ZSTD_did_fieldSize' defined but
not used [-Wunused-const-variable=]
83 | static const size_t ZSTD_did_fieldSize[4] = {0, 1, 2, 4};
| ^~
lib/zstd/zstd_internal.h:82:21: warning: 'ZSTD_fcs_fieldSize' defined but
not used [-Wunused-const-variable=]
82 | static const size_t ZSTD_fcs_fieldSize[4] = {0, 2, 4, 8};
| ^~
In file included from lib/zstd/error_private.h:26,
from lib/zstd/bitstream.h:53,
from lib/zstd/fse.h:228,
from lib/zstd/compress.c:20:
include/linux/zstd.h:798:21: warning: 'ZSTD_skippableHeaderSize' defined but
not used [-Wunused-const-variable=]
798 | static const size_t ZSTD_skippableHeaderSize = 8;
| ^~~~
include/linux/zstd.h:795:21: warning: 'ZSTD_frameHeaderSize_min' defined but
not used [-Wunused-const-variable=]
795 | static const size_t ZSTD_frameHeaderSize_min =
ZSTD_FRAMEHEADERSIZE_MIN;
| ^~~~
include/linux/zstd.h:794:21: warning: 'ZSTD_frameHeaderSize_prefix' defined
but not used [-Wunused-const-variable=]
794 | static const size_t ZSTD_frameHeaderSize_prefix = 5;
| ^~~
lib/zstd/compress.c: In function 'ZSTD_compressBlock_doubleFast':
>> lib/zstd/compress.c:1393:1: warning: the frame size of 1436 bytes is larger
>> than 1280 bytes [-Wframe-larger-than=]
1393 | }
| ^
vim +1393 lib/zstd/compress.c
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1382
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1383 static void
ZSTD_compressBlock_doubleFast(ZSTD_CCtx *ctx, const void *src, size_t srcSize)
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1384 {
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1385 const U32 mls =
ctx->params.cParams.searchLength;
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1386 switch (mls) {
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1387 default: /* includes
case 3 */
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1388 case 4:
ZSTD_compressBlock_doubleFast_generic(ctx, src, srcSize, 4); return;
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1389 case 5:
ZSTD_compressBlock_doubleFast_generic(ctx, src, srcSize, 5); return;
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1390 case 6:
ZSTD_compressBlock_doubleFast_generic(ctx, src, srcSize, 6); return;
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1391 case 7:
ZSTD_compressBlock_doubleFast_generic(ctx, src, srcSize, 7); return;
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1392 }
73f3d1b48f5069d4 Nick Terrell 2017-08-09 @1393 }
73f3d1b48f5069d4 Nick Terrell 2017-08-09 1394
:: The code at line 1393 was first introduced by commit
::
Re: [PATCH v8 3/7] mfd: Add base driver for Netronix embedded controller
Hi "Jonathan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on robh/for-next pwm/for-next abelloni/rtc-next
linus/master v5.11-rc3 next-20210115]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jonathan-Neusch-fer/Netronix-embedded-controller-driver-for-Kobo-and-Tolino-ebook-readers/20210117-050203
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: mips-randconfig-r001-20210117 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
2082b10d100e8dbaffc2ba8f497db5d2ab61beb2)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://github.com/0day-ci/linux/commit/eee80e6b3b7cc2c733bd3f10d8e2ec23dda2fe26
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jonathan-Neusch-fer/Netronix-embedded-controller-driver-for-Kobo-and-Tolino-ebook-readers/20210117-050203
git checkout eee80e6b3b7cc2c733bd3f10d8e2ec23dda2fe26
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/mfd/ntxec.c:127:10: warning: variable 'res' is uninitialized when
>> used here [-Wuninitialized]
return res;
^~~
drivers/mfd/ntxec.c:116:9: note: initialize the variable 'res' to silence
this warning
int res;
^
= 0
1 warning generated.
vim +/res +127 drivers/mfd/ntxec.c
111
112 static int ntxec_probe(struct i2c_client *client)
113 {
114 struct ntxec *ec;
115 unsigned int version;
116 int res;
117
118 ec = devm_kmalloc(>dev, sizeof(*ec), GFP_KERNEL);
119 if (!ec)
120 return -ENOMEM;
121
122 ec->dev = >dev;
123
124 ec->regmap = devm_regmap_init_i2c(client, _config);
125 if (IS_ERR(ec->regmap)) {
126 dev_err(ec->dev, "Failed to set up regmap for
device\n");
> 127 return res;
128 }
129
130 /* Determine the firmware version */
131 res = regmap_read(ec->regmap, NTXEC_REG_VERSION, );
132 if (res < 0) {
133 dev_err(ec->dev, "Failed to read firmware version
number\n");
134 return res;
135 }
136
137 /* Bail out if we encounter an unknown firmware version */
138 switch (version) {
139 case NTXEC_VERSION_KOBO_AURA:
140 break;
141 default:
142 dev_err(ec->dev,
143 "Netronix embedded controller version %04x is
not supported.\n",
144 version);
145 return -ENODEV;
146 }
147
148 dev_info(ec->dev,
149 "Netronix embedded controller version %04x
detected.\n", version);
150
151 if (of_device_is_system_power_controller(ec->dev->of_node)) {
152 /*
153 * Set the 'powerkeep' bit. This is necessary on some
boards
154 * in order to keep the system running.
155 */
156 res = regmap_write(ec->regmap, NTXEC_REG_POWERKEEP,
157 NTXEC_POWERKEEP_VALUE);
158 if (res < 0)
159 return res;
160
161 if (poweroff_restart_client)
162 /*
163 * Another instance of the driver already took
164 * poweroff/restart duties.
165 */
166 dev_err(ec->dev, "poweroff_restart_client
already assigned\n");
167 else
168 poweroff_restart_client = client;
169
170 if (pm_power_off)
171 /* Another driver already registered a poweroff
handler. */
172 dev_err(ec->dev, "pm_power_off already
assigned\n");
173 else
174 pm_power_off = ntxec_poweroff;
175
176 res =
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
Re: [PATCH net-next 1/1] stmmac: intel: change all EHL/TGL to auto detect phy addr
On Sat, 16 Jan 2021 10:12:21 +0100 Jan Kiszka wrote: > On 06.11.20 10:43, Wong Vee Khee wrote: > > From: Voon Weifeng > > > > Set all EHL/TGL phy_addr to -1 so that the driver will automatically > > detect it at run-time by probing all the possible 32 addresses. > > > > Signed-off-by: Voon Weifeng > > Signed-off-by: Wong Vee Khee > > This fixes PHY detection on one of our EHL-based boards. Can this also > be applied to stable 5.10? Sure. Greg, we'd like to request a backport of the following commit to 5.10. commit bff6f1db91e330d7fba56f815cdbc412c75fe163 Author: Voon Weifeng Date: Fri Nov 6 17:43:41 2020 +0800 stmmac: intel: change all EHL/TGL to auto detect phy addr Set all EHL/TGL phy_addr to -1 so that the driver will automatically detect it at run-time by probing all the possible 32 addresses. Signed-off-by: Voon Weifeng Signed-off-by: Wong Vee Khee Link: https://lore.kernel.org/r/20201106094341.4241-1-vee.khee.w...@intel.com Signed-off-by: Jakub Kicinski It's relatively small, and Jan reports it makes his boards detect the PHY. The change went in via -next and into Linus's tree during the 5.11 merge window.
arch/arm64/include/asm/cmpxchg.h:88:1: sparse: sparse: cast truncates bits from constant value (ffff becomes ff)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0da0a8a0a0e1845f495431c3d8d733d2bbf9e9e5
commit: 4beba9486abd2f86d125271d6946f7c38ed0fe77 mm: Add PG_arch_2 page flag
date: 5 months ago
config: arm64-randconfig-s031-20210117 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-208-g46a52ca4-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4beba9486abd2f86d125271d6946f7c38ed0fe77
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 4beba9486abd2f86d125271d6946f7c38ed0fe77
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
mm/migrate.c: note: in included file (through
arch/arm64/include/asm/atomic.h, include/linux/atomic.h,
include/asm-generic/bitops/atomic.h, ...):
>> arch/arm64/include/asm/cmpxchg.h:88:1: sparse: sparse: cast truncates bits
>> from constant value ( becomes ff)
--
>> mm/memory.c:89:2: sparse: sparse: Unfortunate NUMA and NUMA Balancing
>> config, growing page-frame for last_cpupid.
mm/memory.c:829:17: sparse: sparse: context imbalance in 'copy_pte_range' -
different lock contexts for basic block
mm/memory.c:1450:16: sparse: sparse: context imbalance in '__get_locked_pte'
- different lock contexts for basic block
mm/memory.c:1499:9: sparse: sparse: context imbalance in 'insert_page' -
different lock contexts for basic block
mm/memory.c:2001:17: sparse: sparse: context imbalance in 'remap_pte_range'
- different lock contexts for basic block
mm/memory.c:2242:17: sparse: sparse: context imbalance in
'apply_to_pte_range' - unexpected unlock
mm/memory.c:2491:17: sparse: sparse: context imbalance in 'wp_page_copy' -
unexpected unlock
mm/memory.c: note: in included file (through
arch/arm64/include/asm/atomic.h, include/linux/atomic.h,
include/asm-generic/bitops/atomic.h, ...):
>> arch/arm64/include/asm/cmpxchg.h:88:1: sparse: sparse: cast truncates bits
>> from constant value ( becomes ff)
>> arch/arm64/include/asm/cmpxchg.h:88:1: sparse: sparse: cast truncates bits
>> from constant value ( becomes ff)
mm/memory.c:2835:17: sparse: sparse: context imbalance in 'wp_pfn_shared' -
unexpected unlock
>> arch/arm64/include/asm/cmpxchg.h:88:1: sparse: sparse: cast truncates bits
>> from constant value ( becomes ff)
>> arch/arm64/include/asm/cmpxchg.h:88:1: sparse: sparse: cast truncates bits
>> from constant value ( becomes ff)
>> arch/arm64/include/asm/cmpxchg.h:88:1: sparse: sparse: cast truncates bits
>> from constant value ( becomes ff)
mm/memory.c:2898:19: sparse: sparse: context imbalance in 'do_wp_page' -
different lock contexts for basic block
mm/memory.c:3495:19: sparse: sparse: context imbalance in
'pte_alloc_one_map' - different lock contexts for basic block
mm/memory.c:3721:17: sparse: sparse: context imbalance in 'finish_fault' -
unexpected unlock
mm/memory.c:3830:9: sparse: sparse: context imbalance in 'do_fault_around' -
unexpected unlock
mm/memory.c:4549:12: sparse: sparse: context imbalance in '__follow_pte_pmd'
- different lock contexts for basic block
mm/memory.c:4635:16: sparse: sparse: context imbalance in 'follow_pte_pmd' -
different lock contexts for basic block
vim +88 arch/arm64/include/asm/cmpxchg.h
10b663aef1c24794 Catalin Marinas 2012-03-05 84
305d454aaa292be3 Will Deacon 2015-10-08 85 __XCHG_GEN()
305d454aaa292be3 Will Deacon 2015-10-08 86 __XCHG_GEN(_acq)
305d454aaa292be3 Will Deacon 2015-10-08 87 __XCHG_GEN(_rel)
305d454aaa292be3 Will Deacon 2015-10-08 @88 __XCHG_GEN(_mb)
305d454aaa292be3 Will Deacon 2015-10-08 89
:: The code at line 88 was first introduced by commit
:: 305d454aaa292be3a09a9d674e6c35f5b4249a13 arm64: atomics: implement
native {relaxed, acquire, release} atomics
:: TO: Will Deacon
:: CC: Catalin Marinas
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
drivers/dma/ppc4xx/adma.c:688:38: sparse: sparse: incorrect type in argument 2 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0da0a8a0a0e1845f495431c3d8d733d2bbf9e9e5 commit: 894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e powerpc: inline iomap accessors date: 6 weeks ago config: powerpc-randconfig-s031-20210117 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-208-g46a52ca4-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" drivers/dma/ppc4xx/adma.c:73:1: sparse: sparse: symbol 'ppc440spe_adma_chan_list' was not declared. Should it be static? drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:543:35: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] sg1l @@ got restricted __le32 [usertype] @@ drivers/dma/ppc4xx/adma.c:543:35: sparse: expected unsigned int [usertype] sg1l
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
Re: [PATCH v4 2/2] media: dt-bindings: media: i2c: Add IMX300 CMOS sensor binding
Hi AngeloGioacchino,
On Wed, Jan 13, 2021 at 07:29:34PM +0100, AngeloGioacchino Del Regno wrote:
> Add YAML device tree binding for IMX300 CMOS image sensor, and
> the relevant MAINTAINERS entries.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> .../bindings/media/i2c/sony,imx300.yaml | 112 ++
> MAINTAINERS | 7 ++
> 2 files changed, 119 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
> b/Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
> new file mode 100644
> index ..4fa767feea80
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
> @@ -0,0 +1,112 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/sony,imx300.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Sony 1/2.3-Inch 25Mpixel Stacked CMOS Digital Image Sensor
> +
> +maintainers:
> + - AngeloGioacchino Del Regno
> +
> +description: |-
> + The Sony IMX300 is a 1/2.3-inch Stacked CMOS (Exmor-RS) digital image
> + sensor with a pixel size of 1.08um and an active array size of
> + 5948H x 4140V. It is programmable through I2C interface at address 0x10.
> + Image data is sent through MIPI CSI-2, which is configured as either 2 or
> + 4 data lanes.
> +
> +properties:
> + compatible:
> +const: sony,imx300
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +maxItems: 1
Please add assigned clock related properties; see
Documentation/driver-api/media/camera-sensor.rst .
> +
> + vdig-supply:
> +description:
> + Digital I/O voltage supply, 1.15-1.20 volts
> +
> + vana-supply:
> +description:
> + Analog voltage supply, 2.2 volts
> +
> + vddl-supply:
> +description:
> + Digital core voltage supply, 1.8 volts
> +
> + reset-gpios:
> +description: |-
> + Reference to the GPIO connected to the xclr pin, if any.
> + Must be released (set high) after all supplies are applied.
> +
> + # See ../video-interfaces.txt for more details
> + port:
> +type: object
> +properties:
> + endpoint:
> +type: object
> +
> +properties:
> + data-lanes:
> +description: |-
> + The driver only supports four-lane operation.
This can be removed as bindings describe hardware, not driver operation.
> +items:
> + - const: 0
> + - const: 1
> + - const: 2
> + - const: 3
Two lanes here, too?
> +
> + clock-noncontinuous: true
> +
> + link-frequencies:
> +$ref: /schemas/types.yaml#/definitions/uint64-array
> +description:
> + Allowed data bus frequencies. The driver currently needs
> + to switch between 78000 and 48000 Hz in order to
> + guarantee functionality of all modes.
You can omit this description, too.
> +
> +required:
> + - data-lanes
> + - link-frequencies
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - vana-supply
> + - vdig-supply
> + - vddl-supply
Are the regulators really required? I'm not quite sure about the
established practices; still the common case is that one or two of these
are hard-wired.
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +i2c0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +imx300: sensor@10 {
> +compatible = "sony,imx300";
> +reg = <0x10>;
> +clocks = <_xclk>;
> +vana-supply = <_vana>; /* 2.2v */
> +vdig-supply = <_vdig>; /* 1.2v */
> +vddl-supply = <_vddl>; /* 1.8v */
> +
> +port {
> +imx300_0: endpoint {
> +remote-endpoint = <_ep>;
> +data-lanes = <0 1 2 3>;
> +clock-noncontinuous;
> +link-frequencies = /bits/ 64 <78000 48000>;
> +};
> +};
> +};
> +};
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ad9abb42f852..5e0f08f48d48 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16633,6 +16633,13 @@ T: git git://linuxtv.org/media_tree.git
> F: Documentation/devicetree/bindings/media/i2c/imx290.txt
> F: drivers/media/i2c/imx290.c
>
> +SONY IMX300 SENSOR DRIVER
> +M: AngeloGioacchino Del Regno
> +L: linux-me...@vger.kernel.org
Please also add the git tree.
Ideally also the MAINTAINERS change comes with the first patch adding the
files, which should be the DT bindings. I.e. just reverse the order of the
patches.
> +S: Maintained
> +F: Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
> +F: drivers/media/i2c/imx300.c
> +
> SONY
Re: Missing param value! Expected 'rw=...value...'
On 1/16/21 3:07 PM, Heiner Kallweit wrote:
> Since 60b7cab23e5e ("proc_sysctl: fix oops caused by incorrect command
> parameters.")
> I'm getting the following warning: Missing param value! Expected
> 'rw=...value...'
> AFAIK param rw doesn't require a value. That's what my command line looks
> like:
> Command line: initrd=\intel-ucode.img initrd=\initramfs-linux.img
> root=/dev/sda2 rw
>
"rw" isn't a sysctl, so it looks like that added test is too early in
that function.
--
~Randy
You can't do anything without having to do something else first.
-- Belefant's Law
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
drivers/dma/ppc4xx/adma.c:4094:14: sparse: sparse: incorrect type in assignment (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0da0a8a0a0e1845f495431c3d8d733d2bbf9e9e5 commit: 68f35add4ba4c850a33878633e10c02d7ba32d84 dmaengine: ppc4xx: make ppc440spe_adma_chan_list static date: 3 months ago config: powerpc-randconfig-s031-20210117 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-208-g46a52ca4-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68f35add4ba4c850a33878633e10c02d7ba32d84 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 68f35add4ba4c850a33878633e10c02d7ba32d84 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" drivers/dma/ppc4xx/adma.c:1159:38: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void [noderef] __iomem * @@ got unsigned int * @@ drivers/dma/ppc4xx/adma.c:1159:38: sparse: expected void [noderef] __iomem * drivers/dma/ppc4xx/adma.c:1159:38: sparse: got unsigned int * drivers/dma/ppc4xx/adma.c:911:25: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct dma_regs *dma_reg @@ got struct dma_regs [noderef] __iomem *dma_reg @@ drivers/dma/ppc4xx/adma.c:911:25: sparse: expected struct dma_regs *dma_reg drivers/dma/ppc4xx/adma.c:911:25: sparse: got struct dma_regs [noderef] __iomem *dma_reg drivers/dma/ppc4xx/adma.c:912:40: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const [noderef] __iomem * @@ got unsigned int * @@ drivers/dma/ppc4xx/adma.c:912:40: sparse: expected void const [noderef] __iomem * drivers/dma/ppc4xx/adma.c:912:40: sparse: got unsigned int * drivers/dma/ppc4xx/adma.c:929:37: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:929:37: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:929:37: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:929:37: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:929:37: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:929:37: sparse: sparse: cast to restricted __le32 drivers/dma/ppc4xx/adma.c:974:32: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const [noderef] __iomem * @@ got unsigned int * @@ drivers/dma/ppc4xx/adma.c:974:32: sparse: expected void const [noderef] __iomem * drivers/dma/ppc4xx/adma.c:974:32: sparse: got unsigned int * drivers/dma/ppc4xx/adma.c:979:40: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void [noderef] __iomem * @@ got unsigned int * @@ drivers/dma/ppc4xx/adma.c:979:40: sparse: expected void [noderef] __iomem * drivers/dma/ppc4xx/adma.c:979:40: sparse: got unsigned int * drivers/dma/ppc4xx/adma.c:984:25: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct xor_regs *xor_reg @@ got struct xor_regs [noderef] __iomem *xor_reg @@ drivers/dma/ppc4xx/adma.c:984:25: sparse: expected struct xor_regs *xor_reg drivers/dma/ppc4xx/adma.c:984:25: sparse: got struct xor_regs [noderef] __iomem *xor_reg drivers/dma/ppc4xx/adma.c:985:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const [noderef] __iomem * @@ got unsigned int * @@ drivers/dma/ppc4xx/adma.c:985:34: sparse: expected void const [noderef] __iomem * drivers/dma/ppc4xx/adma.c:985:34: sparse: got unsigned int * drivers/dma/ppc4xx/adma.c:986:34: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void [noderef] __iomem * @@ got unsigned int * @@ drivers/dma/ppc4xx/adma.c:986:34: sparse: expected void [noderef] __iomem * drivers/dma/ppc4xx/adma.c:986:34: sparse: got unsigned int * drivers/dma/ppc4xx/adma.c:993:55: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const [noderef] __iomem * @@ got unsigned int * @@ drivers/dma/ppc4xx/adma.c:993:55: sparse: expected void const [noderef] __iomem * drivers/dma/ppc4xx/adma.c:993:55: sparse: got unsigned int * drivers/dma/ppc4xx/adma.c:995:51: sparse: sparse: incorrect type in argument 2 (different
Re: [PATCH 2/3] media: videodev2.h: clarify v4l2_pix_format_mplane.sizeimage docs when to set to zero
Hi Helen,
Thanks for the patch.
On Thu, Jan 14, 2021 at 03:01:48PM -0300, Helen Koike wrote:
> sizeimage field should be set to zero for unused planes, even when
> v4l2_pix_format_mplane.num_planes is smaller then the index of planes.
>
> Signed-off-by: Helen Koike
>
> ---
>
> I caught this with v4l2-compliance, which throws an error if we dirty
> planes, even if invalid, so I would like to make it clear in the docs.
Would it be possible to do this in the framework instead?
> ---
> include/uapi/linux/videodev2.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 79dbde3bcf8d..d9b7c9177605 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -2227,6 +2227,7 @@ struct v4l2_mpeg_vbi_fmt_ivtv {
> * struct v4l2_plane_pix_format - additional, per-plane format definition
> * @sizeimage: maximum size in bytes required for data, for
> which
> * this plane will be used
> + * Drivers should be set it zero for unused planes.
> * @bytesperline:distance in bytes between the leftmost pixels in two
> * adjacent lines
> */
--
Kind regards,
Sakari Ailus
Re: [PATCH 3/3] media: videobuf2-v4l2: remove redundant error test
On Thu, Jan 14, 2021 at 03:01:49PM -0300, Helen Koike wrote: > request_fd is validated under media_request_get_by_fd() just below this > check. Thus remove it. > > Suggested-by: Tomasz Figa > Signed-off-by: Helen Koike Reviewed-by: Sakari Ailus -- Sakari Ailus
Re: Old platforms never die, was Re: Old platforms: bring out your dead
On Sat, 16 Jan 2021, Rob Landley wrote: > Speaking of which, my qemu m68k system has failed to boot ever since commit: > > commit f93bfeb55255bddaa16597e187a99ae6131b964a > Author: Finn Thain > Date: Sun Jun 28 14:23:12 2020 +1000 > > macintosh/via-macii: Poll the device most likely to respond > Yes, that patch series broke your emulator by fixing kernel bugs. Please refer to this message for some background and some solutions-- https://lore.kernel.org/linux-m68k/alpine.LNX.2.23.453.2008100844450.8@nippy.intranet/
Re: [PATCH] media: i2c: imx219: Rewrite tables and implement more modes
Hi AngeloGioacchino, On Fri, Jan 15, 2021 at 07:52:33PM +0100, AngeloGioacchino Del Regno wrote: > Enhance the feature set for this camera sensor by in rewriting the > entire tables (as they were just meaningless magic register writes) > in a similar form, but giving some names to the actual registers > we write to, separating common sequences and reusing them for the > various configuration variations that are now supported, hence > implementing support for: > - 8MHz XCLK, as used by (and not only) some Sony Xperia smartphones > - 4-Lane Mode in both 24MHz and 8MHz XCLK configuration > - High Frame Rate output modes support on 4-Lane operation, up to > 1000FPS (also on 2-Lane but, being bandwidth-constrained, the > maximum achievable frame rate gets lower there) That's a lot of changes for a single patch. Could you split each of these into separate patches, please? > - Frame Bank Control Groups, in order to support a fast output > resolution switch, without resetting the entire sensor during > a streaming session: here the new mode gets configured on the > secondary (or primary, read: "the other") bank and the sensor > will be able to switch to it at the end of the "current frame". You basically need to stop streaming to reconfigure the sensor; V4L2 currently does not doing this on the fly. There's no need to rest the sensor though, and I don't think the driver did that before either. > > Please note: an unknown register write sequence was found in both > the Raspberry Pi and a Sony Xperia smartphone i2c dump, but this > seems to do literally nothing, as the sensor seems to work > in the exact same way when sending and when not sending this > write sequence, which is undocumented in the datasheet. > > Both the authentication and magic sequences were left in the > driver with a big comment explaining what's going on so that, > in the event that someone discovers the meaning of it (or > Sony distributes documentation for that), it'll be pretty > straightforward to insert them when needed. > > All the modes that got implemented in this commit have been tested > with all combinations of 24/8MHz, 2/4Lane, all resolutions, on the > following smartphones: > - Sony Xperia XA2 (SDM630) > - Sony Xperia XA2 Ultra (SDM630) > > Signed-off-by: AngeloGioacchino Del Regno > > --- > drivers/media/i2c/imx219.c | 884 - > 1 file changed, 580 insertions(+), 304 deletions(-) > > diff --git a/drivers/media/i2c/imx219.c b/drivers/media/i2c/imx219.c > index 92a8d52776b8..360730d5b81c 100644 > --- a/drivers/media/i2c/imx219.c > +++ b/drivers/media/i2c/imx219.c > @@ -12,6 +12,10 @@ > * Flip handling taken from the Sony IMX319 driver. > * Copyright (C) 2018 Intel Corporation > * > + * 8MHz, 4-Lane, High Frame Rate modes, Frame Bank Control groups, > + * fast mode switching > + * Copyright (C) 2020, AngeloGioacchino Del Regno > + * > */ > > #include > @@ -35,24 +39,93 @@ > #define IMX219_MODE_STANDBY 0x00 > #define IMX219_MODE_STREAMING0x01 > > +#define IMX219_REG_SW_RESET 0x0103 > + > +/* Output Set-up */ > +#define IMX219_REG_CSI_LANE_MODE 0x0114 > +#define IMX219_CSI_LANE_MODE_2LANE BIT(0) > +#define IMX219_CSI_LANE_MODE_4LANE (BIT(0) | BIT(1)) > + > +#define IMX219_REG_DPHY_CTRL 0x0128 > +#define IMX219_DPHY_CTRL_AUTO0 > +#define IMX219_DPHY_CTRL_MANUAL 1 > + > +/* Use as 16-bits reg */ > +#define IMX219_REG_EXCK_FREQ_MHZ 0x012A > +#define IMX219_EXCK_FREQ_MHZ_MIN 6 > +#define IMX219_EXCK_FREQ_MHZ_MAX 27 > + > +/* Frame Bank Control Registers*/ > +#define IMX219_REG_FRAME_BANK_CTRL 0x0150 > +#define IMX219_FRAME_BANK_EN_SHIFT BIT(0) > +#define IMX219_FRAME_BANK_STAT_SHIFT BIT(1) > + > +#define IMX219_REG_FRAME_COUNT 0x0151 > +#define IMX219_REG_FRAME_FAST_TRACKING 0x0152 > + > +/* Frame Bank 0: Group "A" - 1: Group "B" */ > +#define IMX219_REG_FRAME_BANK_BASE(x)((0x100 * x) + 0x154) > +#define IMX219_REG_ANALOG_GAIN 0x03 > +#define IMX219_REG_DIGITAL_GAIN 0x04 > +#define IMX219_REG_EXPOSURE 0x06 > +#define IMX219_REG_FRAME_LEN_LINES 0x0c > +#define IMX219_REG_LINE_LEN_PCK 0x0e > +#define IMX219_REG_X_ADDR_START 0x10 > +#define IMX219_REG_X_ADDR_END0x12 > +#define IMX219_REG_Y_ADDR_START 0x14 > +#define IMX219_REG_Y_ADDR_END0x16 > +#define IMX219_REG_X_OUTPUT_SIZE 0x18 > +#define IMX219_REG_Y_OUTPUT_SIZE 0x1a > +#define IMX219_REG_X_ODD_INC 0x1c > +#define IMX219_REG_Y_ODD_INC 0x1d > +#define IMX219_REG_ORIENTATION 0x1e > +#define IMX219_REG_BINNING_MODE_H0x20 > +#define IMX219_REG_BINNING_MODE_V0x21 > +#define IMX219_REG_BINNING_CAL_H 0x22 > +#define IMX219_REG_BINNING_CAL_V 0x23 > +#define IMX219_REG_CSI_DATA_FORMAT_HI0x38 > +#define
Missing param value! Expected 'rw=...value...'
Since 60b7cab23e5e ("proc_sysctl: fix oops caused by incorrect command
parameters.")
I'm getting the following warning: Missing param value! Expected
'rw=...value...'
AFAIK param rw doesn't require a value. That's what my command line looks like:
Command line: initrd=\intel-ucode.img initrd=\initramfs-linux.img
root=/dev/sda2 rw
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
RE: [PATCH] x86/hyperv: Initialize clockevents after LAPIC is initialized
From: Dexuan Cui Sent: Saturday, January 16, 2021 2:32 PM
>
> With commit 4df4cb9e99f8, the Hyper-V direct-mode STIMER is actually
> initialized before LAPIC is initialized: see
>
> apic_intr_mode_init()
>
> x86_platform.apic_post_init()
> hyperv_init()
> hv_stimer_alloc()
>
> apic_bsp_setup()
> setup_local_APIC()
>
> setup_local_APIC() temporarily disables LAPIC, initializes it and
> re-eanble it. The direct-mode STIMER depends on LAPIC, and when it's
> registered, it can be programmed immediately and the timer can fire
> very soon:
>
> hv_stimer_init
> clockevents_config_and_register
> clockevents_register_device
> tick_check_new_device
> tick_setup_device
> tick_setup_periodic(), tick_setup_oneshot()
> clockevents_program_event
>
> When the timer fires in the hypervisor, if the LAPIC is in the
> disabled state, new versions of Hyper-V ignore the event and don't inject
> the timer interrupt into the VM, and hence the VM hangs when it boots.
>
> Note: when the VM starts/reboots, the LAPIC is pre-enabled by the
> firmware, so the window of LAPIC being temporarily disabled is pretty
> small, and the issue can only happen once out of 100~200 reboots for
> a 40-vCPU VM on one dev host, and on another host the issue doesn't
> reproduce after 2000 reboots.
>
> The issue is more noticeable for kdump/kexec, because the LAPIC is
> disabled by the first kernel, and stays disabled until the kdump/kexec
> kernel enables it. This is especially an issue to a Generation-2 VM
> (for which Hyper-V doesn't emulate the PIT timer) when CONFIG_HZ=1000
> (rather than CONFIG_HZ=250) is used.
>
> Fix the issue by moving hv_stimer_alloc() to a later place where the
> LAPIC timer is initialized.
>
> Fixes: 4df4cb9e99f8 ("x86/hyperv: Initialize clockevents earlier in CPU
> onlining")
> Signed-off-by: Dexuan Cui
> ---
> arch/x86/hyperv/hv_init.c | 29 ++---
> 1 file changed, 26 insertions(+), 3 deletions(-)
>
Reviewed-by: Michael Kelley
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
[PATCH] x86/hyperv: Initialize clockevents after LAPIC is initialized
With commit 4df4cb9e99f8, the Hyper-V direct-mode STIMER is actually
initialized before LAPIC is initialized: see
apic_intr_mode_init()
x86_platform.apic_post_init()
hyperv_init()
hv_stimer_alloc()
apic_bsp_setup()
setup_local_APIC()
setup_local_APIC() temporarily disables LAPIC, initializes it and
re-eanble it. The direct-mode STIMER depends on LAPIC, and when it's
registered, it can be programmed immediately and the timer can fire
very soon:
hv_stimer_init
clockevents_config_and_register
clockevents_register_device
tick_check_new_device
tick_setup_device
tick_setup_periodic(), tick_setup_oneshot()
clockevents_program_event
When the timer fires in the hypervisor, if the LAPIC is in the
disabled state, new versions of Hyper-V ignore the event and don't inject
the timer interrupt into the VM, and hence the VM hangs when it boots.
Note: when the VM starts/reboots, the LAPIC is pre-enabled by the
firmware, so the window of LAPIC being temporarily disabled is pretty
small, and the issue can only happen once out of 100~200 reboots for
a 40-vCPU VM on one dev host, and on another host the issue doesn't
reproduce after 2000 reboots.
The issue is more noticeable for kdump/kexec, because the LAPIC is
disabled by the first kernel, and stays disabled until the kdump/kexec
kernel enables it. This is especially an issue to a Generation-2 VM
(for which Hyper-V doesn't emulate the PIT timer) when CONFIG_HZ=1000
(rather than CONFIG_HZ=250) is used.
Fix the issue by moving hv_stimer_alloc() to a later place where the
LAPIC timer is initialized.
Fixes: 4df4cb9e99f8 ("x86/hyperv: Initialize clockevents earlier in CPU
onlining")
Signed-off-by: Dexuan Cui
---
arch/x86/hyperv/hv_init.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 4638a52d8eae..6375967a8244 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -315,6 +315,25 @@ static struct syscore_ops hv_syscore_ops = {
.resume = hv_resume,
};
+static void (* __initdata old_setup_percpu_clockev)(void);
+
+static void __init hv_stimer_setup_percpu_clockev(void)
+{
+ /*
+* Ignore any errors in setting up stimer clockevents
+* as we can run with the LAPIC timer as a fallback.
+*/
+ (void)hv_stimer_alloc();
+
+ /*
+* Still register the LAPIC timer, because the direct-mode STIMER is
+* not supported by old versions of Hyper-V. This also allows users
+* to switch to LAPIC timer via /sys, if they want to.
+*/
+ if (old_setup_percpu_clockev)
+ old_setup_percpu_clockev();
+}
+
/*
* This function is to be invoked early in the boot sequence after the
* hypervisor has been detected.
@@ -393,10 +412,14 @@ void __init hyperv_init(void)
wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
/*
-* Ignore any errors in setting up stimer clockevents
-* as we can run with the LAPIC timer as a fallback.
+* hyperv_init() is called before LAPIC is initialized: see
+* apic_intr_mode_init() -> x86_platform.apic_post_init() and
+* apic_bsp_setup() -> setup_local_APIC(). The direct-mode STIMER
+* depends on LAPIC, so hv_stimer_alloc() should be called from
+* x86_init.timers.setup_percpu_clockev.
*/
- (void)hv_stimer_alloc();
+ old_setup_percpu_clockev = x86_init.timers.setup_percpu_clockev;
+ x86_init.timers.setup_percpu_clockev = hv_stimer_setup_percpu_clockev;
hv_apic_init();
--
2.19.1
Re: [PATCH v5 0/3] rtc: s5m: driver improvements
On Thu, 14 Jan 2021 11:22:16 +0100, Bartosz Golaszewski wrote: > This is a set of improvements for the rtc-s5m driver. The first patch > is new in v4: I noticed the I2C regmap is not selected by this driver's > Kconfig. Two subsequent patches were already submitted separately. > > v1 -> v2: > - remove the remove() callback > > [...] Applied, thanks! [1/3] rtc: s5m: select REGMAP_I2C commit: 1f0cbda3b452b520c5f3794f8f0e410e8bc7386a [2/3] rtc: s5m: use devm_i2c_new_dummy_device() commit: 7db7ad0817fe7d3c6fcbd9402deb7509b2851f06 [3/3] rtc: s5m: check the return value of s5m8767_rtc_init_reg() commit: 3be95d277484117f248b2f7e8cb8d14cb38dbb04 Best regards, -- Alexandre Belloni
[PATCH] mm: thp: fix MADV_REMOVE deadlock on shmem THP
Sergey reported deadlock between kswapd correctly doing its usual
lock_page(page) followed by down_read(page->mapping->i_mmap_rwsem),
and madvise(MADV_REMOVE) on an madvise(MADV_HUGEPAGE) area doing
down_write(page->mapping->i_mmap_rwsem) followed by lock_page(page).
This happened when shmem_fallocate(punch hole)'s unmap_mapping_range()
reaches zap_pmd_range()'s call to __split_huge_pmd(). The same deadlock
could occur when partially truncating a mapped huge tmpfs file, or using
fallocate(FALLOC_FL_PUNCH_HOLE) on it.
__split_huge_pmd()'s page lock was added in 5.8, to make sure that any
concurrent use of reuse_swap_page() (holding page lock) could not catch
the anon THP's mapcounts and swapcounts while they were being split.
Fortunately, reuse_swap_page() is never applied to a shmem or file THP
(not even by khugepaged, which checks PageSwapCache before calling),
and anonymous THPs are never created in shmem or file areas: so that
__split_huge_pmd()'s page lock can only be necessary for anonymous THPs,
on which there is no risk of deadlock with i_mmap_rwsem.
Reported-by: Sergey Senozhatsky
Fixes: c444eb564fb1 ("mm: thp: make the THP mapcount atomic against
__split_huge_pmd_locked()")
Signed-off-by: Hugh Dickins
Reviewed-by: Andrea Arcangeli
Cc: sta...@vger.kernel.org
---
The status of reuse_swap_page(), and its use on THPs, is currently under
discussion, and may need to be changed: but this patch is a simple fix
to the reported deadlock, which can go in now, and be easily backported
to whichever stable and longterm releases took in 5.8's c444eb564fb1.
mm/huge_memory.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
--- 5.11-rc3/mm/huge_memory.c 2020-12-27 20:39:37.667932292 -0800
+++ linux/mm/huge_memory.c 2021-01-16 08:02:08.265551393 -0800
@@ -2202,7 +2202,7 @@ void __split_huge_pmd(struct vm_area_str
{
spinlock_t *ptl;
struct mmu_notifier_range range;
- bool was_locked = false;
+ bool do_unlock_page = false;
pmd_t _pmd;
mmu_notifier_range_init(, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
@@ -2218,7 +2218,6 @@ void __split_huge_pmd(struct vm_area_str
VM_BUG_ON(freeze && !page);
if (page) {
VM_WARN_ON_ONCE(!PageLocked(page));
- was_locked = true;
if (page != pmd_page(*pmd))
goto out;
}
@@ -2227,19 +2226,29 @@ repeat:
if (pmd_trans_huge(*pmd)) {
if (!page) {
page = pmd_page(*pmd);
- if (unlikely(!trylock_page(page))) {
- get_page(page);
- _pmd = *pmd;
- spin_unlock(ptl);
- lock_page(page);
- spin_lock(ptl);
- if (unlikely(!pmd_same(*pmd, _pmd))) {
- unlock_page(page);
+ /*
+* An anonymous page must be locked, to ensure that a
+* concurrent reuse_swap_page() sees stable mapcount;
+* but reuse_swap_page() is not used on shmem or file,
+* and page lock must not be taken when zap_pmd_range()
+* calls __split_huge_pmd() while i_mmap_lock is held.
+*/
+ if (PageAnon(page)) {
+ if (unlikely(!trylock_page(page))) {
+ get_page(page);
+ _pmd = *pmd;
+ spin_unlock(ptl);
+ lock_page(page);
+ spin_lock(ptl);
+ if (unlikely(!pmd_same(*pmd, _pmd))) {
+ unlock_page(page);
+ put_page(page);
+ page = NULL;
+ goto repeat;
+ }
put_page(page);
- page = NULL;
- goto repeat;
}
- put_page(page);
+ do_unlock_page = true;
}
}
if (PageMlocked(page))
@@ -2249,7 +2258,7 @@ repeat:
__split_huge_pmd_locked(vma, pmd, range.start, freeze);
out:
spin_unlock(ptl);
- if (!was_locked && page)
+ if (do_unlock_page)
unlock_page(page);
/*
* No need to double call mmu_notifier->invalidate_range() callback.
[PATCH 1/2] [v2] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses
Hashed addresses are useless in hexdumps unless you're comparing
with other hashed addresses, which is unlikely. However, there's
no need to break existing code, so introduce a new prefix type
that prints unhashed addresses.
Signed-off-by: Timur Tabi
Reviewed-by: Petr Mladek
Cc: Roman Fietze
---
fs/seq_file.c | 3 +++
include/linux/printk.h | 8 +---
lib/hexdump.c | 9 +++--
lib/seq_buf.c | 9 +++--
4 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 03a369ccd28c..b5b49a855894 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -864,6 +864,9 @@ void seq_hex_dump(struct seq_file *m, const char
*prefix_str, int prefix_type,
remaining -= rowsize;
switch (prefix_type) {
+ case DUMP_PREFIX_UNHASHED:
+ seq_printf(m, "%s%px: ", prefix_str, ptr + i);
+ break;
case DUMP_PREFIX_ADDRESS:
seq_printf(m, "%s%p: ", prefix_str, ptr + i);
break;
diff --git a/include/linux/printk.h b/include/linux/printk.h
index fe7eb2351610..d3c08095a9a3 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -567,7 +567,8 @@ extern const struct file_operations kmsg_fops;
enum {
DUMP_PREFIX_NONE,
DUMP_PREFIX_ADDRESS,
- DUMP_PREFIX_OFFSET
+ DUMP_PREFIX_OFFSET,
+ DUMP_PREFIX_UNHASHED,
};
extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
int groupsize, char *linebuf, size_t linebuflen,
@@ -612,8 +613,9 @@ static inline void print_hex_dump_debug(const char
*prefix_str, int prefix_type,
* print_hex_dump_bytes - shorthand form of print_hex_dump() with default
params
* @prefix_str: string to prefix each line with;
* caller supplies trailing spaces for alignment if desired
- * @prefix_type: controls whether prefix of an offset, address, or none
- * is printed (%DUMP_PREFIX_OFFSET, %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_NONE)
+ * @prefix_type: controls whether prefix of an offset, hashed address,
+ * unhashed address, or none is printed (%DUMP_PREFIX_OFFSET,
+ * %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_UNHASHED, %DUMP_PREFIX_NONE)
* @buf: data blob to dump
* @len: number of bytes in the @buf
*
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 9301578f98e8..b5acfc4168a8 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -211,8 +211,9 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
* @level: kernel log level (e.g. KERN_DEBUG)
* @prefix_str: string to prefix each line with;
* caller supplies trailing spaces for alignment if desired
- * @prefix_type: controls whether prefix of an offset, address, or none
- * is printed (%DUMP_PREFIX_OFFSET, %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_NONE)
+ * @prefix_type: controls whether prefix of an offset, hashed address,
+ * unhashed address, or none is printed (%DUMP_PREFIX_OFFSET,
+ * %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_UNHASHED, %DUMP_PREFIX_NONE)
* @rowsize: number of bytes to print per line; must be 16 or 32
* @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
* @buf: data blob to dump
@@ -256,6 +257,10 @@ void print_hex_dump(const char *level, const char
*prefix_str, int prefix_type,
linebuf, sizeof(linebuf), ascii);
switch (prefix_type) {
+ case DUMP_PREFIX_UNHASHED:
+ printk("%s%s%px: %s\n",
+ level, prefix_str, ptr + i, linebuf);
+ break;
case DUMP_PREFIX_ADDRESS:
printk("%s%s%p: %s\n",
level, prefix_str, ptr + i, linebuf);
diff --git a/lib/seq_buf.c b/lib/seq_buf.c
index 707453f5d58e..017c4d7e93f1 100644
--- a/lib/seq_buf.c
+++ b/lib/seq_buf.c
@@ -335,8 +335,9 @@ int seq_buf_to_user(struct seq_buf *s, char __user *ubuf,
int cnt)
* @s: seq_buf descriptor
* @prefix_str: string to prefix each line with;
* caller supplies trailing spaces for alignment if desired
- * @prefix_type: controls whether prefix of an offset, address, or none
- * is printed (%DUMP_PREFIX_OFFSET, %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_NONE)
+ * @prefix_type: controls whether prefix of an offset, hashed address,
+ * unhashed address, or none is printed (%DUMP_PREFIX_OFFSET,
+ * %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_UNHASHED, %DUMP_PREFIX_NONE)
* @rowsize: number of bytes to print per line; must be 16 or 32
* @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
* @buf: data blob to dump
@@ -374,6 +375,10 @@ int seq_buf_hex_dump(struct seq_buf *s, const char
*prefix_str, int prefix_type,
linebuf, sizeof(linebuf), ascii);
switch (prefix_type) {
+ case DUMP_PREFIX_UNHASHED:
+ ret = seq_buf_printf(s, "%s%px: %s\n",
+
[PATCH 2/2] mm/page_poison: use unhashed address in hexdump for check_poison_mem()
Now that print_hex_dump() is capable of printing unhashed addresses,
use that feature in the code that reports memory errors. Hashed
addresses don't tell you where the corrupted page actually is.
Signed-off-by: Timur Tabi
---
mm/page_poison.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_poison.c b/mm/page_poison.c
index 65cdf844c8ad..4902f3261ee4 100644
--- a/mm/page_poison.c
+++ b/mm/page_poison.c
@@ -67,7 +67,7 @@ static void check_poison_mem(unsigned char *mem, size_t bytes)
else
pr_err("pagealloc: memory corruption\n");
- print_hex_dump(KERN_ERR, "", DUMP_PREFIX_ADDRESS, 16, 1, start,
+ print_hex_dump(KERN_ERR, "", DUMP_PREFIX_UNHASHED, 16, 1, start,
end - start + 1, 1);
dump_stack();
}
--
2.25.1
[PATCH 0/2] introduce DUMP_PREFIX_UNHASHED for hex dumps
First patch updates print_hex_dump() and related functions to allow callers to print hex dumps with unhashed addresses. It adds a new prefix type, so existing code is unchanged. Second patch changes a page poising function to use the new address type. This is just an example of a change. If it's wrong, it doesn't need to be applied. IMHO, hashed addresses make very little sense for hex dumps, which print addresses in 16- or 32-byte increments. Typical use-case is to correlate an addresses in between one of these increments with some other address, but that can't be done if the addresses are hashed. I expect most developers to want to replace their usage of DUMP_PREFIX_ADDRESS with DUMP_PREFIX_UNHASHED, now that they have the opportunity. Timur Tabi (2): [v2] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses mm/page_poison: use unhashed address in hexdump for check_poison_mem() fs/seq_file.c | 3 +++ include/linux/printk.h | 8 +--- lib/hexdump.c | 9 +++-- lib/seq_buf.c | 9 +++-- mm/page_poison.c | 2 +- 5 files changed, 23 insertions(+), 8 deletions(-) -- 2.25.1
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
[PATCH 2/2] clk: vc5: Add support for optional load capacitance
There are two registers which can set the load capacitance for
XTAL1 and XTAL2. These are optional registers when using an
external crystal. Parse the device tree and set the
corresponding registers accordingly.
Signed-off-by: Adam Ford
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 43db67337bc0..224118ca08fd 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -759,6 +759,72 @@ static int vc5_update_power(struct device_node *np_output,
return 0;
}
+static int vc5_map_cap_value(u32 femtofarads)
+{
+ int mapped_value;
+
+ /*
+* The datasheet explicitly states 9000 - 25000 with 0.5pF
+* steps, but the Programmer's guide shows the steps are 0.430pF.
+* After getting feedback from Renesas, the .5pF steps were the
+* goal, but 430nF was the actual values.
+* Because of this, the actual range goes to 22760 instead of 25000
+*/
+ if (femtofarads < 9000 || femtofarads > 22760)
+ return -EINVAL;
+
+ /* The lowest target we can hit is 9430, so exit if it's less */
+ if (femtofarads < 9430)
+ return 0;
+
+ /*
+* The Programmer's guide shows XTAL[5:0] but in reality,
+* XTAL[0] and XTAL[1] are both LSB which makes the math
+* strange. With clarfication from Renesas, setting the
+* values should be simpler by ignoring XTAL[0]
+*/
+
+ mapped_value = DIV_ROUND_CLOSEST(femtofarads - 9430, 430);
+
+ /*
+* Since the calculation ignores XTAL[0], there is one
+* special case where mapped_value = 32. In reality, this means
+* the real mapped value should be 11b. In other clases,
+* the mapped_value needs to be shifted 1 to the left.
+*/
+
+ if (mapped_value > 31)
+ mapped_value = 0x3f;
+ else
+ mapped_value <<= 1;
+
+ return mapped_value;
+}
+static int vc5_update_cap_load(struct device_node *node, struct
vc5_driver_data *vc5)
+{
+ u32 value;
+ int mapped_value;
+
+ if (!of_property_read_u32(node, "idt,xtal-load-femtofarads", )) {
+ mapped_value = vc5_map_cap_value(value);
+ if (mapped_value < 0)
+ return mapped_value;
+
+ /*
+* According to Renesas, bits [1:0] of VC5_XTAL_X1_LOAD_CAP
+* and VC5_XTAL_X2_LOAD_CAP should always be 01b.
+* Since the mapped_value is really the high 6 bits of 8,
+* shift the value 2 places and or in the 0x01;
+*/
+
+ mapped_value = (mapped_value << 2) | 0x01;
+ regmap_write(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, mapped_value);
+ regmap_write(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, mapped_value);
+ }
+
+ return 0;
+}
+
static int vc5_update_slew(struct device_node *np_output,
struct vc5_out_data *clk_out)
{
@@ -884,6 +950,13 @@ static int vc5_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return -EINVAL;
}
+ /* Configure Optional Loading Capacitance for external XTAL */
+ if (!(vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)) {
+ ret = vc5_update_cap_load(client->dev.of_node, vc5);
+ if (ret)
+ goto err_clk_register;
+ }
+
init.name = kasprintf(GFP_KERNEL, "%pOFn.mux", client->dev.of_node);
init.ops = _mux_ops;
init.flags = 0;
--
2.25.1
[PATCH 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property
There are two registers which can set the load capacitance for XTAL1 and XTAL2. These are optional registers when using an external crystal. Since XTAL1 and XTAL2 will set to the same value, update the binding to support a single property called xtal-load-femtofarads. Signed-off-by: Adam Ford diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index 2ac1131fd922..c268debe5b8d 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -59,6 +59,12 @@ properties: minItems: 1 maxItems: 2 + idt,xtal-load-femtofarads: +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 9000 +maximum: 22760 +description: Optional load capacitor for XTAL1 and XTAL2 + patternProperties: "^OUT[1-4]$": type: object -- 2.25.1
Re: [PATCH 2/5] hugetlb: convert page_huge_active() to HP_Migratable flag
On 1/16/21 4:06 AM, Oscar Salvador wrote:
> On Sat, Jan 16, 2021 at 04:24:16AM +, Matthew Wilcox wrote:
>> and name these HPG_restore_reserve and HPG_migratable
>>
>> and generate the calls to hugetlb_set_page_flag etc from macros, eg:
>>
>> #define TESTHPAGEFLAG(uname, lname) \
>> static __always_inline bool HPage##uname(struct page *page) \
>> { return test_bit(HPG_##lname, >private); }
>> ...
>> #define HPAGEFLAG(uname, lname)
>> \
>> TESTHPAGEFLAG(uname, lname) \
>> SETHPAGEFLAG(uname, lname) \
>> CLEARHPAGEFLAG(uname, lname)
>>
>> HPAGEFLAG(RestoreReserve, restore_reserve)
>> HPAGEFLAG(Migratable, migratable)
>>
>> just to mirror page-flags.h more closely.
>
> That is on me.
> I thought that given the low number of flags, we coud get away with:
>
> hugetlb_{set,test,clear}_page_flag(page, flag)
>
> and call it from the code.
> But some of the flags need to be set/tested outside hugetlb code, so
> it indeed looks nicer and more consistent to follow page-flags.h convention.
>
> Sorry for the noise.
Thanks everyone!
I was unsure about the best way to go for this. Will send out a new version
in a few days using the page-flag style macros.
--
Mike Kravetz
Re: [PATCH v3 0/4] Remove one more platform_device_add_properties() call
On 16/01/2021 20:23, Andy Shevchenko wrote: > On Fri, Jan 15, 2021 at 11:52 AM Heikki Krogerus > wrote: >> Hi, >> >> I'm now clearing the dev_fwnode(dev)->secondary pointer in >> device_remove_software_node() as requested by Daniel and Andy. Thanks >> guys, it's much better now. I also took the liberty of including one >> more PCI ID patch where I add PCI ID for the Alder Lake-P variant. I >> hope that is OK. >> >> Andy, I dropped your Tested-by tag because of the change I made to the >> first patch. If you have time to retest these, I would much appreciate. > Since Greg already grabbed a v3 I will test it when it appears in linux-next. > It seems the grabbed one is the v2 one though actually
[PATCH] media: cx25821: Fix a bug when reallocating some dma memory
This function looks like a realloc.
However, if 'risc->cpu != NULL', the memory will be freed, but never
reallocated with the bigger 'size'.
Explicitly set 'risc->cpu' to NULL, so that the reallocation is
correctly performed a few lines below.
Fixes: 5ede94c70553 ("[media] cx25821: remove bogus btcx_risc dependency)
Signed-off-by: Christophe JAILLET
---
Completly speculative and untested.
---
drivers/media/pci/cx25821/cx25821-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx25821/cx25821-core.c
b/drivers/media/pci/cx25821/cx25821-core.c
index 6f8ffab8840f..22e47dd74df4 100644
--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -976,8 +976,10 @@ int cx25821_riscmem_alloc(struct pci_dev *pci,
__le32 *cpu;
dma_addr_t dma = 0;
- if (NULL != risc->cpu && risc->size < size)
+ if (NULL != risc->cpu && risc->size < size) {
pci_free_consistent(pci, risc->size, risc->cpu, risc->dma);
+ risc->cpu = NULL;
+ }
if (NULL == risc->cpu) {
cpu = pci_zalloc_consistent(pci, size, );
if (NULL == cpu)
--
2.27.0
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
[PATCH] power: supply: fix sbs-charger build, needs REGMAP_I2C
CHARGER_SBS should select REGMAP_I2C since it uses API(s) that are
provided by that Kconfig symbol.
Fixes these errors:
../drivers/power/supply/sbs-charger.c:149:21: error: variable ‘sbs_regmap’ has
initializer but incomplete type
static const struct regmap_config sbs_regmap = {
../drivers/power/supply/sbs-charger.c:150:3: error: ‘const struct
regmap_config’ has no member named ‘reg_bits’
.reg_bits = 8,
../drivers/power/supply/sbs-charger.c:155:23: error: ‘REGMAP_ENDIAN_LITTLE’
undeclared here (not in a function)
.val_format_endian = REGMAP_ENDIAN_LITTLE, /* since based on SMBus */
../drivers/power/supply/sbs-charger.c: In function ‘sbs_probe’:
../drivers/power/supply/sbs-charger.c:183:17: error: implicit declaration of
function ‘devm_regmap_init_i2c’; did you mean ‘devm_request_irq’?
[-Werror=implicit-function-declaration]
chip->regmap = devm_regmap_init_i2c(client, _regmap);
../drivers/power/supply/sbs-charger.c: At top level:
../drivers/power/supply/sbs-charger.c:149:35: error: storage size of
‘sbs_regmap’ isn’t known
static const struct regmap_config sbs_regmap = {
Fixes: feb583e37f8a ("power: supply: add sbs-charger driver")
Signed-off-by: Randy Dunlap
Cc: Sebastian Reichel
Cc: linux...@vger.kernel.org
Cc: Martin Mokrejs
Cc: Greg Kroah-Hartman
Cc: nicolassae...@gmail.com
Cc: Nicolas Saenz Julienne
Cc: Rafael J. Wysocki
---
Martin, do you want Reported-by: on this?
drivers/power/supply/Kconfig |1 +
1 file changed, 1 insertion(+)
--- linux-next-20210115.orig/drivers/power/supply/Kconfig
+++ linux-next-20210115/drivers/power/supply/Kconfig
@@ -229,6 +229,7 @@ config BATTERY_SBS
config CHARGER_SBS
tristate "SBS Compliant charger"
depends on I2C
+ select REGMAP_I2C
help
Say Y to include support for SBS compliant battery chargers.
Re: [PATCH v2 4/5] remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor
Hi Mathieu,
thank you for taking the time to go through my patch!
On Wed, Jan 13, 2021 at 12:43 AM Mathieu Poirier
wrote:
[...]
> > + If unusre say N.
>
> s/unusre/unsure
godo catch, noted.
[...]
> > +#include
>
> Is it possible for this to go after platform_device.h?
I think so, not sure why this is not in alphabetical order
[...]
> > +#define AO_CPU_CNTL 0x0
> > + #define AO_CPU_CNTL_MEM_ADDR_UPPER GENMASK(28, 16)
> > + #define AO_CPU_CNTL_HALTBIT(9)
> > + #define AO_CPU_CNTL_UNKNONWNBIT(8)
> > + #define AO_CPU_CNTL_RUN BIT(0)
>
> Any reason for the extra tabulation at the beginning of the lines?
not really, I think I did the same thing as in
drivers/iio/adc/meson_saradc.c where the register itself starts at the
beginning of the line and each bit(mask) starts indented
I'll change this for the next version
[...]
> > +#define MESON_AO_RPROC_SRAM_USABLE_BITS GENMASK(31,
> > 20)
>
> As per your comments in the cover letter I assume we don't know more about
> this?
unfortunately not, but I'll still try to get some more information
from someone at Amlogic.
That said, this is "legacy" hardware for them so I can't make any promises.
> > +#define MESON_AO_RPROC_MEMORY_OFFSET 0x1000
> > +
> > +struct meson_mx_ao_arc_rproc_priv {
> > + void __iomem*remap_base;
> > + void __iomem*cpu_base;
> > + unsigned long sram_va;
> > + phys_addr_t sram_pa;
> > + size_t sram_size;
> > + struct gen_pool *sram_pool;
> > + struct reset_control*arc_reset;
> > + struct clk *arc_pclk;
> > + struct regmap *secbus2_regmap;
> > +};
> > +
> > +static int meson_mx_ao_arc_rproc_start(struct rproc *rproc)
> > +{
> > + struct meson_mx_ao_arc_rproc_priv *priv = rproc->priv;
> > + phys_addr_t phys_addr;
> > + int ret;
> > +
> > + ret = clk_prepare_enable(priv->arc_pclk);
> > + if (ret)
> > + return ret;
> > +
> > + writel(0, priv->remap_base + AO_REMAP_REG0);
> > + usleep_range(10, 100);
>
> That's wonderful - here too I assume there is no indication as to why this is
> needed?
looking at this again: the vendor driver only has a delay after
pulsing the reset line
I will double check and hopefully remove this usleep_range and only
keep the one below (after pulsing the reset line)
[...]
> > +static void *meson_mx_ao_arc_rproc_da_to_va(struct rproc *rproc, u64 da,
> > + size_t len)
> > +{
> > + struct meson_mx_ao_arc_rproc_priv *priv = rproc->priv;
> > +
> > + if ((da + len) >= priv->sram_size)
> > + return NULL;
>
> This isn't an index so it should be '>' rather than '>='. You should be able
> to
> ask for the whole range and get it, which the above prevents you from doing.
>
> Moreover are you sure 'da' always starts at 0? This seems to be at odds with
> your comment in meson_mx_ao_arc_rproc_start() about converting from 0xd900
> to 0xc900.
thanks for both of these comments, I'll address this in the next version
[...]
> > + priv->arc_reset = devm_reset_control_get_exclusive(dev, NULL);
> > + if (IS_ERR(priv->arc_reset)) {
>
> Looking at __devm_reset_control_get(), this should probably be
> IS_ERR_OR_NULL().
as far as I know only devm_reset_control_get_optional_exclusive (the
important bit is "optional" - I am using the "mandatory/not optional"
variant) can return NULL, all other variants return PTR_ERR or a valid
reset_control.
Best regards,
Martin
[PATCH v8 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC
The Netronix EC provides a PWM output which is used for the backlight
on some ebook readers. This patches adds a driver for the PWM output.
The .get_state callback is not implemented, because the PWM state can't
be read back from the hardware.
Signed-off-by: Jonathan Neuschäfer
Reviewed-by: Uwe Kleine-König
---
v8:
- Add Uwe Kleine-König's R-b tag
- Copy dev.of_node from parent device
v7:
- no changes
v6:
- https://lore.kernel.org/lkml/20201208011000.3060239-5-j.neuschae...@gmx.net/
- Move period / duty cycle setting code to a function
- Rename pwmchip_to_priv to ntxec_pwm_from_chip
- Set period and duty cycle only before enabling the output
- Mention that duty=0, enable=1 is assumed not to happen
- Interleave writes to the period and duty cycle registers, to minimize the
window of time that an inconsistent state is configured
v5:
- https://lore.kernel.org/lkml/20201201011513.1627028-5-j.neuschae...@gmx.net/
- Avoid truncation of period and duty cycle to 32 bits
- Make ntxec_pwm_ops const
- Use regmap_multi_reg_write
- Add comment about get_state to ntxec_pwm_ops
- Add comments about non-atomicity of (period, duty cycle) update
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-5-j.neuschae...@gmx.net/
- Document hardware/driver limitations
- Only accept normal polarity
- Fix a typo ("zone" -> "zero")
- change MAX_PERIOD_NS to 0x * 125
- Clamp period to the maximum rather than returning an error
- Rename private struct pointer to priv
- Rearrage control flow in _probe to save a few lines and a temporary variable
- Add missing MODULE_ALIAS line
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-5-j.neuschae...@gmx.net/
- Relicense as GPLv2 or later
- Add email address to copyright line
- Remove OF compatible string and don't include linux/of_device.h
- Fix bogus ?: in return line
- Don't use a comma after sentinels
- Avoid ret |= ... pattern
- Move 8-bit register conversion to ntxec.h
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-6-j.neuschae...@gmx.net/
- Various grammar and style improvements, as suggested by Uwe Kleine-König,
Lee Jones, and Alexandre Belloni
- Switch to regmap
- Prefix registers with NTXEC_REG_
- Add help text to the Kconfig option
- Use the .apply callback instead of the old API
- Add a #define for the time base (125ns)
- Don't change device state in .probe; this avoids multiple problems
- Rework division and overflow check logic to perform divisions in 32 bits
- Avoid setting duty cycle to zero, to work around a hardware quirk
---
drivers/pwm/Kconfig | 8 ++
drivers/pwm/Makefile| 1 +
drivers/pwm/pwm-ntxec.c | 184
3 files changed, 193 insertions(+)
create mode 100644 drivers/pwm/pwm-ntxec.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 0937e1c047acb..a2830b8832b97 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -393,6 +393,14 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_NTXEC
+ tristate "Netronix embedded controller PWM support"
+ depends on MFD_NTXEC
+ help
+ Say yes here if you want to support the PWM output of the embedded
+ controller found in certain e-book readers designed by the original
+ design manufacturer Netronix.
+
config PWM_OMAP_DMTIMER
tristate "OMAP Dual-Mode Timer PWM support"
depends on OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 18b89d7fd092a..7d97eb595bbef 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_PWM_MESON) += pwm-meson.o
obj-$(CONFIG_PWM_MEDIATEK) += pwm-mediatek.o
obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
+obj-$(CONFIG_PWM_NTXEC)+= pwm-ntxec.o
obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
diff --git a/drivers/pwm/pwm-ntxec.c b/drivers/pwm/pwm-ntxec.c
new file mode 100644
index 0..50c454c553c46
--- /dev/null
+++ b/drivers/pwm/pwm-ntxec.c
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found in some
+ * e-book readers designed by the original design manufacturer Netronix, Inc.
+ * It contains RTC, battery monitoring, system power management, and PWM
+ * functionality.
+ *
+ * This driver implements PWM output.
+ *
+ * Copyright 2020 Jonathan Neuschäfer
+ *
+ * Limitations:
+ * - The get_state callback is not implemented, because the current state of
+ * the PWM output can't be read back from the hardware.
+ * - The hardware can only generate normal polarity output.
+ * - The period and duty cycle can't be changed together in one atomic action.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
[PATCH v8 6/7] MAINTAINERS: Add entry for Netronix embedded controller
Let's make sure I'll notice when there are patches for the NTXEC drivers. Signed-off-by: Jonathan Neuschäfer --- v4-v8: - no changes v3: - https://lore.kernel.org/lkml/20200924192455.2484005-7-j.neuschae...@gmx.net/ - Remove pwm and rtc bindings v2: - https://lore.kernel.org/lkml/20200905144503.1067124-2-j.neuschae...@gmx.net/ - No changes --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 546aa66428c9f..0c6e739e3afb7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12298,6 +12298,15 @@ F: include/net/netrom.h F: include/uapi/linux/netrom.h F: net/netrom/ +NETRONIX EMBEDDED CONTROLLER +M: Jonathan Neuschäfer +S: Maintained +F: Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml +F: drivers/mfd/ntxec.c +F: drivers/pwm/pwm-ntxec.c +F: drivers/rtc/rtc-ntxec.c +F: include/linux/mfd/ntxec.h + NETRONOME ETHERNET DRIVERS M: Simon Horman R: Jakub Kicinski -- 2.29.2
Re: [PATCH] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses
On Fri, Jan 15, 2021 at 3:24 AM Petr Mladek wrote: > By other words, every print_hex_dump() used need to be reviewed in > which context might be called. I did a rough analysis of all current usage of DUMP_PREFIX_ADDRESS in the kernel, compared to the introduction of %px and hashed addresses, using git-blame to find the most recent commit that modifies a line that contains _ADDRESS. Of 150 cases, 110 of them are newer than %px, so I'm assuming that these developers chose _ADDRESS instead of _OFFSET knowing that the addresses are hashed. > > If you want, I can include a patch that changes a few callers of > > print_hex_dump() to use DUMP_PREFIX_UNHASHED, based on what I think would be > > useful. > > It would be nice. I have a v2 that I'm about to post, and I included a patch that modifies check_poison_mem() in mm/page_poison.c. I chose this file because I figured actual addresses would probably be necessary for tracking memory-related errors. Also, that call to print_hex_dump() was added back in 2009, so it predates the introduction of %px.
[PATCH v8 7/7] ARM: dts: imx50-kobo-aura: Add Netronix embedded controller
Enable the Netronix EC on the Kobo Aura ebook reader.
Several features are still missing:
- Frontlight/backlight. The vendor kernel drives the frontlight LED
using the PWM output of the EC and an additional boost pin that
increases the brightness.
- Battery monitoring
- Interrupts for RTC alarm and low-battery events
Signed-off-by: Jonathan Neuschäfer
---
v5-v8:
- no changes
v4:
- https://lore.kernel.org/lkml/20201123000913.1506944-1-j.neuschae...@gmx.net/
- Add 'grp' suffix to pinctrl node
v3:
- https://lore.kernel.org/lkml/20200925050818.2512375-1-j.neuschae...@gmx.net/
- Remove interrupt-controller property from embedded-controller node
- subnodes of embedded-controller node in to the main node
v2:
- https://lore.kernel.org/lkml/20200905144503.1067124-3-j.neuschae...@gmx.net/
- Fix pwm-cells property (should be 2, not 1)
---
arch/arm/boot/dts/imx50-kobo-aura.dts | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx50-kobo-aura.dts
b/arch/arm/boot/dts/imx50-kobo-aura.dts
index 97cfd970fe742..82ce8c43be867 100644
--- a/arch/arm/boot/dts/imx50-kobo-aura.dts
+++ b/arch/arm/boot/dts/imx50-kobo-aura.dts
@@ -143,10 +143,24 @@ {
pinctrl-0 = <_i2c3>;
status = "okay";
- /* TODO: embedded controller at 0x43 */
+ embedded-controller@43 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_ec>;
+ compatible = "netronix,ntxec";
+ reg = <0x43>;
+ system-power-controller;
+ interrupts-extended = < 11 IRQ_TYPE_EDGE_FALLING>;
+ #pwm-cells = <2>;
+ };
};
{
+ pinctrl_ec: ecgrp {
+ fsl,pins = <
+ MX50_PAD_CSPI_SS0__GPIO4_11 0x0 /* INT
*/
+ >;
+ };
+
pinctrl_gpiokeys: gpiokeysgrp {
fsl,pins = <
MX50_PAD_CSPI_MISO__GPIO4_100x0
--
2.29.2
[PATCH v8 5/7] rtc: New driver for RTC in Netronix embedded controller
With this driver, mainline Linux can keep its time and date in sync with
the vendor kernel.
Advanced functionality like alarm and automatic power-on is not yet
supported.
Signed-off-by: Jonathan Neuschäfer
Acked-by: Alexandre Belloni
---
v8:
- Copy dev.of_node from parent device
v7:
- Adjust to recent RTC API change (rtc_register_device ->
devm_rtc_register_device)
v6:
- no changes
v5:
- https://lore.kernel.org/lkml/20201201011513.1627028-6-j.neuschae...@gmx.net/
- Add Alexandre Belloni's A-b
- Use regmap_multi_reg_write
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-6-j.neuschae...@gmx.net/
- Remove "driver" from Kconfig entry for consistency with most other entries
- Add missing MODULE_ALIAS line
- Give NTXEC_REG_READ_ macros longer names
- Solve the read tearing issue using Alexandre Belloni's algorithm
- Solve the write tearing issue using Uwe Kleine-König's algorithm
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-6-j.neuschae...@gmx.net/
- Add email address to copyright line
- Remove OF compatible string and don't include linux/of_device.h
- Don't use a comma after sentinels
- Avoid ret |= ... pattern
- Move 8-bit register conversion to ntxec.h
- Relicense as GPLv2 or later
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-7-j.neuschae...@gmx.net/
- Rework top-of-file comment [Lee Jones]
- Sort the #include lines [Alexandre Belloni]
- don't align = signs in struct initializers [Uwe Kleine-König]
- Switch to regmap
- Fix register number used to read minutes and seconds
- Prefix registers with NTXEC_REG_
- Add help text to the Kconfig option
- Use devm_rtc_allocate_device and rtc_register_device, set ->range_min and
->range_max
---
drivers/rtc/Kconfig | 8 +++
drivers/rtc/Makefile| 1 +
drivers/rtc/rtc-ntxec.c | 145
3 files changed, 154 insertions(+)
create mode 100644 drivers/rtc/rtc-ntxec.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 6123f9f4fbc90..d49cf387add14 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1315,6 +1315,14 @@ config RTC_DRV_CROS_EC
This driver can also be built as a module. If so, the module
will be called rtc-cros-ec.
+config RTC_DRV_NTXEC
+ tristate "Netronix embedded controller RTC"
+ depends on MFD_NTXEC
+ help
+ Say yes here if you want to support the RTC functionality of the
+ embedded controller found in certain e-book readers designed by the
+ original design manufacturer Netronix.
+
comment "on-CPU RTC drivers"
config RTC_DRV_ASM9260
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index bb8f319b09fbf..92c26eafe70ce 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -110,6 +110,7 @@ obj-$(CONFIG_RTC_DRV_MT7622)+= rtc-mt7622.o
obj-$(CONFIG_RTC_DRV_MV) += rtc-mv.o
obj-$(CONFIG_RTC_DRV_MXC) += rtc-mxc.o
obj-$(CONFIG_RTC_DRV_MXC_V2) += rtc-mxc_v2.o
+obj-$(CONFIG_RTC_DRV_NTXEC)+= rtc-ntxec.o
obj-$(CONFIG_RTC_DRV_OMAP) += rtc-omap.o
obj-$(CONFIG_RTC_DRV_OPAL) += rtc-opal.o
obj-$(CONFIG_RTC_DRV_PALMAS) += rtc-palmas.o
diff --git a/drivers/rtc/rtc-ntxec.c b/drivers/rtc/rtc-ntxec.c
new file mode 100644
index 0..850ca49186fdc
--- /dev/null
+++ b/drivers/rtc/rtc-ntxec.c
@@ -0,0 +1,145 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found in some
+ * e-book readers designed by the original design manufacturer Netronix, Inc.
+ * It contains RTC, battery monitoring, system power management, and PWM
+ * functionality.
+ *
+ * This driver implements access to the RTC time and date.
+ *
+ * Copyright 2020 Jonathan Neuschäfer
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ntxec_rtc {
+ struct device *dev;
+ struct ntxec *ec;
+};
+
+#define NTXEC_REG_WRITE_YEAR 0x10
+#define NTXEC_REG_WRITE_MONTH 0x11
+#define NTXEC_REG_WRITE_DAY0x12
+#define NTXEC_REG_WRITE_HOUR 0x13
+#define NTXEC_REG_WRITE_MINUTE 0x14
+#define NTXEC_REG_WRITE_SECOND 0x15
+
+#define NTXEC_REG_READ_YEAR_MONTH 0x20
+#define NTXEC_REG_READ_MDAY_HOUR 0x21
+#define NTXEC_REG_READ_MINUTE_SECOND 0x23
+
+static int ntxec_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct ntxec_rtc *rtc = dev_get_drvdata(dev);
+ unsigned int value;
+ int res;
+
+retry:
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_MINUTE_SECOND,
);
+ if (res < 0)
+ return res;
+
+ tm->tm_min = value >> 8;
+ tm->tm_sec = value & 0xff;
+
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_MDAY_HOUR, );
+ if (res < 0)
+ return res;
+
+ tm->tm_mday = value >> 8;
+ tm->tm_hour = value & 0xff;
+
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_YEAR_MONTH, );
+ if (res < 0)
+ return res;
+
+ tm->tm_year = (value
RE: [PATCH] dt-bindings: mips: lantiq: Document Lantiq Xway DMA bindings
(another late reply from me, sorry)
> +required:
> + - compatible
> + - reg
This is actually an older IP variant of what can be found in the Intel
LGM SoCs. The dt-bindings are currently being upstreamed for that newer
SoC in [0].
Based on "DOs and DON’Ts for designing and writing Devicetree bindings"
I think some more mandatory properties are needed, even though our
driver currently uses none of them:
- interrupts: as far as I know the IP on the Lantiq SoCs has (at least)
one interrupt for each DMA channel. That means: 28 interrupts on the
xRX200 SoCs
- I *assume* (but I have not researched if that's really the case) that
the Lantiq variant also has at least one clock input and a reset line
- since we don't have a proper DMA driver yet I can't comment what we
should use for #dma-cells
> +examples:
> + - |
> +dma@e104100 {
note to self: it seems that both dma@ and dma-controller@ are used in
existing schemas (the latter having twice as many occurrences though):
$ grep -R dma@ Documentation/devicetree/bindings/dma/* | wc -l
20
$ grep -R dma-controller@ Documentation/devicetree/bindings/dma/* | wc -l
45
Best regards,
Martin
[0]
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/0864b9bfa6e2b8b5e7ad9a7a739ca3274f66493c.1610703653.git.mallikarjunax.re...@linux.intel.com/
[1]
https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-bindings.html
Re: [PATCH v2] gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default
On Sat, Jan 16, 2021 at 3:15 AM Saravana Kannan wrote: > v1 -> v2: > - Fixed up compilation errors that were introduced accidentally > - Fixed a missing put_device() See my comments as per v1 and address. -- With Best Regards, Andy Shevchenko
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
Re: [PATCH v1] gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default
On Fri, Jan 15, 2021 at 11:03 PM Saravana Kannan wrote:
>
> There are multiple instances of GPIO devictree nodes of the form:
What? Device Tree (or device tree).
> foo {
> compatible = "acme,foo";
> ...
>
> gpio0: gpio0@ {
> compatible = "acme,bar";
> ...
> gpio-controller;
> };
>
> gpio1: gpio1@ {
> compatible = "acme,bar";
> ...
> gpio-controller;
> };
>
> ...
> }
>
> bazz {
> my-gpios = < ...>;
> }
>
> Case 1: The driver for "foo" populates struct device for these gpio*
> nodes and then probes them using a driver that binds with "acme,bar".
> This lines up with how DT nodes with the "compatible" property are
> generally converted to struct devices and then registered with driver
> core to probe them. This also allows the gpio* devices to hook into all
> the driver core capabilities like runtime PM, probe deferral,
> suspend/resume ordering, device links, etc.
>
> Case 2: The driver for "foo" doesn't populate its child device nodes
> with "compatible" property and instead just loops through its child
> nodes and directly registers the GPIOs with gpiolib without ever
> populating a struct device or binding a driver to it.
>
> Drivers that follow the case 2 cause problems with fw_devlink=on. This
follow case
> is because fw_devlink will prevent bazz from probing until there's a
> struct device that has gpio0 as its fwnode (because bazz lists gpio0 as
> a GPIO supplier). Once the struct device is available, fw_devlink will
> create a device link between with gpio0 as the supplier and bazz as the
> consumer. After this point, the device link will prevent bazz from
> probing until its supplier (the gpio0 device) has bound to a driver.
> Once the supplier is bound to a driver, the probe of bazz is triggered
> automatically.
>
> Finding and refactoring all the instances of drivers that follow case 2
> will cause a lot of code churn and it not something that can be done in
it is not
> one shot. Examples of such instances are [1] [2].
>
> This patch works around this problem and avoids all the code churn by
> simply creating a stub driver to bind to the gpio_device. Since the
> gpio_device already points to the GPIO device tree node, this allows all
> the consumers to continue probing when the driver follows case 2.
>
> If/when all the old drivers are refactored, we can revert this patch.
>
> [1] - https://lore.kernel.org/lkml/20201014191235.7f71fcb4@xhacker.debian/
> [2] -
> https://lore.kernel.org/lkml/e28e1f38d87c12a3c714a6573beba...@kernel.org/
Link: tags?
...
> + of_node = gdev->dev.of_node;
This seems unused (see below).
> + fwnode = of_fwnode_handle(of_node);
I don't get this. Are you telling that dev_fwnode(>dev) is not the same?
> + fwnode_dev = get_dev_from_fwnode(fwnode);
> +
> + /*
> +* If your driver hits this warning, it's because you are directly
> +* parsing a device tree node with "compatible" property and
> +* initializing it instead of using the standard DT + device driver
> +* model of creating a struct device and then initializing it in the
> +* probe function. Please refactor your driver.
> +*/
> + if (!fwnode_dev && of_find_property(gdev->dev.of_node, "compatible"))
> {
fwnode_property_present() ?
> + chip_warn(gc, "Create a real device for %pOF\n" of_node);
%pfw ?
> + gdev->dev.fwnode = fwnode;
Why not dev_fwnode()?
> + }
> #endif
...
> +static struct device_driver gpio_drv = {
> + .name = "gpio_drv",
Can it have a better name, please?
> + .bus = _bus_type,
> + .probe = gpio_drv_probe,
> +};
--
With Best Regards,
Andy Shevchenko
RE: [PATCH] dt-bindings: mips: lantiq: Document Lantiq Xway EBU bindings
(again, sorry for seeing this patch late) > +properties: > + compatible: > +items: > + - enum: > + - lantiq,ebu-xway I think this compatible string is very generic and with that comes some problems. There is actually two different versions of this IP: one which has support for controlling the interrupt of the PCI controller on some SoCs (Danube, xRX100, xRX200). Other SoC variants (Falcon, Amazon-SE) don't have that interrupt-controller as they don't have PCI support. Also there is at least one clock input. I *assume* we need to describe it but I am not sure (as this platform doesn't use the common clock framework yet). My version of this can be found here [0]. It's still sitting in my tree because it has a dependency on an ICU patch in my tree which I could not make work properly yet. Best regards, Martin [0] https://github.com/xdarklight/linux/blob/8d5c632e11fe0ca14497efc2f9d99b69f75590ba/Documentation/devicetree/bindings/mips/lantiq/lantiq%2Cebu.yaml
sound/soc/samsung/aries_wm8994.c:525:34: warning: unused variable 'samsung_wm8994_of_match'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 1d94330a437a573cfdf848f6743b1ed169242c8a
commit: 84569f329f7fcb40b7b1860f273b2909dabf2a2b Merge remote-tracking branch
'asoc/for-5.9' into asoc-next
date: 6 months ago
config: arm-randconfig-r033-20210117 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
d7bc3b7ce23b664d6620cdc32370a8614523ca2f)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84569f329f7fcb40b7b1860f273b2909dabf2a2b
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 84569f329f7fcb40b7b1860f273b2909dabf2a2b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> sound/soc/samsung/aries_wm8994.c:525:34: warning: unused variable
>> 'samsung_wm8994_of_match' [-Wunused-const-variable]
static const struct of_device_id samsung_wm8994_of_match[] = {
^
1 warning generated.
vim +/samsung_wm8994_of_match +525 sound/soc/samsung/aries_wm8994.c
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 524
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 @525 static const struct
of_device_id samsung_wm8994_of_match[] = {
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 526{
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 527.compatible =
"samsung,fascinate4g-wm8994",
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 528.data =
_variant,
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 529},
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 530{
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 531.compatible =
"samsung,aries-wm8994",
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 532.data =
_variant,
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 533},
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 534{ /* sentinel */ },
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 535 };
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 536 MODULE_DEVICE_TABLE(of,
samsung_wm8994_of_match);
7a3a7671fa6c7e90 Jonathan Bakker 2020-06-14 537
:: The code at line 525 was first introduced by commit
:: 7a3a7671fa6c7e90aff5f4242add2a40587b85ef ASoC: samsung: Add driver for
Aries boards
:: TO: Jonathan Bakker
:: CC: Mark Brown
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
RE: [PATCH] dt-bindings: mips: lantiq: Document Lantiq Xway CGU bindings
(sorry for only seeing this late)
[...]
> +maintainers:
> + - John Crispin
personally I think we should get at least John's Acked-by but I don't
know if there's any rule for adding a dt-binding for some other
maintainer
[...]
> +required:
> + - compatible
> + - reg
based on "DOs and DON’Ts for designing and writing Devicetree bindings"
from [0] I think this is incomplete
As far as I know CGU contains some PLLs. These PLLs need at least one
input: the main XTAL which is found on the board
Also the Lantiq code does not use the common clock framework yet. Once
that's used we also need #clock-cells = <1>. I don't know if that
should be added already (or not).
> +examples:
> + - |
> +cgu@103000 {
this should be clock-controller@...
Best regards,
Martin
[0]
https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-bindings.html
Re: [GIT PULL] SCSI fixes for 5.11-rc3
The pull request you sent on Sat, 16 Jan 2021 12:21:17 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0da0a8a0a0e1845f495431c3d8d733d2bbf9e9e5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v3 0/4] Remove one more platform_device_add_properties() call
On Fri, Jan 15, 2021 at 11:52 AM Heikki Krogerus wrote: > > Hi, > > I'm now clearing the dev_fwnode(dev)->secondary pointer in > device_remove_software_node() as requested by Daniel and Andy. Thanks > guys, it's much better now. I also took the liberty of including one > more PCI ID patch where I add PCI ID for the Alder Lake-P variant. I > hope that is OK. > > Andy, I dropped your Tested-by tag because of the change I made to the > first patch. If you have time to retest these, I would much appreciate. Since Greg already grabbed a v3 I will test it when it appears in linux-next. -- With Best Regards, Andy Shevchenko
Re: [PATCH v5] pgo: add clang's Profile Guided Optimization infrastructure
On Sat, Jan 16, 2021 at 9:39 AM Sedat Dilek wrote: > On Sat, Jan 16, 2021 at 10:44 AM 'Bill Wendling' via Clang Built Linux > wrote: > > > > From: Sami Tolvanen > > > > Enable the use of clang's Profile-Guided Optimization[1]. To generate a > > profile, the kernel is instrumented with PGO counters, a representative > > workload is run, and the raw profile data is collected from > > /sys/kernel/debug/pgo/profraw. > > > > The raw profile data must be processed by clang's "llvm-profdata" tool > > before it can be used during recompilation: > > > > $ cp /sys/kernel/debug/pgo/profraw vmlinux.profraw > > $ llvm-profdata merge --output=vmlinux.profdata vmlinux.profraw > > > > Multiple raw profiles may be merged during this step. > > > > The data can now be used by the compiler: > > > > $ make LLVM=1 KCFLAGS=-fprofile-use=vmlinux.profdata ... > > > > This initial submission is restricted to x86, as that's the platform we > > know works. This restriction can be lifted once other platforms have > > been verified to work with PGO. > > > > Note that this method of profiling the kernel is clang-native, unlike > > the clang support in kernel/gcov. > > > > [1] https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization > > > > Signed-off-by: Sami Tolvanen > > Co-developed-by: Bill Wendling > > Signed-off-by: Bill Wendling > > --- > > v2: - Added "__llvm_profile_instrument_memop" based on Nathan Chancellor's > > testing. > > - Corrected documentation, re PGO flags when using LTO, based on Fangrui > > Song's comments. > > v3: - Added change log section based on Sedat Dilek's comments. > > v4: - Remove non-x86 Makfile changes and se "hweight64" instead of using our > > own popcount implementation, based on Nick Desaulniers's comment. > > v5: - Correct padding calculation, discovered by Nathan Chancellor. > > --- > > Documentation/dev-tools/index.rst | 1 + > > Documentation/dev-tools/pgo.rst | 127 + > > MAINTAINERS | 9 + > > Makefile | 3 + > > arch/Kconfig | 1 + > > arch/x86/Kconfig | 1 + > > arch/x86/boot/Makefile| 1 + > > arch/x86/boot/compressed/Makefile | 1 + > > arch/x86/crypto/Makefile | 2 + > > arch/x86/entry/vdso/Makefile | 1 + > > arch/x86/kernel/vmlinux.lds.S | 2 + > > arch/x86/platform/efi/Makefile| 1 + > > arch/x86/purgatory/Makefile | 1 + > > arch/x86/realmode/rm/Makefile | 1 + > > arch/x86/um/vdso/Makefile | 1 + > > drivers/firmware/efi/libstub/Makefile | 1 + > > include/asm-generic/vmlinux.lds.h | 44 +++ > > kernel/Makefile | 1 + > > kernel/pgo/Kconfig| 35 +++ > > kernel/pgo/Makefile | 5 + > > kernel/pgo/fs.c | 382 ++ > > kernel/pgo/instrument.c | 185 + > > kernel/pgo/pgo.h | 206 ++ > > scripts/Makefile.lib | 10 + > > 24 files changed, 1022 insertions(+) > > create mode 100644 Documentation/dev-tools/pgo.rst > > create mode 100644 kernel/pgo/Kconfig > > create mode 100644 kernel/pgo/Makefile > > create mode 100644 kernel/pgo/fs.c > > create mode 100644 kernel/pgo/instrument.c > > create mode 100644 kernel/pgo/pgo.h > > > > diff --git a/Documentation/dev-tools/index.rst > > b/Documentation/dev-tools/index.rst > > index f7809c7b1ba9e..8d6418e858062 100644 > > --- a/Documentation/dev-tools/index.rst > > +++ b/Documentation/dev-tools/index.rst > > @@ -26,6 +26,7 @@ whole; patches welcome! > > kgdb > > kselftest > > kunit/index > > + pgo > > > > > > .. only:: subproject and html > > diff --git a/Documentation/dev-tools/pgo.rst > > b/Documentation/dev-tools/pgo.rst > > new file mode 100644 > > index 0..b7f11d8405b73 > > --- /dev/null > > +++ b/Documentation/dev-tools/pgo.rst > > @@ -0,0 +1,127 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > +=== > > +Using PGO with the Linux kernel > > +=== > > + > > +Clang's profiling kernel support (PGO_) enables profiling of the Linux > > kernel > > +when building with Clang. The profiling data is exported via the ``pgo`` > > +debugfs directory. > > + > > +.. _PGO: > > https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization > > + > > + > > +Preparation > > +=== > > + > > +Configure the kernel with: > > + > > +.. code-block:: make > > + > > + CONFIG_DEBUG_FS=y > > + CONFIG_PGO_CLANG=y > > + > > +Note that kernels compiled with profiling flags will be significantly > > larger > > +and run slower. > > + > > +Profiling data will only become accessible once debugfs has been mounted: > > + > > +.. code-block:: sh > > + > > + mount -t debugfs none
[GIT PULL] SCSI fixes for 5.11-rc3
Nine minor fixes, 7 in drivers and 2 in the core SCSI disk driver (sd)
which should be harmless involving removing an unused variable and
quietening a spurious warning.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Can Guo (1):
scsi: ufs: Correct the LUN used in eh_device_reset_handler() callback
Colin Ian King (1):
scsi: mpt3sas: Fix spelling mistake in Kconfig "compatiblity" ->
"compatibility"
Dinghao Liu (1):
scsi: scsi_debug: Fix memleak in scsi_debug_init()
Ewan D. Milne (1):
scsi: sd: Suppress spurious errors when WRITE SAME is being disabled
Kiwoong Kim (1):
scsi: ufs: Relocate flush of exceptional event
Lukas Bulwahn (1):
scsi: sd: Remove obsolete variable in sd_remove()
Nilesh Javali (1):
scsi: qedi: Correct max length of CHAP secret
Stanley Chu (2):
scsi: ufs: Relax the condition of UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
scsi: ufs: Fix possible power drain during system suspend
And the diffstat:
drivers/scsi/mpt3sas/Kconfig | 2 +-
drivers/scsi/qedi/qedi_main.c | 4 ++--
drivers/scsi/scsi_debug.c | 5 +++--
drivers/scsi/sd.c | 6 +++---
drivers/scsi/ufs/ufshcd.c | 24 ++--
5 files changed, 19 insertions(+), 22 deletions(-)
With full diff below.
James
---
diff --git a/drivers/scsi/mpt3sas/Kconfig b/drivers/scsi/mpt3sas/Kconfig
index 86209455172d..c299f7e078fb 100644
--- a/drivers/scsi/mpt3sas/Kconfig
+++ b/drivers/scsi/mpt3sas/Kconfig
@@ -79,5 +79,5 @@ config SCSI_MPT2SAS
select SCSI_MPT3SAS
depends on PCI && SCSI
help
- Dummy config option for backwards compatiblity: configure the MPT3SAS
+ Dummy config option for backwards compatibility: configure the MPT3SAS
driver instead.
diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c
index f5fc7f518f8a..47ad64b06623 100644
--- a/drivers/scsi/qedi/qedi_main.c
+++ b/drivers/scsi/qedi/qedi_main.c
@@ -2245,7 +2245,7 @@ qedi_show_boot_tgt_info(struct qedi_ctx *qedi, int type,
chap_name);
break;
case ISCSI_BOOT_TGT_CHAP_SECRET:
- rc = sprintf(buf, "%.*s\n", NVM_ISCSI_CFG_CHAP_NAME_MAX_LEN,
+ rc = sprintf(buf, "%.*s\n", NVM_ISCSI_CFG_CHAP_PWD_MAX_LEN,
chap_secret);
break;
case ISCSI_BOOT_TGT_REV_CHAP_NAME:
@@ -2253,7 +2253,7 @@ qedi_show_boot_tgt_info(struct qedi_ctx *qedi, int type,
mchap_name);
break;
case ISCSI_BOOT_TGT_REV_CHAP_SECRET:
- rc = sprintf(buf, "%.*s\n", NVM_ISCSI_CFG_CHAP_NAME_MAX_LEN,
+ rc = sprintf(buf, "%.*s\n", NVM_ISCSI_CFG_CHAP_PWD_MAX_LEN,
mchap_secret);
break;
case ISCSI_BOOT_TGT_FLAGS:
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 24c0f7ec0351..4a08c450b756 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -6740,7 +6740,7 @@ static int __init scsi_debug_init(void)
k = sdeb_zbc_model_str(sdeb_zbc_model_s);
if (k < 0) {
ret = k;
- goto free_vm;
+ goto free_q_arr;
}
sdeb_zbc_model = k;
switch (sdeb_zbc_model) {
@@ -6753,7 +6753,8 @@ static int __init scsi_debug_init(void)
break;
default:
pr_err("Invalid ZBC model\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto free_q_arr;
}
}
if (sdeb_zbc_model != BLK_ZONED_NONE) {
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 679c2c025047..a3d2d4bc4a3d 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -984,8 +984,10 @@ static blk_status_t sd_setup_write_zeroes_cmnd(struct
scsi_cmnd *cmd)
}
}
- if (sdp->no_write_same)
+ if (sdp->no_write_same) {
+ rq->rq_flags |= RQF_QUIET;
return BLK_STS_TARGET;
+ }
if (sdkp->ws16 || lba > 0x || nr_blocks > 0x)
return sd_setup_write_same16_cmnd(cmd, false);
@@ -3510,10 +3512,8 @@ static int sd_probe(struct device *dev)
static int sd_remove(struct device *dev)
{
struct scsi_disk *sdkp;
- dev_t devt;
sdkp = dev_get_drvdata(dev);
- devt = disk_devt(sdkp->disk);
scsi_autopm_get_device(sdkp->device);
async_synchronize_full_domain(_sd_pm_domain);
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 82ad31781bc9..e31d2c5c7b23 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -289,7 +289,8 @@ static inline void ufshcd_wb_config(struct ufs_hba *hba)
if (ret)
Re: [PATCH 1/2] dt-bindings: soc: ti: ti,pruss: add ti,am1806-pruss
On 1/15/21 10:45 AM, Suman Anna wrote: + Sekhar and Bartosz Hi David, On 1/4/21 12:30 PM, David Lechner wrote: This adds a "ti,am1806-pruss" compatible type for the PRUSS found in TI AM18xx/OMAP-L138 SoCs. Signed-off-by: David Lechner --- Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index 037c51b2f972..a6ed23fdbc00 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -61,6 +61,7 @@ properties: compatible: enum: + - ti,am1806-pruss # for AM18xx/OMAP-L138 SoC family Almost all the drivers for these SoCs use the prefix "ti,da850-xxx" for the compatibles. Can we switch to using those instead of ti,am1806? I wasn't sure which chips exactly are "DA850". If someone can tell me, I can look at the docs to see if they have a PRUSS.
drivers/net/ethernet/google/gve/gve_tx.c:507:25: warning: variable 'buf' set but not used
Hi Catherine,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 1d94330a437a573cfdf848f6743b1ed169242c8a
commit: 6f007c6486d69967ac1d9e67df9ae9c77d49f1cc gve: Add support for raw
addressing in the tx path
date: 6 weeks ago
config: i386-randconfig-r026-20210117 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6f007c6486d69967ac1d9e67df9ae9c77d49f1cc
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 6f007c6486d69967ac1d9e67df9ae9c77d49f1cc
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/net/ethernet/google/gve/gve_tx.c: In function
'gve_tx_add_skb_no_copy':
>> drivers/net/ethernet/google/gve/gve_tx.c:507:25: warning: variable 'buf' set
>> but not used [-Wunused-but-set-variable]
507 | struct gve_tx_dma_buf *buf;
| ^~~
vim +/buf +507 drivers/net/ethernet/google/gve/gve_tx.c
497
498 static int gve_tx_add_skb_no_copy(struct gve_priv *priv, struct
gve_tx_ring *tx,
499struct sk_buff *skb)
500 {
501 const struct skb_shared_info *shinfo = skb_shinfo(skb);
502 int hlen, payload_nfrags, l4_hdr_offset;
503 union gve_tx_desc *pkt_desc, *seg_desc;
504 struct gve_tx_buffer_state *info;
505 bool is_gso = skb_is_gso(skb);
506 u32 idx = tx->req & tx->mask;
> 507 struct gve_tx_dma_buf *buf;
508 u64 addr;
509 u32 len;
510 int i;
511
512 info = >info[idx];
513 pkt_desc = >desc[idx];
514
515 l4_hdr_offset = skb_checksum_start_offset(skb);
516 /* If the skb is gso, then we want only up to the tcp header in
the first segment
517 * to efficiently replicate on each segment otherwise we want
the linear portion
518 * of the skb (which will contain the checksum because
skb->csum_start and
519 * skb->csum_offset are given relative to skb->head) in the
first segment.
520 */
521 hlen = is_gso ? l4_hdr_offset + tcp_hdrlen(skb) :
skb_headlen(skb);
522 len = skb_headlen(skb);
523
524 info->skb = skb;
525
526 addr = dma_map_single(tx->dev, skb->data, len, DMA_TO_DEVICE);
527 if (unlikely(dma_mapping_error(tx->dev, addr))) {
528 tx->dma_mapping_error++;
529 goto drop;
530 }
531 buf = >buf;
532 dma_unmap_len_set(buf, len, len);
533 dma_unmap_addr_set(buf, dma, addr);
534
535 payload_nfrags = shinfo->nr_frags;
536 if (hlen < len) {
537 /* For gso the rest of the linear portion of the skb
needs to
538 * be in its own descriptor.
539 */
540 payload_nfrags++;
541 gve_tx_fill_pkt_desc(pkt_desc, skb, is_gso,
l4_hdr_offset,
542 1 + payload_nfrags, hlen, addr);
543
544 len -= hlen;
545 addr += hlen;
546 idx = (tx->req + 1) & tx->mask;
547 seg_desc = >desc[idx];
548 gve_tx_fill_seg_desc(seg_desc, skb, is_gso, len, addr);
549 } else {
550 gve_tx_fill_pkt_desc(pkt_desc, skb, is_gso,
l4_hdr_offset,
551 1 + payload_nfrags, hlen, addr);
552 }
553
554 for (i = 0; i < shinfo->nr_frags; i++) {
555 const skb_frag_t *frag = >frags[i];
556
557 idx = (idx + 1) & tx->mask;
558 seg_desc = >desc[idx];
559 len = skb_frag_size(frag);
560 addr = skb_frag_dma_map(tx->dev, frag, 0, len,
DMA_TO_DEVICE);
561 if (unlikely(dma_mapping_error(tx->dev, addr))) {
562 tx->dma_mapping_error++;
563 goto unmap_drop;
564 }
565 buf = >info[idx].buf;
566 tx->info[idx].skb = NULL;
567 dma_unmap_len_set(buf, len, len);
568 dma_unmap_addr_set(buf, dma, addr);
569
570 gve_tx_fill_seg_desc(seg_desc, skb, is_gso, len, addr);
571 }
572
573 return 1 + payload_nfrags;
574
575 unmap_drop:
576
Re: [PATCH 2/2] soc: ti: pruss: add support for AM18XX/OMAP-L138 PRUSS
On 1/15/21 6:52 PM, Suman Anna wrote:
Hi David,
On 1/4/21 12:30 PM, David Lechner wrote:
This adds support for the PRUSS found in AM18XX/OMAP-L138. This PRUSS
doesn't have a CFG register, so that is made optional as selected by
the device tree compatible string.
ARCH_DAVINCI is added in the Kconfig so that the driver can be selected
on that platform.
Signed-off-by: David Lechner
---
drivers/soc/ti/Kconfig | 2 +-
drivers/soc/ti/pruss.c | 76 --
2 files changed, 45 insertions(+), 33 deletions(-)
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 7e2fb1c16af1..7a692a21480a 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -85,7 +85,7 @@ config TI_K3_SOCINFO
config TI_PRUSS
tristate "TI PRU-ICSS Subsystem Platform drivers"
- depends on SOC_AM33XX || SOC_AM43XX || SOC_DRA7XX || ARCH_KEYSTONE ||
ARCH_K3
+ depends on ARCH_DAVINCI || SOC_AM33XX || SOC_AM43XX || SOC_DRA7XX ||
ARCH_KEYSTONE || ARCH_K3
select MFD_SYSCON
help
TI PRU-ICSS Subsystem platform specific support.
diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
index 5d6e7132a5c4..bfaf3ff74b01 100644
--- a/drivers/soc/ti/pruss.c
+++ b/drivers/soc/ti/pruss.c
@@ -24,10 +24,12 @@
* struct pruss_private_data - PRUSS driver private data
* @has_no_sharedram: flag to indicate the absence of PRUSS Shared Data RAM
* @has_core_mux_clock: flag to indicate the presence of PRUSS core clock
+ * @has_cfg: flag to indicate the presence of PRUSS CFG registers
I recommend to change this to a negative flag as the Davinci platforms are the
only ones that don't have CFG (being the very first SoCs with a PRUSS IP)
sub-module.
Negative flags hurt my brain. :-)
I was actually thinking about submitting a patch to convert
has_no_sharedram to a positive flag as well. But I understand
the sentiment of only setting the flag true for the odd case
rather than the usual case.
*/
struct pruss_private_data {
bool has_no_sharedram;
bool has_core_mux_clock;
+ bool has_cfg;
};
static void pruss_of_free_clk_provider(void *data)
@@ -239,42 +241,44 @@ static int pruss_probe(struct platform_device *pdev)
goto rpm_disable;
}
And use it here to skip all the cfg code parsing. All the below delta is just
for the additional indentation for the flag. If you don't like goto's in
non-error paths, then we can refactor the CFG parse code into a separate
function.
Refactoring to a separate function sounds good to me.
[PATCH] media: i2c: fix odd_ptr_err.cocci warnings
From: kernel test robot
PTR_ERR should access the value just tested by IS_ERR
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
Fixes: 11c0d8fdccc5 ("media: i2c: Add support for the OV8865 image sensor")
CC: Paul Kocialkowski
Reported-by: kernel test robot
Signed-off-by: kernel test robot
Signed-off-by: Julia Lawall
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: b3a3cbdec55b090d22a09f75efb7c7d34cb97f25
commit: 11c0d8fdccc56fa15cb15906480b4737c31dd085 [2650/3956] media: i2c: Add
support for the OV8865 image sensor
:: branch date: 2 days ago
:: commit date: 4 days ago
ov8865.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/media/i2c/ov8865.c
+++ b/drivers/media/i2c/ov8865.c
@@ -2849,7 +2849,7 @@ static int ov8865_probe(struct i2c_clien
sensor->avdd = devm_regulator_get(dev, "avdd");
if (IS_ERR(sensor->avdd)) {
dev_err(dev, "cannot get AVDD (analog) regulator\n");
- ret = PTR_ERR(sensor->dvdd);
+ ret = PTR_ERR(sensor->avdd);
goto error_endpoint;
}
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 14th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
Re: [GIT PULL] RISC-V Fixes for 5.11-rc4
The pull request you sent on Sat, 16 Jan 2021 09:54:51 -0800 (PST): > git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git > tags/riscv-for-linus-5.11-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/acda701bf1e8233f982164c8ddbedc055427212d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
