From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2608939BFE1 for ; Wed, 8 Apr 2026 08:33:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775637230; cv=none; b=g3UO/pST8EHCx5UNTm43IfBaYNDkG/z1gzdUKMXLeCQwypz402ZgYhANx68MQw4/50D1rcMABqPachsYJACMKcQitprrseeXv4zUFRRvNohwZQMxpD/R1Mh+WeexplrRg3weg/BNGiLWtCZxIcHKPdW7n99Vz00mRANi/hdY6Bs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775637230; c=relaxed/simple; bh=OKjKmjKCU62uaCjhibuDqhSE1AGMzLcspem2OqAtVYs=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=PXRB6QGYO+QLcXpXYFpMcuaWGRzlIfp7dUE161E1SB4oeeHNICWgcPsZ4l6RSvc/cRTMQKclYXbcvLZFKkph9W9l05X+eXyxWEieTpNSUR2mEmHylMWtGPQyUEuy/gSDF/AbjZPDmIAsk8YfKaTDWK3P0CBRbGnXyQYbM0UZKSA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=p77gfSBu; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="p77gfSBu" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-488b00ed86fso31093065e9.3 for ; Wed, 08 Apr 2026 01:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775637227; x=1776242027; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=Pbj1pinyLCpTvRMDqb5wMltAGKRQ0z6dfcrCaaij6ks=; b=p77gfSBuAxonX9liwZs+8/t5Mudz4WzeCGIoIxYvYIjpyA3tLkryVpFL4NFPypkswo y2I+VVzgrjUd10ofAtxbWy3xVVEKHqt40qaZsvsUZrUFxhR+SJWWfeKZLncB6lu5M9z7 /+yfuyXJi4tdiDDIfAtiauxD6s2BzLDVxZOt3VB9BUohrKOIcuoxctCRQ2uky0cJ/5QH S/4m8vwXpUVv1OmZmqFztiCNstj0LouYQEiQ3VihAskewy6QWq02TBIsXihwa/puJMRb rhzyNRlSkyBQTp3xfIzWsSk9ZK+aCijcv+/iy3FjYDiO1qmk0cD8TX+KrngXTsIh4qxN P5MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775637227; x=1776242027; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Pbj1pinyLCpTvRMDqb5wMltAGKRQ0z6dfcrCaaij6ks=; b=aJnBGQ8Vy/VEzYWVsRoLjSgDzEqqxPCCm3F+YaBk7YlBS2K/226ahBYUYWbMQelLpI xz/f5eZTQbIFnXjUGErWGlUscwPED+PDfnPCLl/fnt6zchueX2a+xQfLrh2G8nFJ59Cy rtqxWCcUsy0am7vfugqvw11Q53GhMW0wX2BVJ+YPw/gfkltjnkXrgx3e908tSx6X709t h17utXUP/2qCUguIlj2YZQHlh5pNziIdpZ4/jP0JDz48SQZ9r7zo2D1ypP7rWOL6jI+e luit1lhgMQ+lu7In7FhvE9mGyrePvO1bA98/Qt3Bt3aWNrls2Li80kmXXnFTFf1h4tiY mikw== X-Forwarded-Encrypted: i=1; AJvYcCU1DSsV/feDRTRbY7SGbjVcs5oY13jsobl6WFKwknb2Ya2z2nDtY6cAuDTT0Xl4shAfQ+8Dh7OKysTi5hE=@vger.kernel.org X-Gm-Message-State: AOJu0YwdnohhU0Q6SvE6oTLU/i6wKRN/zDR3jPTpbgp7snnZPgp84mqg qlbcNOE99Ufjky+S0ANrPxMySJyBRxcj6waSkjZB2uj2sdGsvCpQt9eW X-Gm-Gg: AeBDiesjVaO9T372JfeG7SOQ8qGEF1bT4cd+/DcafS0nx2F2ubP6/0T/TGKaxheFLjR aWPW+sdVoZFhoXYyHj8FVzCi7Oudhwf523Hm7a+p70lhVdJUikYNeTpr+tt2qcNXWwkCOE4/Rcp /u5NUyCzAImp8dK0XjikciPGrYyziH5puDknyfeicThyUXwXE7tp9ua84+bwQnBxu8Q6rOD6QTo DU/XASaxoGeAfCfVyuWnUvwF5x+sE2RnVUpMTau/KfiISTYomHLq8PoI044RM4y2cHbdA7i0VNi SkI5TlyL1aEkfOKlL0u3OtMCnYz9IdsW1+py9kLmovI84PvBFijtja1BbZGbgBVoElmwmJ/Ii27 4vcTxIklNnsPxbBruzaDLg+Vl/i+iudIPFF8uVWirRZ7pJRISYYh7fwuID1WN4AN3VfP2WLh1un cladBUBO0BFHEDougnHxES6DzqIR8CrtlT X-Received: by 2002:a05:600c:3b1b:b0:488:8bdd:cfb9 with SMTP id 5b1f17b1804b1-488996b01c8mr283650655e9.1.1775637227307; Wed, 08 Apr 2026 01:33:47 -0700 (PDT) Received: from foxbook (bfi53.neoplus.adsl.tpnet.pl. [83.28.46.53]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488c5db33b4sm17711325e9.6.2026.04.08.01.33.45 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 08 Apr 2026 01:33:46 -0700 (PDT) Date: Wed, 8 Apr 2026 10:33:43 +0200 From: Michal Pecio To: Andrew Lunn Cc: Petko Manolov , Simon Horman , Morduan Zang , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-usb@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+9db6c624635564ad813c@syzkaller.appspotmail.com Subject: Re: [PATCH] usb: rtl8150: avoid using uninitialized CSCR value Message-ID: <20260408103343.19cf599a.michal.pecio@gmail.com> In-Reply-To: <76d6b341-27d5-44aa-92fb-3b8966d609df@lunn.ch> References: <93FF85BB9F33CD2B+20260402070743.20641-1-zhangdandan@uniontech.com> <20260403154538.GA187715@horms.kernel.org> <20260405085212.GA8491@cabron.k.g> <76d6b341-27d5-44aa-92fb-3b8966d609df@lunn.ch> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 6 Apr 2026 01:38:06 +0200, Andrew Lunn wrote: > > > - get_registers(dev, CSCR, 2, &tmp); > > > + if (get_registers(dev, CSCR, 2, &tmp) < 0) > > > + tmp = 0; > > > if (tmp & CSCR_LINK_STATUS) > > > netif_carrier_on(netdev); > > > else > > > > I was wondering if calling netif_carrier_off() is the right thing > > to do in case get_registers() fail. > > > > There are multiple get_registers() calls that don't check the error > > and if we do this in set_carrier() maybe we should do the same > > thing across the whole driver? > > What does it actually mean if get_registers() fails? The device is > gone? Hot unplugged? If so, you are going to get a cascade of errors, > and then hopefully the USB core code removes the device? > > Are there any legitimate reasons for get_registers() to fail if the > device is still plugged in? In principle it might be temporary EMI or a flaky cable. These errors rarely reach drivers due to retries in USB layer, but in extreme cases the device may be in unknown state and it may become functional later. IIRC net layer has some operations which are presumed trivial enough that they would never fail, so this could be annoying. It does seem rare enough in practice that for 25 years nobody noticed carrier status being set to a random vaule by this driver. BTW, some functions like rtl8150_reset() pre-set data to a value which will be safe in case of get_register() failure. But here, unhandled set_register() error is dodgy - the 0x10 bit may never turn on. Regards, Michal